Monitor Sierra Wireless 5G signal?

Thomas Eiszler

@pthomason I, too, am trying to find a way to get the signal strength periodically to build a coverage map of our 5G CBRS deployment. It seems like qmicli can be used for this purpose, but it doesn't give me anything interesting when I query for the signal information:

voxl2:/$ qmicli -d /dev/cdc-wdm0 --device-open-proxy --nas-get-signal-info
[/dev/cdc-wdm0] Successfully got signal info

Has anyone successfully retrieved the signal information from voxl?

Update:

I also tried the following from another post, but the 5G Sierra Wireless modem is not on ttyUSB2, so I am not sure how to address it.

echo -ne "AT+QENG=\"servingcell\"\r" | busybox microcom -t 1000 /dev/ttyUSB2

lsusb shows it is on bus 002, device 003.

voxl2:/dev/bus/usb/002$ lsusb
Bus 002 Device 003: ID 1199:90e3 Sierra Wireless, Inc.

groupo

@Thomas-Eiszler Hey Thomas

I will save you some time I ran into this issue within the past few months as well. I believe Modal AI is using drivers that predate the SW EM9291. I figured out how to send the commands and submitted the info to them. Hopefully they are able to implement it in an upcoming release. I will attach the same documentation I sent them.

######################################################
AT Commands to EM9291 Modem (SDK 1.3.0)

lsusb (to see device VID/PID)

voxl2:/$ lsusb
Bus 002 Device 003: ID 1199:90e3 Sierra Wireless, Inc.
Bus 002 Device 002: ID 0424:5744 Standard Microsystems Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0424:2740 Standard Microsystems Corp.
Bus 001 Device 003: ID 0bda:0811 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 0424:2744 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

echo VID and PID to this directory

voxl2:/$ echo 1199 90e3 > /sys/bus/usb-serial/drivers/option1/new_id

You can see dmesg output:
[ 72.620475] option 2-1.1:1.3: GSM modem (1-port) converter detected
[ 72.621037] usb 2-1.1: GSM modem (1-port) converter now attached to ttyUSB0
[ 72.621318] option 2-1.1:1.4: GSM modem (1-port) converter detected
[ 72.623288] usb 2-1.1: GSM modem (1-port) converter now attached to ttyUSB1

You can now send AT commands to USB0. I included Sierra Wireless’ qcserial driver in email to Travis that comes from (their?) Mobile Broadband Package for Linux (MBPL). Notice the EM9291 that is defined in there under SDX55 (I think something to do with Snapdragon) has ttyUSB0 as the AT command port, instead of older Sierra modems using ttyUSB2.

I send AT commands like so:
voxl2:/$ echo -ne 'AT!entercnd="A710"\r\n' | busybox microcom -t 1000 /dev/ttyUSB0

Sometimes AT commands returns +CME ERROR if you send commands too fast/don’t wait for reply from earlier command. An example is running AT+COPS=? then running another command before that returns its result. If this happens, I have found this always works to free up that port:
rm -rf /var/locl/LCK…ttyUSB0

You can read more about this solution here:
https://forum.sierrawireless.com/t/em9191-does-not-bring-up-the-serial-interface-works-in-mbim-only-usb-composition/24783/3

Thomas Eiszler

@groupo Thanks for the tutorial! It didn't work the first time I echoed to new_id, but after I restarted the VOXL, the second time the kernel picked it up and created the ttyUSB0 device. Now I just need to figure out what command to use to get the signal strength. So far, most of the commands I have tried either yield no output or 'ERROR'. Progress by degrees...

voxl2:/$ echo -ne "AT+QENG=\"servingcell\"\r" | busybox microcom -t 1000 /dev/ttyUSB0
AT+QENG="servingcell"
ERROR
voxl2:/$ echo -ne 'AT!LTEINFO?' | busybox microcom -t 1000 /dev/ttyUSB0
AT!LTEINFO?voxl2:/$ echo -ne 'AT+COPS=?' | busybox microcom -t 1000 /dev/ttyUSB0
AT+COPS=?voxl2:/$
voxl2:/$ echo -ne 'AT!NRINFO?' | busybox microcom -t 1000 /dev/ttyUSB0
AT!NRINFO?voxl2:/$

Thomas Eiszler

@Thomas-Eiszler Rather than echoing commands, I just went into the microcom shell and interactively ran some commands. AT+COPS? took a long time, and then afterwards, other commands also seemed to work, so I think it was perhaps the -t flag that was causing it to exit prematurely. Or something with redirection of stdout/stderr...

groupo

@Thomas-Eiszler Make sure you specifically run AT!entercnd="A710" after enumerating the modem. This is the password for the modem that 'unlocks' it. Afterward, it produces much more verbose outputs for most commands. I forget a good example, maybe !lteinfo. You can read about it here

How did you go into the microcom shell to do that? That would be useful. I am a pretty new linux user I could never figure out how to do anything besides echoing. But yes, you are right, +COPS? does take some time and if you use the -t (timeout) flag and send another command before that has returned you can get into that weird state I described above where you must rm -rf /var/locl/LCK…ttyUSB0

Try the A710 command first and then all other commands and let me know if that resolves it. I have a simple shell script I think i will try to make a service out of that runs new_id & A710 steps so that the modem is ready to go when I turn the drone on. Havent done that yet but if you are more savvy than myself and choose to do that lemme know!

Thomas Eiszler

@groupo To get a shell, you just do

busybox microcom /dev/ttyUSB0

Without the echo, it will just wait for your input and output the result after you type each command and hit enter. CTRL-X will return you to the voxl2 shell. i.e.:

voxl2:/$ busybox microcom /dev/ttyUSB0
AT!NRINFO?
!NRINFO:
Connectivity Mode: SA

NR5G Cell ID:    8001 (32769)
NR5G band:       n48       	        NR5G Carrier ID: 0
NR5G dl bw:      40 MHz    	        NR5G ul bw:      40 MHz
NR5G Tx Power:   ---        	        NR5G Tx chan:    0
NR5G Rx chan:    638856
NR5G dl MIMO:    4         	        NR5G ul MIMO:    1
NR5G(sub6) Rx0 RSSI (dBm):   -39.9	NR5G(sub6) Rx1 RSSI (dBm):   -44.8
NR5G(sub6) Rx2 RSSI (dBm):   ---  	NR5G(sub6) Rx3 RSSI (dBm):   ---

NR5G RSRP (dBm): -68		                NR5G RSRQ (dB):  -11
NR5G SINR (dB):  21.0


OK

I think the reason I wasn't getting output via echo, was because I forgot to send it the carriage return-line feed so it was still effectively 'waiting for me to press ENTER'.

voxl2:/$ echo -ne 'AT!NRINFO?\r\n' | busybox microcom -t 1000 /dev/ttyUSB0
AT!NRINFO?
!NRINFO:
Connectivity Mode: SA

NR5G Cell ID:    8001 (32769)
NR5G band:       n48       	        NR5G Carrier ID: 0
NR5G dl bw:      40 MHz    	        NR5G ul bw:      40 MHz
NR5G Tx Power:   ---        	        NR5G Tx chan:    0
NR5G Rx chan:    638856
NR5G dl MIMO:    4         	        NR5G ul MIMO:    1
NR5G(sub6) Rx0 RSSI (dBm):   -41.0	NR5G(sub6) Rx1 RSSI (dBm):   -53.4
NR5G(sub6) Rx2 RSSI (dBm):   ---  	NR5G(sub6) Rx3 RSSI (dBm):   ---

NR5G RSRP (dBm): -67		                NR5G RSRQ (dB):  -11
NR5G SINR (dB):  21.0


OK

groupo

@Thomas-Eiszler glad we were both able to learn something, thank you

Thomas Eiszler

@groupo Our goal is to use the Starling MAX with 5G to build a coverage map of our CBRS network. So I am planning to write a small bash script to periodically do AT!NRINFO? and AT!GPSLOC? alongside a timestamp. Then in post processing we can use the data to construct a heat map to see the extent. Once I get things working the way I want, I can share the script here if it would be useful to you.

groupo

@Thomas-Eiszler yeah that would be great! it sounds like you would want to create a service to do that? That way it happens automatically, you need not manually start it each time... if you do go down that route I would be especially interested. Ive not yet made my own service but I think I will need to

pthomason

@Thomas-Eiszler That's the plan we're working towards also, I did make some tries with AT commands also, but had to put the work aside for other commitments in the past few weeks. The information from yourself and @groupo above helps a lot. It shouldn't be too hard to make a service out of a python script for this. I'd been pursuing getting the data direct from the Qualcomm chipset, but AT commands and gpsd queries seen to be the way to go.