4G Hat

[kikusin]

I am afraid we both need help from someone who knows better about QMI. I am still blocked with the IP lease :S

The only thing I can suggest is: by console, do you get to open the network by [ AT+NETOPEN ] ?
And can you get IP [ AT+IPPADDR ]?

Surely you know, but just in case, the IP you mention [ wwan0: configured 169.###.##.88/16 ] is autoconfig one, not a valid IP. What make sense if there are problems to open the network.

Good luck!

[gamura]

Hi @kikusin,

I am currently playing around with the waveshare LTE hat and ran into exactly the same problem. I was able to solve it by executing the following command. I simply execute it just before using udhcpc to get an IP.

Code: Select all

sudo qmi-network /dev/cdc-wdm0 start

This only works if you set the device to use the "raw-ip" as mentioned in mkrzysztofowicz's awesome instructions. Thanks for that by the way! I hope this helps. If not, I can sent you my total list of commands i use to activate the modem.

[kikusin]

It worked!
Thank you so much Gamura!
[By the way, probably related to ISP, but in my case I need to wait up to three minutes since starting network till I request IP if I want it to succeed.]

Anyway, just in case, I think is great to have here the whole list of commands you use. I am pretty sure someone else will face same problem.

Thanks again!

[witenite1]

Hi,
I'm hoping somebody with a lot more QMI knowledge can help me. I have been tearing my hair out spending hours every night for a couple of weeks trying to get this working! Basically I have a SIM7600SA-H based hat for the Raspberry Pi 3B+ board running the latest version (Stretch) of Raspbian. Connecting to the 2Degrees network here in New Zealand.

I have closely followed instructions from mkrzysztofowicz using the QMI utils library as described here, but no success. Basically doing the following:

1. sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online' # Unit reports Operating mode set successfully
2. I get either a slow flashing (approx1 second duty cycle) NET LED, indicating as far as I understand it, a connected network. Then flashes fast after a while.
3. sudo qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength # Reports successfully got signal strength. This shows Current and RSSI drifting around from -80dBm to -100dBm and ECIO -4dBm to -18dBm. Sometimes UMTS, sometimes LTE networks. I have seen LTE network sometimes come up with additional network information but I'm not sure whether that means that's the only time it's actually connected, or just random additional info.
4. sudo qmicli -d /dev/cdc-wdm0 --nas-get-home-network # Reports MCC: 530, MNC: 24, Description: 2degrees. This all makes sense.
5. Bring down wwan0 interface run, sudo echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip and bring wwan0 up again. No errors etc. reported, though I note wwan0 has no IP address anymore.
6. sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='internet',ip-type=4" –client-no-release-cid # Works without errors, however...
I get told
[/dev/cdc-wdm0] Network started
Packet data handle: '2263160128'
The Packet data handle obviously changes every time, but nothing else is reported. this differs from everybody elses experience, where they see something like:
Service: 'wds'
CID: '20'
I never see this.

Furthermore, if I disregard this, and move on and run sudo udhcpc -i wwan0 I get:
udhcpc (v1.22.1) started
No resolv.conf for interface wwan0.udhcpc
Sending discover...
Sending discover...
Sending discover...
Sending discover...

No discovery is ever made. I have tried this with both the wwan0 interface up and down, it makes no difference.

To make matters worse, I have read there is a bug in the QMI uttils and it's recommended to roll back to an earlier version. Also there's a typo in /usr/bin/qmi-network for the Raspbian version (see bug report here):
https://bugs.debian.org/cgi-bin/bugrepo ... bug=845979
I have not rolled back, as I get the impression the bug is to do with the typo, so i fixed that instead, but that wasn't enough to get things working. I checked the version of QMI utils that I am using and it appears to be the "buggy" version, so it looks like this problem hasn't been fixed for at least a year, perhaps more.

I'm really hoping somebody here can help me, as I am absolutely out of ideas. Honestly, how hard can this be?!

[kikusin]

Hi @witenite1!

Have you tried to follow previos Gamuras tip?

launch

Code: Select all

sudo qmi-network /dev/cdc-wdm0 start

Before requesting IP.

This is not gonna get you rid of the bug, but is a faster thing to try.

Good luck!

[witenite1]

Hi,
thanks for your response. Yes, I had already tried that. I've tried it with various settings for APN (and I'm pretty sure I have this correct, I'm using:
APN: Internet
User: unset
Password: unset

also tried guest as username and password (as can be seen below) as these seemed typical credentials for other networks, but I get exactly the same results every time.

according to a couple of different sources online, these are the correct credentials. I get the following results:

qmi_start.png (117.65 KiB) Viewed 26019 times

Note the error (Couldn't parse input string...)
I don't know whether this is acceptable or not, but can find no information at all about this.

As per my previous message too, when I run
sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='internet',ip-type=4" –client-no-release-cid
I don't see something like:
Service: 'wds'
CID: '20'
I do however get a handle assigned, and no errors reported.

[kikusin]

I think it is not passing username and password.

Try to input all the parameter within " " , as only one unique string.
Like in --wds-start-network= "apn=orange,username=orange,password=orange,ip-type=4"

[Jarrr]

Hey guys,

Kinda new here so I hope I provide enough information to solve my problem, i have the waveshare sim7600 hat for europe (same as dobova86 mentioned) on a RPi 3B+ running raspian , and followed mkrzysztofowicz instructions, which are very good! thanks mkrzysztofowicz! my raspberry pi has acces to internet.

however, the next step for me is to make a wifi hotspot and provide other raspberry pi s (zeros) with internet acces. the goal is to send data from sensors / cameras on the zeros to a remote server. So far I have have set up the hotspot no problem, but devices connecting have no internet. I use the wifi module that is build the raspberry pi 3B+

I have followed basicly this https://www.raspberrypi.org/documentati ... s-point.md but this is for eth0 to wifi. im not sure how to go about making the bridge between my module (wwan0) and the wifihotspot (wlan0), simply changing eth0 to wwan0 did not work for me. I followed a few posts but was not succesfull.

Any help is very welcome or any broader explanation!

/etc/network/interfaces

Code: Select all

auto lo
iface lo inet loopback

allow-hotplug wwan0
iface wwan0 inet manual #could not start with static

allow hotplug wlan0
iface wlan0 inet manual #same, fails if I substitute with static keyword
	address 192.168.4.1
	netmask 255.255.255.0
	network 192.24.1.255
	broadcast 192.24.1.255

/etc/dnsmasq.conf

Code: Select all

interface-wlan0
dhcp-range=192.168.4.2,192.169.4.20,255.255.255.0,24h

/etc/dhcpcd.conf

Code: Select all

denyinterfaces wlan0
denyinterfaces wwan0

interface wlan0
	static ip_adress=192.168.4.1/24
	nohook wpa_supplicant

/etc/hostapd/hostapd.conf

Code: Select all

interface=wlan0
driver=nl80211
ssid=MyId
hw_mode=g
channel=7
wmm_enabled=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=password
wpa_pairwise=TKIP
rsn_pairwise=CCMP

I changed in /etc/default/hostapd this DAEMON_CONF="/etc/hostapd/hostapd.conf"

in /etc/sysctl.conf this net.ipv4.ip_forward=1 uncommend

Here I got stuck in ip table rules and bridges.

I followed a few treads like this but like I said, most posts are about eth0 to wwan0.
http://qcktech.blogspot.com/2012/08/ras ... outer.html
https://forum.openwrt.org/t/bridge-mode ... em/35974/8
https://raspberrypi.stackexchange.com/q ... d-ethernet
https://forum.openwrt.org/t/routing-wwa ... rpi3/30312

[szabofrigocargo1]

Hy

We're working on a project with an Rpi 3B and a SIM7600 LTE module.
We would be it used in cars for tracking.

We establish the connection using AT$QCRMCALL command (in chatscript) and request an IP address using DHCP.

The problem is that if there is a change of network while traveling, for example from LTE to 2G, then we get a new IP address from the provider.
DHCP still want to communicate with the IP address that received from the LTE network, and in the meantime DHCP should communicate with the 2G IP adress.

My question is, does DHCP have a configuration that can handle the IP address change?

How it works with a mobile phone??

Thanks.

[bipbip38]

Hi,

I tried to used same hat than you, but Ivm not able to configure it, even if in used the main docs of waveshare..

If one of you are able to help me it's will be wonderful.

A step by step process until the physical connection on PI3B+, should be perfect.

I'm a beginner on raspberry and on Linux OS.

Thanks for your understand and your help.

[horndash]

@mkrzysztofowicz - awesome, thanks!!

Works for me on the US t-mobile network with the following details: apn: fast.t-mobile.com (no username no password(

[ikillbombs]

Hi,

I have an issue regarding using the established internet connection that is described before.

I've used the qmcli and have established an internet connection. After that I'm using /dev/ttyUSB2

To receive calls and use https://github.com/wilsonwang371/sim-access to communicate.

Sometimes it completely looses the usb connection. When I call the USB connection always disappears.


Maybe somebody had the same issue?

[exszaa]

@mkrzysztofowicz

Thank You!!! tested work by me

[jjgl]

OK, I've got this working fully now!

For those of you who are still struggling, here's the required steps:

1. Install required software

Code: Select all

pi:~$ sudo apt-get update && sudo apt-get install libqmi-utils udhcpc

2. This one is important - when you reboot the pi, the SIM7600 module's cellular radio is OFF and needs to be turned ON before you can see the mobile network. One way is to use a script which pulls the GPIO pin 4 LOW for a second or two (as per this post: viewtopic.php?t=206761#p1368015), but a more elegant way I think is to use the newly installed qmi utils:

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

Note, you can verify if your radio needs to be turned on by using the following commands:

Code: Select all

qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength
qmicli -d /dev/cdc-wdm0 --nas-get-home-network

If the first command shows in its output 'Low Power' or anything other than 'online' it means your radio is off and needs to be turned on.
The last of those commands should return the LTE network ID if your device successfully connected.

3. Reconfigure the network interface for raw-ip protocol

The qmi-wwan kernel driver creates the wwan0 network interface for you when it detects the SIM7600 module connected to your Raspberry Pi. By default that interface is set to 802-3 protocol, however it seems the correct protocol should be raw-ip. The qmi-network script tries to set that up for you, but it will most likely fail. To make the change, do the following:

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 -w		# this confirms the name of the network interface, typically wwan0
pi:~$ sudo ip link set wwan0 down		# change the wwan0 to the one returned above if different
pi:~$ echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
pi:~$ sudo ip link set wwan0 up

4. Connect to the mobile network.

After having done all the above, when trying to use qmicli to connect, I was getting the following error: error: "couldn't start network: QMI protocol error (64): '(null)'. .

There have apparently been some changes to qmi utils in Stretch and most of the documentation I saw over the last days is almost correct but missing one vital detail - you need to add ip-type=4 to other parameters for qmicli -d /dev/cdc-wdm0 --wds-start-network= as below.

Code: Select all

pi:~$ qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='YOUR_APN',username='YOUR_USERNAME',password='YOUR_PASSWORD',ip-type=4" --client-no-release-cid
[/dev/cdc-wdm0] Network started
	Packet data handle: '2264328160'
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '20'

5. Finally, configure the IP address and the default route with udhcpc:

Code: Select all

pi:~$ sudo udhcpc -i wwan0
udhcpc (v1.22.1) started
No resolv.conf for interface wwan0.udhcpc
Sending discover...
Sending select for 10.65.52.178...
Lease of 10.65.52.178 obtained, lease time 7200
cat: /run/resolvconf/lock/pid: No such file or directory
/sbin/resolvconf: 733: kill: Illegal number:
clearing stale lock pid
Too few arguments.
Too few arguments.

As you can see, this spits out a number of errors, but they relate to configuration of DNS servers in your resolv.conf file, but otherwise this works and I can now get the connection via the mobile network:

Code: Select all

pi:~ $ ip a s wwan0
3: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/none
    inet 10.65.52.178/30 scope global wwan0
       valid_lft forever preferred_lft forever

pi:~ $ ip r s
default via 10.65.52.177 dev wwan0
10.65.52.176/30 dev wwan0 proto kernel scope link src 10.65.52.178
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.5 metric 202

pi:~ $ ping -4 www.google.com
PING www.google.com (74.125.193.147) 56(84) bytes of data.
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=1 ttl=50 time=732 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=2 ttl=50 time=79.4 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=3 ttl=50 time=80.3 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=4 ttl=50 time=79.4 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 79.447/242.945/732.530/282.662 ms

You can take a look at this article: http://www.embeddedpi.com/documentation ... face-setup for a way to tidy things up a bit. It refers to a different 3G/4G modem (Sierra Wireless) but the way they set interfaces up and everything else still applies.

Good luck!

Well that worked like a charm on my 7600E in Australia! Thank you very much!

I then bought a SIM7000C with not so much luck:



Their bands are similar
SIM7600E-H:
– LTE-FDD B1/B3/B5/B7/B8/B20
– LTE-TDD B38/B40/B41

SIM7000C
– FDD-LTE B1/B3/B5/B8

…and compatible with the ones the carriers use un Australia:
Australia is currently using these LTE bands:
2100MHz (B1) – Telstra (a handful of sites), Optus, Vodafone
1800MHz (B3) – Telstra, Optus, Vodafone
850MHz (B5) – Vodafone
2600MHz (B7) – Telstra, Optus
900MHz (B8) – Telstra (a handful of sites, utilises spectrum previously used by 2G)
700MHz (B28) – Telstra, Optus
2300MHz (B40) – Optus

Also they’re both SIMCOM, only difference is:
SIM7600E is LTE CAT 4
SIM7000C is LTE CAT M1(eMTC) and NBI-oT

So I wonder if I’m missing a step?

Otherwise is a dedicated SIM card for LTE CAT M1(eMTC) and NBI-oT being needed?

Has anyone connected to the LTE network successfully with a regular SIM card using a SIM7000?

[wntr]

Hey guys,

I really get nothing to work with my 4G Hat.

Here is what I've done so far:

1. Inserted my SIM-Card, connected the antenna to "Main", connected the hat via GPIO pins to my Raspberry Pi 3B+ without any USB cable connected to the hat. I left the two yellow jumpers factory-default like, centered just as pictured in the manual: https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf

2. Booted the raspberry, set via raspi-config the serial options as described in the manual(no, then yes), rebooted.

3 chmod 777 for sim7600_4G_hat_init and added
sh /home/.../sim7600_4G_hat_init to rc.local

4. Rebooted, installed minicom, started sudo minicom -D /dev/ttyS0 and nothing happens and it does not even react on any keystroke.
I even compiled the bcm2835 directory and the phoncecall-demo. When I try to sudo ./Phonecall it says:

"Failed to get byte count on serial."

Both LEDs shine red continuously. What am I doing wrong?

[jjgl]

Hey guys,

I really get nothing to work with my 4G Hat.

Here is what I've done so far:

1. Inserted my SIM-Card, connected the antenna to "Main", connected the hat via GPIO pins to my Raspberry Pi 3B+ without any USB cable connected to the hat. I left the two yellow jumpers factory-default like, centered just as pictured in the manual: https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf

2. Booted the raspberry, set via raspi-config the serial options as described in the manual(no, then yes), rebooted.

3 chmod 777 for sim7600_4G_hat_init and added
sh /home/.../sim7600_4G_hat_init to rc.local

4. Rebooted, installed minicom, started sudo minicom -D /dev/ttyS0 and nothing happens and it does not even react on any keystroke.
I even compiled the bcm2835 directory and the phoncecall-demo. When I try to sudo ./Phonecall it says:

"Failed to get byte count on serial."

Both LEDs shine red continuously. What am I doing wrong?

Hi wntr,

in the manual it says:
21. UART selection jumper：
A: access Raspberry Pi via USB to UART
B: control the SIM7600 by Raspberry Pi
C: control the SIM7600 via USB to UART

I too have the jumpers in the middle position and have the shield connected onto the RPi gpio (which turns the SIM7600 on on boot). I however, have the rpi pi connected via USB as well (to the "USB" port not "USB to UART"). When the module is on, the power LED is on (not blinking), try pressing the pwrkey if its blinking.

If you don't want to do that, you probably want to change it to configuration C (I haven't tested this yet).

You can then use the sample code available through waveshare's wiki page which is useful to get you started:
https://www.waveshare.com/wiki/SIM7600E-H_4G_HAT
under Resources > source code.

When connected through USB you can check /dev directory and will find ttyUSB 0-1-2-3-4 (as well as cdc-wdm0 for qmi-cli). Interfaces ttyUSB 2 and 3 have worked well for all my tests with the USB cable.

The following python code has worked to test AT commands (you can set it to 115200bps too if needed):

Code: Select all

import time
import serial

# configure the serial connections (the parameters differs on the device you are connecting to)
ser = serial.Serial(
    port='/dev/ttyUSB2',
    baudrate=9600,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_TWO,
    bytesize=serial.EIGHTBITS
)

ser.isOpen()

print 'Enter your commands below.\r\nInsert "exit" to leave the application.'

input=1
while 1 :
    # get keyboard input
    input = raw_input(">> ")
        # Python 3 users
        # input = input(">> ")
    if input == 'exit':
        ser.close()
        exit()
    else:
        # send the character to the device
        # (note that I happend a \r\n carriage return and line feed to the characters - this is requested by my device)
        ser.write(input + '\r\n')
        out = ''
        # let's wait one second before reading output (let's give device time to answer)
        time.sleep(1)
        while ser.inWaiting() > 0:
            out += ser.read(1)

        if out != '':
            print ">>" + out

I've been using qmi-cli since I read "mkrzysztofowicz" post on this thread to establish a LTE internet connection:

Code: Select all

#!/bin/bash
sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

sudo qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
sudo qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength
sudo qmicli -d /dev/cdc-wdm0 --nas-get-home-network

sudo qmicli -d /dev/cdc-wdm0 -w		# this confirms the name of the network interface, typically wwan0
sudo ip link set wwan0 down		# change the wwan0 to the one returned above if different
echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
sudo ip link set wwan0 up

sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="ip-type=4" --client-no-release-cid

sudo udhcpc -i wwan0
ip a s wwan0
ip r s

All this code is good for testing manually initially and a POC at least.
I've found the SIM7600 from waveshare to work very reliably so far.

Hope this helps!

[jjgl]

Hi guys !

when I try to start network I get an error:
error: couldn't start network: QMI protocol error (14): 'CallFailed'

Code: Select all

sudo qmicli -p  -d /dev/cdc-wdm0 --device-open-"net=net-raw-ip|net-no-qos-header" --wds-start-network="apn='orange',username='orange',password='orange' --client-no-release-cid
error: couldn't start network: QMI protocol error (14): 'CallFailed'
call end reason (3): generic-no-service
verbose call end reason (3,2500): [cm] (null)
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '20'

I'm completely desperate ! I don't know 'How' and 'Where' I can find the solution.
Can someone help me ?

I have experienced call failed when the signal strength is not strong enough. Also when the APN settings are not correct. With some networks I've been able to connect without any settings like so:

Code: Select all

sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="ip-type=4" --client-no-release-cid

I would suggest to try different APN USER PASSWORD combinations, provided the signal strength is good enough.

[jjgl]

Hi,

I tried to used same hat than you, but Ivm not able to configure it, even if in used the main docs of waveshare..

If one of you are able to help me it's will be wonderful.

A step by step process until the physical connection on PI3B+, should be perfect.

I'm a beginner on raspberry and on Linux OS.

Thanks for your understand and your help.

Hi, I have it connected through the gpio pins and with the usb ("usb" port, NOT "usb to uart") and jumpers on configuration B.

With this configuration "mkrzysztofowicz" 's code works perfectly for me (using qmi-cli):

Code: Select all

#!/bin/bash
sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

sudo qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
sudo qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength
sudo qmicli -d /dev/cdc-wdm0 --nas-get-home-network

sudo qmicli -d /dev/cdc-wdm0 -w		# this confirms the name of the network interface, typically wwan0
sudo ip link set wwan0 down		# change the wwan0 to the one returned above if different
echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
sudo ip link set wwan0 up

sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="ip-type=4" --client-no-release-cid

sudo udhcpc -i wwan0
ip a s wwan0
ip r s

[arnolddozsa90]

Hey guys,

I really get nothing to work with my 4G Hat.

Here is what I've done so far:

1. Inserted my SIM-Card, connected the antenna to "Main", connected the hat via GPIO pins to my Raspberry Pi 3B+ without any USB cable connected to the hat. I left the two yellow jumpers factory-default like, centered just as pictured in the manual: https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf

2. Booted the raspberry, set via raspi-config the serial options as described in the manual(no, then yes), rebooted.

3 chmod 777 for sim7600_4G_hat_init and added
sh /home/.../sim7600_4G_hat_init to rc.local

4. Rebooted, installed minicom, started sudo minicom -D /dev/ttyS0 and nothing happens and it does not even react on any keystroke.
I even compiled the bcm2835 directory and the phoncecall-demo. When I try to sudo ./Phonecall it says:

"Failed to get byte count on serial."

Both LEDs shine red continuously. What am I doing wrong?

Dear!

I do not now that you solved the problem or not yet, but i had exactly the same problem.
The device works perfectly when i plugged on to the USB only (not used as a hat). (In this mode i had to push the power button for a second to power up the module, and the NET led flashes as expected)
used pppd and chatscript to connect

When i put it on the raspberry via gpio (as hat), the NET led shine continuously.

The manual contains a mistake.
It says put init your file to /home/pi/.
and says add this line to rc.local before "exit 0"
your end of file should look like

Code: Select all

...
fi
sh /home/pi/SIM7600X/sim_7600_4G_hat_init
exit 0

The problem is that your init file is here /home/pi/sim7600_4G_hat_init
and the rc.local points to /home/pi/SIM7600/sim7600_4G_hat_init
and cannot run this script and will not prepare your gpios.

In common the gpios are "floating".
The script is important because it prepares your 4 and 6 gpio to down.
If you open the init file it contains instructions for the gpios.
This runs when the device boots.

So you only have to correct the path to your init file.

When you reboot next your pi, then the NET led should blink

I did the same way and works.

One more thing:
You can check it with minicom
Download minicom

minicom -s

port settings -> A
set to ttyS0
Enter
Enter
Exit
type "AT"
gives "OK"
type "ATI"
gives similar to "
Manufacturer: SIMCOM INCORPORATED
Model: SIMCOM_SIM7600E-H
Revision: SIM7600M22_V1.1
IMEI: ***************
+GCAP: +CGSM

OK
"
type "AT+CSQ"
gives
"+CSQ: 20,99

OK"

if something is wrong with the module or with the gpio config the previous command gives:
"+CSQ: 99,99

OK"
the first number gives the rssi, if this is 99 it means that the signal strength is not known or unavailable

another sign of wrong module operation
type "AT+CREG?"
gives "
+CREG: 0,1

OK"

if something wrong with the module or with the gpio config the previosu command gives:
"
+CREG: 0,0

OK"

the second number says that the module is registered on a network or not 1 means yes 0 means no
this should be 1 even if you not connected to the Internet (this is the mobile network)
for more information you can read AT commands manual
https://www.waveshare.com/w/upload/5/54 ... _V1.08.pdf

I hope helped you!

[dotmatt]

Hi all

Firstly, thanks for the great resources in this thread. I don't think I would have managed to get this working without them.

I've used the following set of commands to get the HAT running on a PI configured as wireless access point:

Code: Select all

#!/bin/bash
sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'
sudo ip link set wwan0 down		# change the wwan0 to the one returned above if different
echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
sudo ip link set wwan0 up
sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='internet',ip-type=4" --client-no-release-cid
sudo udhcpc -i wwan0

I can run the above at boot, both via rc.local and via @reboot in crontab.

However, no matter what happens, I don't get an IP lease until I manually issue

Code: Select all

sudo udhcpc -i wwan0

. Once I get the lease, everything works 100% and wireless clients connected to the Pi AP can access the internet.

I've also tried using the code here by adding the commands to the wwan0 interface file, which in many cases don't work at all (although I have a feeling that I have forgotten to issue the

Code: Select all

qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

instruction first).

I have also tried adding

Code: Select all

post-up /sbin/udhcpc -R -b -p /var/run/udhcpc.eth0.pid -i wwan0

to the wwan0 interface file with no success.

So basically, my question is am I missing some config for getting udhcpc to run at boot time after the wwan0 interface is up and connected?

[kina]

Hey guys,

I really get nothing to work with my 4G Hat.

Here is what I've done so far:

1. Inserted my SIM-Card, connected the antenna to "Main", connected the hat via GPIO pins to my Raspberry Pi 3B+ without any USB cable connected to the hat. I left the two yellow jumpers factory-default like, centered just as pictured in the manual: https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf

2. Booted the raspberry, set via raspi-config the serial options as described in the manual(no, then yes), rebooted.

3 chmod 777 for sim7600_4G_hat_init and added
sh /home/.../sim7600_4G_hat_init to rc.local

4. Rebooted, installed minicom, started sudo minicom -D /dev/ttyS0 and nothing happens and it does not even react on any keystroke.
I even compiled the bcm2835 directory and the phoncecall-demo. When I try to sudo ./Phonecall it says:

"Failed to get byte count on serial."

Both LEDs shine red continuously. What am I doing wrong?

Dear!

I do not now that you solved the problem or not yet, but i had exactly the same problem.
The device works perfectly when i plugged on to the USB only (not used as a hat). (In this mode i had to push the power button for a second to power up the module, and the NET led flashes as expected)
used pppd and chatscript to connect

When i put it on the raspberry via gpio (as hat), the NET led shine continuously.

The manual contains a mistake.
It says put init your file to /home/pi/.
and says add this line to rc.local before "exit 0"
your end of file should look like

Code: Select all

...
fi
sh /home/pi/SIM7600X/sim_7600_4G_hat_init
exit 0

The problem is that your init file is here /home/pi/sim7600_4G_hat_init
and the rc.local points to /home/pi/SIM7600/sim7600_4G_hat_init
and cannot run this script and will not prepare your gpios.

In common the gpios are "floating".
The script is important because it prepares your 4 and 6 gpio to down.
If you open the init file it contains instructions for the gpios.
This runs when the device boots.

So you only have to correct the path to your init file.

When you reboot next your pi, then the NET led should blink

I did the same way and works.

One more thing:
You can check it with minicom
Download minicom

minicom -s

port settings -> A
set to ttyS0
Enter
Enter
Exit
type "AT"
gives "OK"
type "ATI"
gives similar to "
Manufacturer: SIMCOM INCORPORATED
Model: SIMCOM_SIM7600E-H
Revision: SIM7600M22_V1.1
IMEI: ***************
+GCAP: +CGSM

OK
"
type "AT+CSQ"
gives
"+CSQ: 20,99

OK"

if something is wrong with the module or with the gpio config the previous command gives:
"+CSQ: 99,99

OK"
the first number gives the rssi, if this is 99 it means that the signal strength is not known or unavailable

another sign of wrong module operation
type "AT+CREG?"
gives "
+CREG: 0,1

OK"

if something wrong with the module or with the gpio config the previosu command gives:
"
+CREG: 0,0

OK"

the second number says that the module is registered on a network or not 1 means yes 0 means no
this should be 1 even if you not connected to the Internet (this is the mobile network)
for more information you can read AT commands manual
https://www.waveshare.com/w/upload/5/54 ... _V1.08.pdf

I hope helped you!

hello i've try it but it error

chmod: cannot access 'sim7600_4G_hat_init': No such file or directory

i done copy and paste the demo at /home/pi/SIM7600X/sim7600_4G_hat_init
. when i want to type the AT command at minicom it become freeze. i cant type anything there. can you help me. i really need anyone help. i really new with rpi and this sim7600 T^T

[montegue85]

This is great and I got it working. Do you have anything like this for the getting the GPS/GNS working?

OK, I've got this working fully now!

For those of you who are still struggling, here's the required steps:

1. Install required software

Code: Select all

pi:~$ sudo apt-get update && sudo apt-get install libqmi-utils udhcpc

2. This one is important - when you reboot the pi, the SIM7600 module's cellular radio is OFF and needs to be turned ON before you can see the mobile network. One way is to use a script which pulls the GPIO pin 4 LOW for a second or two (as per this post: viewtopic.php?t=206761#p1368015), but a more elegant way I think is to use the newly installed qmi utils:

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

Note, you can verify if your radio needs to be turned on by using the following commands:

Code: Select all

qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength
qmicli -d /dev/cdc-wdm0 --nas-get-home-network

If the first command shows in its output 'Low Power' or anything other than 'online' it means your radio is off and needs to be turned on.
The last of those commands should return the LTE network ID if your device successfully connected.

3. Reconfigure the network interface for raw-ip protocol

The qmi-wwan kernel driver creates the wwan0 network interface for you when it detects the SIM7600 module connected to your Raspberry Pi. By default that interface is set to 802-3 protocol, however it seems the correct protocol should be raw-ip. The qmi-network script tries to set that up for you, but it will most likely fail. To make the change, do the following:

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 -w		# this confirms the name of the network interface, typically wwan0
pi:~$ sudo ip link set wwan0 down		# change the wwan0 to the one returned above if different
pi:~$ echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
pi:~$ sudo ip link set wwan0 up

4. Connect to the mobile network.

After having done all the above, when trying to use qmicli to connect, I was getting the following error: error: "couldn't start network: QMI protocol error (64): '(null)'. .

There have apparently been some changes to qmi utils in Stretch and most of the documentation I saw over the last days is almost correct but missing one vital detail - you need to add ip-type=4 to other parameters for qmicli -d /dev/cdc-wdm0 --wds-start-network= as below.

Code: Select all

pi:~$ qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='YOUR_APN',username='YOUR_USERNAME',password='YOUR_PASSWORD',ip-type=4" --client-no-release-cid
[/dev/cdc-wdm0] Network started
	Packet data handle: '2264328160'
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '20'

5. Finally, configure the IP address and the default route with udhcpc:

Code: Select all

pi:~$ sudo udhcpc -i wwan0
udhcpc (v1.22.1) started
No resolv.conf for interface wwan0.udhcpc
Sending discover...
Sending select for 10.65.52.178...
Lease of 10.65.52.178 obtained, lease time 7200
cat: /run/resolvconf/lock/pid: No such file or directory
/sbin/resolvconf: 733: kill: Illegal number:
clearing stale lock pid
Too few arguments.
Too few arguments.

As you can see, this spits out a number of errors, but they relate to configuration of DNS servers in your resolv.conf file, but otherwise this works and I can now get the connection via the mobile network:

Code: Select all

pi:~ $ ip a s wwan0
3: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/none
    inet 10.65.52.178/30 scope global wwan0
       valid_lft forever preferred_lft forever

pi:~ $ ip r s
default via 10.65.52.177 dev wwan0
10.65.52.176/30 dev wwan0 proto kernel scope link src 10.65.52.178
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.5 metric 202

pi:~ $ ping -4 www.google.com
PING www.google.com (74.125.193.147) 56(84) bytes of data.
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=1 ttl=50 time=732 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=2 ttl=50 time=79.4 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=3 ttl=50 time=80.3 ms
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=4 ttl=50 time=79.4 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 79.447/242.945/732.530/282.662 ms

You can take a look at this article: http://www.embeddedpi.com/documentation ... face-setup for a way to tidy things up a bit. It refers to a different 3G/4G modem (Sierra Wireless) but the way they set interfaces up and everything else still applies.

Good luck!

[jupiter8]

Taught i would give you some advice to ease your life a bit. I had my share of troubles making these modem work. Days of pulling my hair out.

I'm using a sim7000g pcie with a usb adapter wich is more or less the same, and using the QMI WAN means running some script to connect or doing it manually. Not the best for me as i have a few dozen of them in the field left unatended and it need to connect back itself after a power loss or a reset.

I was using Huawei E-303 in Hilink mode before. Great modem, with usb-modeswitch being part of raspbian, you plug the thing and it work. Period. I needed something like this in Lte Cat1.

So the trick to make this modem being recognised as an ethernet adapter is to change it's mode with the AT+CECMMODE=1 command. This obscure command is not even published by Simcom themselfes, ask me why.


Starting with a fresh install of raspbian, plug your modem in a USB port with a valid sim card. enter lsusb -t, it will show you this:

[codepi@raspberrypi:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 5, Class=Vendor Specific Class, Driver=qmi_wwan, 480M][/code]

Now with minicom installed start it with this: sudo minicom -D /dev/ttyUSB3

enter your apn if not set: AT+CGDCONT=1,"IP","yourapn"

Now with a valid sim card in the modem (important or it will not work) enter this command: AT+CECMMODE?

It will tell you +CECMMODE=0

Enter: AT+CECMMODE=1

Now check again with AT+CECMMODE?

It will be: +CECMMODE=1

Now check with lsusb -t, it should be now a cdc_ether device

Code: Select all

pi@raspberrypi:~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 4, If 2, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 4, If 3, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 4, If 4, Class=Vendor Specific Class, Driver=option, 480M
    |__ Port 1: Dev 4, If 5, Class=Communications, Driver=cdc_ether, 480M
    |__ Port 1: Dev 4, If 6, Class=CDC Data, Driver=cdc_ether, 480M

And you should have interwebs right away. Type ifconfig and your modem should be listed as eth0 (if you have a pi zero) or eth1.

Ping google: ping -I eth0 8.8.8.8

That's all, nothing else to do.

[psulli10]

Hi...

Has anyone managed to get a 4g connection (using mkrzysztofowicz instructions... thanks by the way! ) and gps running through gpsd on boot of the Pi?

I've got a crontab script running after boot to bring the wwan down and reconfigure the network interface for raw-ip protocol. This works and gets me a 4g connection but it manages to break GPSD. GPSD is set up to listen on terminal '/dev/ttyUSB1' however when I bring the wwan down and reconfigure it this terminal appears to be locked and when it comes back up my GPS data is coming through on '/dev/ttyUSB2' below is the output from 'dmesg | grep usb'

Code: Select all

[    0.105295] usbcore: registered new interface driver usbfs
[    0.105370] usbcore: registered new interface driver hub
[    0.105485] usbcore: registered new device driver usb
[    0.305274] usbcore: registered new interface driver lan78xx
[    0.307836] usbcore: registered new interface driver smsc95xx
[    0.340601] dwc_otg 3f980000.usb: base=(ptrval)
[    0.785535] dwc_otg 3f980000.usb: DWC OTG Controller
[    0.787817] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    0.790138] dwc_otg 3f980000.usb: irq 56, io mem 0x00000000
[    0.797137] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[    0.801637] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.804045] usb usb1: Product: DWC OTG Controller
[    0.806406] usb usb1: Manufacturer: Linux 4.19.97-v7+ dwc_otg_hcd
[    0.808847] usb usb1: SerialNumber: 3f980000.usb
[    0.817119] usbcore: registered new interface driver usb-storage
[    0.848775] usbcore: registered new interface driver usbhid
[    0.851405] usbhid: USB HID core driver
[    1.237035] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    1.477335] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[    1.482647] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.807035] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    1.937329] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[    1.942792] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.040667] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:98:bf:20
[    2.137050] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[    2.290256] usb 1-1.3: New USB device found, idVendor=1e0e, idProduct=9001, bcdDevice= 3.18
[    2.296668] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.300180] usb 1-1.3: Product: SimTech, Incorporated
[    2.303550] usb 1-1.3: Manufacturer: SimTech, Incorporated
[    2.307036] usb 1-1.3: SerialNumber: 0123456789ABCDEF
[    5.165678] usbcore: registered new interface driver brcmfmac
[    5.193777] usbcore: registered new interface driver usbserial_generic
[    5.193856] usbserial: USB Serial support registered for generic
[    5.200224] usbcore: registered new interface driver cdc_wdm
[    5.216489] usbcore: registered new interface driver option
[    5.216569] usbserial: USB Serial support registered for GSM modem (1-port)
[    5.229495] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
[    5.231424] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1
[    5.232501] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
[    5.235632] qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at usb-3f980000.usb-1.3, WWAN/QMI device, 26:21:06:a9:dc:56
[    5.235992] usbcore: registered new interface driver qmi_wwan
[    5.236627] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
[    5.257189] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4
[   29.362352] usb 1-1.3: USB disconnect, device number 4
[   29.366945] qmi_wwan 1-1.3:1.5 wwan0: unregister 'qmi_wwan' usb-3f980000.usb-1.3, WWAN/QMI device
[   35.537055] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[   35.680009] usb 1-1.3: New USB device found, idVendor=1e0e, idProduct=9001, bcdDevice= 3.18
[   35.680026] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   35.680036] usb 1-1.3: Product: SimTech, Incorporated
[   35.680046] usb 1-1.3: Manufacturer: SimTech, Incorporated
[   35.680055] usb 1-1.3: SerialNumber: 0123456789ABCDEF
[   35.682245] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0
[   35.683847] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2
[   35.685215] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB3
[   35.686397] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4
[   35.688779] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5
[   35.698582] qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at usb-3f980000.usb-1.3, WWAN/QMI device, 26:21:06:a9:dc:56

I can manually switch the terminal to 'dev/ttyUSB2' in '/etc/default/gpsd' and everything works fine but I need this all to automatically work on boot of my Pi? Any and all help appreciated. This is the first time I've worked with GSM modules so everything is new to me. I've tried disabling the gpsd service on boot but this has adverse affects on other services I'm running. Has anyone managed to achieve what I'm trying to do?

[djzuluroot]

I am not having luck using the command

sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

Mode: 'online'
HW restricted: 'no'

after rebooting the system does not start the model up, it starts when I run the command again,

sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'

to correct this I installed the latest firmware.