Modem Troubleshooting

The most common problems when operating a celluar link are usually down to network registration getting into a "confused" state or problems with getting or maintining a funtioning network connection.

To help here we have created a simple script to detail some of the key points to take note of regarding network registration :

Raspberry pi 3G 4G Modem troubleshooting network registration check


The most common checkpoints prior to "dial out" that should be tested are that the SIM is talking OK to the modem (i.e. it's not PIN locked or blocked) , the system has good signal strength (anywhere from around 5 to 22+ is considered OK) and the network is detected and registered.

If the modem detects low signal strength (below 10/31), the antenna should be re-orientated to capture best signal or fitted with a Yagi directional arial (pointing at the nearest base station) in areas where signal coverage is poor.  Below 10 and you'll more likely to have problems with getting LTE and the system may back off to 3G/EDGE/GPRS modes.

Occasionally modems can get stuck in the "Not registered, (not) searching" mode, or report really odd signal strength values,  here a soft reset can be issued to the modem via AT commands (depending on modem type) :


This usually is enough to reboot the modem firmware and restart the network registration process, failing that the device can be toggled in/out of airplane mode or given a hardware reset, using either 'Wireless Disable' or 'Modem Reset' Lines (see GPIO docs section for details of the relevent GPIO lines to toggle on your device).

When doing a PPP dial out the system will give you exit codes showing what went wrong in the process (man pppd - exit status) These are useful for debugging the situation, the most common issues are apn/password details incorrect/spelt wrong, inadequate signal, cellular base station congestion.

Once a network connection is made it is a good idea to check periodically that the internet network connection is still valid by making an 'end-to-end' remote server check (especially so if the modem is using the standard consumer APN credentials)

This is largely down to how cellular network providers organise thier base stations and have a tendency to "mute" your connection, as opposed to just cutting it entirely, if you are deamed to be hogging your local cellular base station slot for long periods with relatively low data volumes in preference to keeping slots available for other users in order to maximise overall service availability.

Here your connection may appear valid, but any data transfers to remote server(s) (e.g. VPN links or payload data transfers) will fail and it becomes necessary to restart the connection to "refresh" the connection.

A reliable method for validating the current end-to-end connectivity state is via a curl http request (ideally to a page on your target server, which you have control over)to check the last modified time stamp of the webpage, this uses the minimum byte transfer count whist still performing a standard web http request :

curl -I -s --connect-timeout 5 --max-time 10 | grep "HTTP/1.1 200 OK"

Using the success/fail error code (of the grep command on the end) is a pretty good indication on the viability of the comms connection. We have found that using curl to simulate a web request more reliable than using ping as network providers often break ping functionality, usually to mitigate DDoS attacks

If that network check fails 3 times in a row then you should consider the internet connection bad and bring the connection down and back up again to re-stablish connectivity, if the problem persists a software reboot of the modem using the AT command above should be tried, if that also fails give the modem a hardware reset using the relevent GPIO line (allowing time either side for the modem and OS to react)


A common "gotcha" is getting the APN details wrong, sometimes the error messages received can be a bit cryptic, see below example of what results of an incorrect APN name :




Modem gets valid LTE signal, but will not register on the network


In this case the antenna was conencted to the DIV (diversity) antenna port and not the MAIN port


qmi-network start problem with Raspbian 9, reports below error on starting network

error: "couldn't start network: QMI protocol error (64): '(null)'.

There looks like a minor problem with the scripting in libqmi-utils package version 1.16.2 that prevents dialout via the qmi command line utilities, see below link for information and solution :

Bug Report with Fix

Here are some useful links containing more information :

APN details for world wide Cellular networks -- List #1

APN details for world wide Cellular networks -- List #2

Sierra Wireless Modem AT Commands

Contact us now to discuss your project

Ready to order, contact us today for pricing or samples

Contact Us