Modemmanager: Mmcli Get Signal Strength

ModemManager: Signal-/cell information report functionality

ModemManager has a "Signal interface" which, if supported by the modem implementation, allows to retrieve detailed per-technology signal quality values (e.g. RSRP/RSRQ for LTE).

You can enable the periodic gathering with mmcli --signal-setup=[RATE] (RATE being how often to get those values, in seconds). Once enabled, you can query which are the last retrieved values with mmcli --signal-get.

Another option you may want to use is to just run qmicli -p --nas-get-signal-info periodically yourself in a shell script; just make sure you use the -p option so that your commands can work at the same time as ModemManager is running (by using the intermediate qmi-proxy)

Is it possible to read signal quality from GSM/CDMA modems while connected?

As far as I am aware you can use AT+CSQ command to receiving the signal quality. This is independent of whether the modem is connected to an operator or not. My experiences have been with Wavecom, Siemens, and Sierra Wireless modems.

Request:

AT+CSQ=?

Response:

+CSQ: <rssi>,<ber>

Where <rssi> is received signal strength indication and <ber> is the bit error rate.

There is also the possibility of getting regular unsolicited updates but this is normally modem/manufacturer specific. For example Wavecom modems use AT+CCED, Siemens use AT^SMOND.

Can two IoT applications access a cellular modem at the same time so I don't have to kill ModemManager and lose my internet connection?

I think I've mostly figured it out now, without having to kill ModemManager (which risks killing the internet connection on the IoT remote gateways).

The main answer is that I'm simply not getting a GPS fix (permissions issues aside).

I wasn't doing anything wrong in my Python code, and sometimes ModemManager was using the AT port I was sending commands to (either /dev/ttyUSB2 or /dev/ttyUSB3)... Upgrading ModemManager to v1.10.0 also might work, but I'm reluctant to do that on a live gateway working in the field.

@rm5248 suggested using the dedicated NMEA port at /dev/ttyUSB1 on a SIMCom 7600 like mine, and he was right, I think.

I installed GPSD (GPSDaemon) and the various clients for it (e.g. cgps and gpsmon) using this documentation. GPSD and its clients are excellent for getting GPS info, if the GPS has a fix.

How to test the GPSD software:
https://gpsd.gitlab.io/gpsd/installation.html#_how_to_test_the_software

# Start GPSD on /dev/ttyUSB1 with debug level 5, 
# -N (don't daemonize), and -n (don't wait for 
# client to connect to poll GPS)

# no daemon, for debugging
$ sudo gpsd -D 5 -N -n /dev/ttyUSB1

# daemonized to run in background
$ sudo gpsd -D 5 -n /dev/ttyUSB1

Then run one of the following two clients and watch the dedicated NMEA port on /dev/ttyUSB1, as opposed to an "AT" port at /dev/ttyUSB2 or /dev/ttyUSB3:

$ cgps
$ gpsmon /dev/ttyUSB1

On a working gateway cgps works like this:

And gpsmon /dev/ttyUSB1 works like this:

But on a non-working gateway cgps looks like this, showing NO FIX:

---

Related Topics