Phressh
Posts: 2
Joined: Wed Jul 15, 2020 8:27 pm

Re: 4G Hat

Sat Jul 25, 2020 1:56 am

Yes, from my experiences the USB cable should be attached from SIM7600 microUSB port (make sure not UART) to RP USB port. Apparently GPIO pin 6 is the cellular modem on the SIM7600 so setting it to 1 brings it up and then setting back to 0 makes sure the button is not continuously pressed.

arkanos17
Posts: 2
Joined: Mon Jul 13, 2020 6:52 pm

Re: 4G Hat

Tue Jul 28, 2020 5:28 pm

Hello,
I've been struggling with this for some time now.
Was able to get to step 4 and thats where i hit a wall again.
Please can some one look at it and see if i am doing something wrong.

Code: Select all

root@raspberrypi:~# qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="apn='fast.t-mobile.com',username='blank',password='blank',ip-type=4" --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,2001): [cm] no-service
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '26'
root@raspberrypi:~# sudo udhcpc -i wwan0
udhcpc: started, v1.30.1
No resolv.conf for interface wwan0.udhcpc
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
root@raspberrypi:~# 
I tried with my username and password to the account still same results.
TIA.
Ark.

ndomx wrote:
Tue May 26, 2020 7:07 pm
I've been following mkrzysztofowicz' steps with my SIM7600SA-H module (not a hat, only the module with a USB port). I'm currently struggling with the raw_ip setup. On step 3, I get

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
tee: /sys/class/net/wwan0/qmi/raw_ip: No such file or directory
Y
I've found there's no directory named qmi inside the wwan0 folder and I'm also unable to create it (in case the answer was that simple) because the parent folder is protected. I guess the libqmi-utils package should have created those missing directories (?).

There's also another issue that may be causing this error. On step 2, when I execute the command

Code: Select all

pi:~$ sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'
The module turns on. However, the command also throws a timeout error. I'm not so sure this is what's causing my raw_ip problem because all the verification commands that come after work properly (get-operating-mode, get-signal-strength & get-home-network).

mkrzysztofowicz wrote:
Wed Apr 03, 2019 11:35 am
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: https://lb.raspberrypi.org/forums/viewt ... 1#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!

shikmywaifu
Posts: 2
Joined: Mon Aug 17, 2020 7:50 am

Re: 4G Hat

Mon Aug 17, 2020 8:04 am

I've been following "mkrzysztofowicz" post and are able to get the 4G module up and running.

The problem I have is after i reboot the Pi, it seems like the connection is still established but I couldn't get any internet connection on my Pi although the connection part is showing Up&Down arrow.
Any Help pls ?

rushix
Posts: 12
Joined: Sat Jan 20, 2018 7:45 am

Re: 4G Hat

Thu Aug 27, 2020 3:41 am

mkrzysztofowicz wrote:
Wed Apr 03, 2019 11:35 am
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: https://lb.raspberrypi.org/forums/viewt ... 1#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!


Can we use wvdial and pppd instead libqmi?

Dindondooly
Posts: 1
Joined: Fri Jan 24, 2020 5:42 pm

Re: 4G Hat

Sat Aug 29, 2020 11:45 am

Hi all, I have been banging my head on a brick wall with this HAT for 3 months now and have finally decided to come here. I have followed
mkrzysztofowicz instructions and run into problem.

When attempting to connect with the UK's giffgaff network (Virtual network using O2) I got the error: multiple-connections-to-the-same-PDN-not-allowed. So I thought maybe it was just the giffgaff network. I tried it with my O2 contract SIM which worked fine. So next I tried to use a Tesco SIM (Another O2 virtual network), which worked fine up until I actually loaded some data onto the SIM. Then I got the same error.

Can I get some help from anyone a bit more experienced with either qmi or simcom? I did find a Russian forum that said it needed a firmware update but I keep getting a Sahara error when trying to do that (Waveshare support have been of absolutely NO help. They just want to remote connect to my computer even though I have sent them a video and logs).

I have quintuple checked that the username password etc are correct and am at my wits end. Any help is appreciated!

Code: Select all

error: couldn't start network: QMI protocol error (14): 'CallFailed'
call end reason (1): generic-unspecified
verbose call end reason (6,55): [3gpp] multiple-connection-to-same-pdn-not-allowed

Gyom_86
Posts: 11
Joined: Fri Aug 28, 2020 12:40 pm

Re: 4G Hat

Mon Sep 21, 2020 3:27 pm

Hello guys,

I followed the instructions frommkrzysztofowicz and it run very well with my compute module 3with usb port.
The only point is that if the the SIM7600E module is not switched on, i don't see /dev/cdc-wm0 and i can't use command:

Code: Select all

sudo qmicli -d /dev/cdc-wdm0  --dms-set-operating-mode='online' 
I have a question: which commands need to be run each time i want to connect to the network?

I also tried a ppp and it's working also well.
If i compare both : ppp and libqmi:
1/ i didn't notice a difference in the download speed. I thought qmi was faster than ppp.
2/ configuring ppp is quite simple.
3/ each time i want to run ppp, i just have to switch on the simcom module and run

Code: Select all

 sudo pon config_file
What are the advantages of using qmi compare to ppp? perhaps you need to use ppp in one type of application and qmi in another one.


best regards,

Guillaume.

PS: My application is a raspberry pi box collecting can-bus data and sending them through sim7600E to a ftp server.

alexxtasi
Posts: 3
Joined: Thu Sep 24, 2020 8:58 pm

Re: 4G Hat

Thu Sep 24, 2020 9:08 pm

Hi all
it's been a while since I own a SIM7600E-H LTE hat and following it's manual (https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf) I managed to get a connection, using the pppd way.

I got to this post which is very useful but I have two questions

1- as @rushix asks here (viewtopic.php?f=36&t=224355&hilit=pppd& ... 5#p1718624)... is libqmi preffered over pppd and for what reason ?
2- did anyone had speed issues with this hat ?
3- since now I am using pppd to fire a connection... is there a way to open / close the ppp connection only in case of ethernet lack of connection automatically ? (as a form of backup connection)

regards

kranok
Posts: 2
Joined: Sat Jun 27, 2020 10:29 pm

Re: 4G Hat

Fri Sep 25, 2020 8:55 pm

Hi, for some time, I have tried to make the 4G connection and GPS work simultaneously in the SIM7600. Based on trial and error, I made the following things.

1. In a bash program, I copied the instructions posted by Pintovski in this same post. With those instructions, you can get Internet access with your SIM card and 4G Hat.
2. As for the GPS, I used the source code from waveshare: https://www.waveshare.com/wiki/SIM7600A-H_4G_HAT.
2.1. For this code, I used the code located in: SIM7600X-4G-HAT-Demo/Raspberry/python/GPS/GPS.py
2.2. I changed the line of

Code: Select all

ser = serial.Serial('/dev/ttyS0',115200)
to

Code: Select all

ser = serial.Serial('/dev/ttyUSB2',115200)
.
2.3. Finally, I commented part of the power_on function:

Code: Select all

def power_on(power_key):
	print('SIM7600X is starting:')
	#GPIO.setmode(GPIO.BCM)
	#GPIO.setwarnings(False)
	#GPIO.setup(power_key,GPIO.OUT)
	#time.sleep(0.1)
	#GPIO.output(power_key,GPIO.HIGH)
	#time.sleep(2)
	#GPIO.output(power_key,GPIO.LOW)
	#time.sleep(20)
	ser.flushInput()
	print('SIM7600X is ready')
Basically, I commented the GPIO functions. I assume that this code is resetting the 4G configuration, thus being blocked. I managed to make both work by first connecting to 4G and then running the GPS code.

Hope it helps! :D

lancer6x
Posts: 3
Joined: Tue Jun 23, 2020 3:14 pm

Re: 4G Hat

Thu Oct 01, 2020 6:51 pm

SO here's the next question.

Following the instructions on this forum will get you a connected modem. Now, what scripts are people using to gracefully disconnect and shut their modems down?

cuagn
Posts: 5
Joined: Thu Aug 16, 2018 2:00 pm

Re: 4G Hat

Wed Oct 07, 2020 10:26 am

Hello all,

I'm trying to install the basic BK board of a SIM7600E-H following (I hope!) the guidelines.
To summarize :

Code: Select all

# A configuration file is defined
# /etc/qmi-network.conf
# with the following lines
# APN=sl2sfr
# ip-type=4

# in /etc/dhcpcd.conf
# add the following lines to set wwan0 to higher priority than eth0
# interface wwan0
#     metric 201
# interface eth0
#     metric 300


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

# check it
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
# returns the name of the network interface, typically wwan0	

# change to raw-ip
sudo ip link set wwan0 down		# shut the network interface
echo 'Y' | sudo tee /sys/class/net/wwan0/qmi/raw_ip
sudo ip link set wwan0 up

# start network
sudo qmi-network /dev/cdc-wdm0 start

# get a lease
sudo udhcpc -q -f -i wwan0
All "seems" OK

Code: Select all

ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.82  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2001:41d0:fe19:7f00:54b:77a8:1ba8:6f1b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::4cf3:a58f:3875:fc1a  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:80:ae:2d  txqueuelen 1000  (Ethernet)
        RX packets 258  bytes 20949 (20.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1038  bytes 63516 (62.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1330  bytes 121439 (118.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1330  bytes 121439 (118.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wwan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 100.71.245.5  netmask 255.255.255.252  destination 100.71.245.5
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 2  bytes 612 (612.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 34  bytes 6608 (6.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Now, if I consider a basic ping

Code: Select all

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=175 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=45.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=35.5 ms
hmmm... Which connexion ? eth0 or wwan0 ?

Code: Select all

ping -I eth0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.1.82 eth0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=50.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=48.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=49.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=49.4 ms

Code: Select all

ping -I wwan0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 100.71.245.5 wwan0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=160 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=32.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=34.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=50.4 ms
Question : how to verify what is used by default eth0 or wwan0 ?

Then I try to establish a SSH session (putty from my desktop) directly to 100.71.245.5.
It fails... Why ?

Any help welcome.
Tnks

User avatar
DougieLawson
Posts: 42176
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: 4G Hat

Wed Oct 07, 2020 2:06 pm

cuagn wrote:
Wed Oct 07, 2020 10:26 am

Question : how to verify what is used by default eth0 or wwan0 ?

The route or (better) ip route command will tell you that.
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

cuagn
Posts: 5
Joined: Thu Aug 16, 2018 2:00 pm

Re: 4G Hat

Fri Oct 09, 2020 7:50 am

The route or (better) ip route command will tell you that.
Thank you.

sifr
Posts: 3
Joined: Fri Oct 09, 2020 3:39 pm

Re: 4G Hat

Sat Oct 10, 2020 3:45 pm

I followed mkrzysztofowicz's instructions but I get this:

Code: Select all

sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="pp.vodafone.co.uk,username=web,password=web,ip-type=4,auth=both,autoconnect=no" --client-no-release-cid --client-cid $CID

error: operation failed: Transaction timed out
[/dev/cdc-wdm0] Client ID not released:
        Service: 'wds'
            CID: '6' 
I input the CID as that returned from the previous command:

Code: Select all

sudo qmicli -d /dev/cdc-wdm0 --nas-get-home-network --client-no-release-cid
As soon as Iv run the 'nas-get-home-network command', I get the flashing red 'NET' light on the PCB which indicates that iv got a connection.

And also the AT commands say I have a connection too:

Code: Select all

AT+CPSI?
+CPSI: WCDMA,Online,234-15,0x0133,[CELL TOWER ID NO],WCDMA 900,7,2987,0,13.0,92,16,23,500
OK
And curiously, my wwan0 interface was assigned a private IP address, but I want a public IP address!

Code: Select all

pi@raspberrypi:~ $ sudo ifconfig
wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.97.249  netmask 255.255.0.0  broadcast 169.254.255.255 
It seems like the cell tower is playing ball but vodafone just arent... Im starting to wonder if I should give up on qmi and use pppd or wvdial?
Any help or insights would be very gratefully received :)

sifr
Posts: 3
Joined: Fri Oct 09, 2020 3:39 pm

Re: 4G Hat

Mon Oct 12, 2020 4:34 pm

With a little more investigation, it turned out that my pi's /etc/resolv.conf had my router's ip address and route was displaying this local ip. So to take that out of the equation, rather than SSHing into my pi to access it headlessly, I set it up to run with a monitor. I also erased the private IP from /etc/resolv.conf. I tried both of the commands once again:

Code: Select all

sudo qmicli -p -d /dev/cdc-wdm0 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network="pp.vodafone.co.uk,username=web,password=web,ip-type=4,auth=both,autoconnect=no" --client-no-release-cid

Code: Select all

sudo qmi-network /dev/cdc-wdm0 start
However, both commands returned the same error message:

Code: Select all

error: couldn't start network: QMI protocol error (26): 'NoEffect'
Previous posts in this thread suggest the solution to this error is to make sure that 'autoconnect' is not enabled. But ofcause the qmicli 'device-open-net' command has autoconnect=no

This is pretty strange.

YummoPi
Posts: 2
Joined: Wed Oct 14, 2020 10:06 pm

Re: 4G Hat

Wed Oct 14, 2020 10:20 pm

alexxtasi wrote:
Thu Sep 24, 2020 9:08 pm
Hi all
it's been a while since I own a SIM7600E-H LTE hat and following it's manual (https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf) I managed to get a connection, using the pppd way.

I got to this post which is very useful but I have two questions

1- as @rushix asks here (viewtopic.php?f=36&t=224355&hilit=pppd& ... 5#p1718624)... is libqmi preffered over pppd and for what reason ?
2- did anyone had speed issues with this hat ?
3- since now I am using pppd to fire a connection... is there a way to open / close the ppp connection only in case of ethernet lack of connection automatically ? (as a form of backup connection)

regards
I can't speak to 1 or 3 above, but I have been struggling with the speed issue. According to the documentation I should be able to get pretty good 4G speed, but I'm currently getting about 11Mbps down and 0.26Mbps up. I've used pretty much all the configurations I could find including the very good steps provided in prior posts in this thread. I've also tried USB/Pi UART and combinations of jumper settings.

I have tried multiple SIMs including ones proven to work in phones in the same location as the Pi.

At this point it seems like maybe the Hat is falling back to non-4g technology. I attempted to force 'LTE only' using minicom but this resulted in no signal. When it does indeed report lte in the qmicli status output the signal strength is very low, but I'm on the Telstra network in Sydney so there should not be any signal issues and the phone next to it is fine.

Does anyone have any suggestions or even comments about the sorts of speed they are getting?

alexxtasi
Posts: 3
Joined: Thu Sep 24, 2020 8:58 pm

Re: 4G Hat

Sun Oct 18, 2020 8:25 pm

mkrzysztofowicz wrote:
Wed Apr 03, 2019 11:35 am
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: https://lb.raspberrypi.org/forums/viewt ... 1#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'
---------------

Hi there
trying your steps, I installed successfully libqmi-utils and udhcpc in Raspberry Pi 3 model B with Rasperry Pi OS.
But when trying to turn the radio "online" the command results with an error:

Code: Select all

pi@raspberrypi:~ $ sudo qmicli -d /dev/cdc-wdm0 --dms-set-operating-mode='online'
error: couldn't create QmiDevice: Couldn't query file info: Error when getting information for file “/dev/cdc-wdm0”: No such file or directory
In fact there is no such device "/dev/cdc-wdm0".

I am using sim7600e-lte-cat-1 (https://www.waveshare.com/sim7600e-lte-cat-1-hat.htm) connected as a HAT in RPi-3 and following the official documentation (https://www.waveshare.com/w/upload/6/6d ... ual-EN.pdf) it's on device "/dev/ttyS0".

Just in case (maybe it's completely wrong) I tried set online mode in "/dev/ttyS0", but failed with:

Code: Select all

pi@raspberrypi:~ $ sudo qmicli -d /dev/ttyS0 --dms-set-operating-mode='online'
[18 Oct 2020, 23:01:18] -Warning ** [/dev/ttyS0] couldn't load driver of cdc-wdm port
error: couldn't open the QmiDevice: Cannot automatically select QMI/MBIM mode: driver unknown
1- Am I missing something here ?? Software or hardware ?? eg is the hat connection an issue ??
2- ... and my main question... what are the libqmi advantages instead of ppp ??

regards

alexxtasi
Posts: 3
Joined: Thu Sep 24, 2020 8:58 pm

Re: 4G Hat

Sun Oct 18, 2020 8:34 pm

YummoPi wrote:
Wed Oct 14, 2020 10:20 pm
Does anyone have any suggestions or even comments about the sorts of speed they are getting?
thanks for sharing this ...
as you can see above I couldn't yet manage to connect using libqmi...
Till now, I experience slow connection using ppp

YummoPi
Posts: 2
Joined: Wed Oct 14, 2020 10:06 pm

Re: 4G Hat

Sun Oct 18, 2020 10:27 pm

alexxtasi wrote:
Sun Oct 18, 2020 8:34 pm
YummoPi wrote:
Wed Oct 14, 2020 10:20 pm
Does anyone have any suggestions or even comments about the sorts of speed they are getting?
thanks for sharing this ...
as you can see above I couldn't yet manage to connect using libqmi...
Till now, I experience slow connection using ppp
Apologies if you already tried this, but have you connected the USB from the hat to the Pi?

I was not able to get it working without doing that. Based on the documentation it would seem that connection via the Pi pin thing should work, but it did not for me.

I have also read that (assuming it IS possible) that this might limit the speed where USB will not.

sifr
Posts: 3
Joined: Fri Oct 09, 2020 3:39 pm

Re: 4G Hat

Mon Oct 26, 2020 2:04 pm

Embedded pi have some pretty good qmi-cli documentation here https://embeddedpi.com/documentation/3 ... face-setup They suggest that the private IP that my wwan0 interface has, has not been assigned by a DHCP server:
You may find at startup that the wwan0 interface is enabled but is in a disconnected state (usually with a 169.254.x.x. address) before the modem has connected fully and obtained an IP address
But that still doesnt explain the 'leasefail' message that udhcpc is throwing:

Code: Select all

raspberrypi udhcpc[972]: wwan0: configuration failed: leasefail: 
Here is a bit of context:

Code: Select all

raspberrypi avahi-daemon[405]: Withdrawing address record for 169.254.189.25 on wwan0.
raspberrypi avahi-daemon[405]: Leaving mDNS multicast group on interface wwan0.IPv4 with address 169.254.189.25.
raspberrypi avahi-daemon[405]: Interface wwan0.IPv4 no longer relevant for mDNS.
raspberrypi dhcpcd[567]: wwan0: pid 975 deleted IP address 169.254.189.25/16
raspberrypi dhcpcd[567]: wwan0: deleting route to 169.254.0.0/16
raspberrypi udhcpc[972]: wwan0: deconfigured
raspberrypi dhcpcd[567]: wwan0: probing for an IPv4LL address
raspberrypi dhcpcd[567]: wwan0: using IPv4LL address 169.254.50.117
raspberrypi dhcpcd[567]: wwan0: adding route to 169.254.0.0/16
raspberrypi avahi-daemon[405]: Joining mDNS multicast group on interface wwan0.IPv4 with address 169.254.50.117.
raspberrypi avahi-daemon[405]: New relevant interface wwan0.IPv4 for mDNS.
raspberrypi avahi-daemon[405]: Registering new address record for 169.254.50.117 on wwan0.IPv4.
raspberrypi udhcpc[972]: wwan0: configuration failed: leasefail: 
raspberrypi udhcpc[972]: wwan0: configuration failed: leasefail: 
raspberrypi udhcpc[972]: wwan0: configuration failed: leasefail: 
EDIT (SOLVED!):
I found that the issue was actually vodafones credentials are posted incorrectly in most places online. The trick is to submit NO USERNAME and NO PASSWORD:

Code: Select all

sudo qmicli -d /dev/cdc-wdm0 --device-open-net="net-raw-ip|net-no-qos-header" --wds-start-network="apn='pp.vodafone.co.uk',ip-type=4" --client-no-release-cid
Here are the commands in full:

Part 1: prepare qmi

Code: Select all

sudo qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
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
Part 2: connect to Vodafone

Code: Select all

sudo qmicli -d /dev/cdc-wdm0 --device-open-net="net-raw-ip|net-no-qos-header" --wds-start-network="apn='pp.vodafone.co.uk',ip-type=4" --client-no-release-cid
Part 3: request an IP from vodafones DHCP server

Code: Select all

sudo udhcpc -i wwan0
Many thanks to embeddedpi.com for their tutorial. If you have a similar setup, I strongly recommend you follow the same tutorial here: https://embeddedpi.com/documentation/3g ... face-setup.
Last edited by sifr on Sun Nov 22, 2020 12:24 pm, edited 5 times in total.

phabloshablo
Posts: 2
Joined: Mon Nov 02, 2020 4:37 pm

Re: 4G Hat

Thu Nov 05, 2020 5:44 pm

I have a problem with my 7600X.
In particular i have this error

Code: Select all

error: couldn't start network: QMI protocol error (14): 'CallFailed'
call end reason (1): generic-unspecified
verbose call end reason (2,208): [internal] pdn-ipv4-call-disallowed
[/dev/cdc-wdm0] Client ID not released:
	Service: 'wds'
	    CID: '33'
How can i resolve??

palia95
Posts: 3
Joined: Fri Nov 06, 2020 5:33 pm

Re: 4G Hat

Fri Nov 06, 2020 5:45 pm

Hi!

First of all thank you a lot for this useful topic, it helped to make the SIM7600 Hat work on my Raspberry Pi 3 Model B+.

However, I'm getting crazy with a strange issue. Premise: i followed the mkrzysztofowicz's instructions method and I successfully get the hat working through the USB cable. However, I noticed that after a few hour (maybe minutes) of activity or standby, the LTE connection stop working, making the RPI unreachable (I have to manually reboot it to get the LTE link up gain) on VNC (same for Teamviewer) through the mobile network.

I can't figure out which could be the problem, because the LTE connection work flawless once I setup it, but after a certain unknown amount of time, it stops working, which is a big problem for my use case, since my RPI is placed in a field in the country side with many connected sensors.

I don't have any error on the terminal, so I have no idea of what could be. Do you have any suggestion/test to do?

Thank you again!

Emanuele

HftH
Posts: 4
Joined: Sat Jul 04, 2020 8:12 am

Re: 4G Hat

Sun Nov 15, 2020 8:21 am

I have the hat working on a Pi Zero... intermittently.

Often, running the commands as mentioned by @mkrzysztofowicz works perfectly, however every now and again I get

Code: Select all

error: couldn't open the QmiDevice: Transaction timed out
This happens when trying to connect to the mobile network. ie, at the line:

Code: Select all

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
Does anybody have any thoughts as to why the hat doesn't want to respond here? AT commands work fine on the serial pins but the USB seems to be struggling to get the hat to respond.

Many thanks in advance.

dubrma
Posts: 2
Joined: Tue Nov 17, 2020 12:54 pm

Re: 4G Hat

Tue Nov 17, 2020 1:36 pm

Hello
I bought this module, because I need GPS and LTE for my project. GPS work perfect since first set up. But if I turn on LTE 4G connection, stability problems begin. I try two setups, first method by mkrzysztofowicz's, second method official https://www.waveshare.com/wiki/Raspberr ... d_via_NDIS . From the beginning, everything runs fine, but then various problems begin to appear. Most often the LTE connection is interrupted, but also the USB device is reconnected. Failures begin to appear after a few minutes to an hour. I try to boost module power supply 5V and also VBAT 3,77V.
I had a terrible ten days with this module, I can't fix the problem. I am convinced that the module cannot provide LTE connection and GPS position in the same time.

Has anyone been able to use LTE and GPS at the same time without stability problems?

Thanks for nice forum thread.

I'm sorry for my bad English.

Raspberry pi 5 + Raspberry Pi OS
SIM7600E-H 4G HAT, serial0 over GPIO, USB for LTE (wwan) and GPS data (/dev/ttyUSB1), set operating voltage as 3.3V, B: control the SIM7600 by Raspberry Pi

blanco326
Posts: 4
Joined: Fri Aug 14, 2020 7:37 pm

Re: 4G Hat

Mon Nov 23, 2020 4:35 pm

Did anyone figure out how to get GPS? I followed the instructions earlier to connect to 4G, but I don't have GPS.

ganzgustav22
Posts: 325
Joined: Tue Feb 11, 2020 1:04 pm

Re: 4G Hat

Tue Nov 24, 2020 1:58 pm

They suggest that the private IP that my wwan0 interface has, has not been assigned by a DHCP server:
Yes. On Raspbian, it's dhcpcd that's causing this.

If you don't want dhcpcd to run on the wwan0 interface, you can add this to /etc/dhcpcd.conf:
denyinterfaces wwan0

Return to “Networking and servers”