SensorGnome GPS reporting no-dev with SixFab Raspberry Pi 4G/LTE Cellular Mode

Hello,

I’m back working on my testbed SensorGnome v2, running on a Raspberry Pi 4 with a SiXFab Raspberry Pi 4G/LTE Cellular Modem HAT. Currently, the GPS pane on the main web interface tab is reporting “no-dev” for the GPS.

Everything else looks okay. The modem is reporting a power state of “on”, capabilities gsm-umts, lte", and model “LE910C4-AP”. The SixFab SIM card is in place (although not yet activated on the SixFab website), and the state is reporting “enabled”. Network connectivity is all good, over the local WiFi network. I’ve double-checked the connections for the ribbon antennae supplied with the kit against the SixFab guide, and they seem to be correctly configured. I have the FunCube disconnected at the moment to reduce power consumption.

The system is a Raspberry Pi 4 (machineID: SG-E3E4RPI4CED5), running version SG 2024-271, with 1.8 GB memory and a 24 GB SD card. I’ve done a software update on both the SensorGnome software and the system software, and both are reporting up to date on a software update check.

I’ve attached a copy of the boot logs for reference.

Any suggestions for what I should try next? I’ve run the installation from scratch a couple of times, still with the same result.

  Regards
    Andrew Hide

SG-E3E4RPI4CED5-2024-11-20T12_43_12.097Z-logs.zip (80.4 KB)

This is a problem, unfortunately. The modem fails to connect and gets reset to retry and this keeps repeating. The GPS does get detected but the connection gets broken when the modem restarts. Please try to remove the SIM card altogether, although that used to not work either due to a different problem :roll_eyes: and right now I forget whether I managed to work around it or not. It may be simpler to activate the SIM card for a short period or to pop out your phone’s SIM card (if you have a physical SIM) and stick it into the HAT’s modem. Have an adapter cut out handy (the SIM in your phone is likely smaller)…

Sorry for the hassle, this is a bit voodoo stuff…

Hello,

No apology needed, the idea of having a test rig is to be able to work through the quirky setup issues :slight_smile: . Thank you for all the help and suggestions, it’s very much appreciated.

I tried again with the SIM card removed completely, and as predicted, that also didn’t work.

I’ve now set up the SIM card on the SixFab website, made it active, and assigned some credit to the Asia-Pacific data pool for it. The Network tab on the web interface is reporting an “enabled” status, and still searching for an LTE connection. (It reports all three all three of the network carriers you’d expect to see in Australia as being “lte, available”).

Have I missed a step with the configuration on the SixFab site somewhere? I wasn’t sure if it was necessary to configure SixFab CORE or nor, so I haven’t touched that yet.

Regards Andrew Hide

Hello,

  Followup to the previous message: I managed to get hold of a SIM adapter, and plugged my personal mobile phone SIM card into the SixFab LTE modem.

  This time the mobile data network connection came up immediately, so there's obviously still a problem with the activation on the SixFab SIM. I'll drop them a message and see if I can sort that out, to begin with.

  However, even with a working mobile data network connection, the GPS status still came up as "no-dev" after a couple of reboot cycles.

  I've attached a new set of logs for reference: 

SG-E3E4RPI4CED5-2024-11-26T11_30_32.106Z-logs.zip (1.5 MB)

  Thank you again for the assistance with trying to puzzle out my mysterious failures here.


  Regards
    Andrew Hide

Follow up to the previous message: I managed to get hold of a SIM adapter, and plugged my personal mobile phone SIM card into the SixFab LTE modem.

This time the mobile data network connection came up immediately, so there’s obviously still a problem with the activation on the SixFab SIM. I’ll drop them a message and see if I can sort that out, to begin with.

However, even with a working mobile data network connection, the GPS status still came up as “no-dev” after a couple of reboot cycles.

I’ve attached a new set of logs for reference:

SG-E3E4RPI4CED5-2024-11-26T11_30_32.106Z-logs.zip (1.5 MB)

Thank you again for the assistance with trying to puzzle out my mysterious failures here.

Hey, they’re not your failures, they’re the SIM’s or the modem’s failures! :wink:

So the cellular connection comes up immediately without issue, despite having the wrong APN. The GPS device is detected and enabled but then nothing happens, not even an error. Not sure what to think. Are you comfortable ssh’ing into the rPi and issuing some commands?

I will be working on the SG software today and my station has the same telit modem, so I’ll see whether I can come up with some simple troubleshooting ideas.


Updated 2x:

If you can put your working SIM card into the modem again and SSH into the SG you could try the following commands and paste the result here:

first mmcli -L to list the modems, notice the 0 after Modem in the response:

gnome@SG-7F5ERPI46977 ~> mmcli -L                                                              
    /org/freedesktop/ModemManager1/Modem/0 [Telit] LE910C4-NF                                  
  • then get information about location (GPS), use the modem number after the -m option:
gnome@SG-7F5ERPI46977 ~> mmcli -m 0 --location-status                                       
  ------------------------
  Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msb
           |      enabled: 3gpp-lac-ci, gps-nmea
           |      signals: no
  ------------------------
  GPS      | refresh rate: 30 seconds

The key is to see gps-nmea as enabled. I don’t know what “signals: no” means.

It may be helpful to get a general info about the modem:

gnome@SG-7F5ERPI46977 ~> mmcli -m 0                                  
  ----------------------------------
  General  |                   path: /org/freedesktop/ModemManager1/Modem/0
           |              device id: 69b580f5cb29c45e584c21118098565c831ab3a6
  ----------------------------------
  Hardware |           manufacturer: Telit
           |                  model: LE910C4-NF
           |      firmware revision: 25.21.660  1  [Mar 04 2021 12:00:00]
           |         carrier config: default

[... about 30-40 lines ...]                                                

See what the GPS says:

gnome@SG-7F5ERPI46977 ~> gpsmon
tcp://localhost:2947          NMEA0183>
┌──────────────────────────────────────────────────────────────────────────────┐
│Time: 2024-11-26T23:03:52.000Z   Lat: 34 29.940000' N   Lon: 119 49.070000' W │
└───────────────────────────────── Cooked TPV ─────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────┐
│ GPGSV GPGGA GPGLL GPRMC GPGSA                                                │
└───────────────────────────────── Sentences ──────────────────────────────────┘
┌───────────────────────┌─────────────────────────┌────────────────────────────┐
│ SVID  PRN  Az El SN HU│Time:     230352.00      │Time:      230352.00        │
│GP  2    2  94 13 22  Y│Latitude:  3429.940000 N │Latitude:  3429.940000      │
│GP  5    5 271  7 34  Y│Longitude:11949.070000 W │Longitude: 11949.070000     │
│GP  7    7  91 45 32  Y│Speed:    0.0            │Altitude:  636.6            │
│GP  8    8  40 13 36  Y│Course:   308.2          │Quality:   1   Sats: 12     │
│GP  9    9 158 10 33  Y│Status:   A        FAA:A │HDOP:      0.5              │
│GP 13   13 312 35 36  Y│MagVar:   14.1 E         │Geoid:     -22.0            │
│GP 14   14 296 66 33  Y└───────── RMC ───────────└─────────── GGA ────────────┘
│GP 17   17 180 37 36  Y┌─────────────────────────┌────────────────────────────┐
│GP 19   19 194 11 36  Y│Mode: A3 Sats: 2 5 7 8 + │UTC:           RMS:         │
│GP 21   21  75 11 36  Y│DOP H=0.5  V=0.6  P=0.8  │MAJ:           MIN:         │
│GP 22   22 264 50 37  Y│TOFF:  0.025676591       │ORI:           LAT:         │
│GP 30   30  32 70 33  Y│PPS: N/A                 │LON:           ALT:         │
└───↓──── GSV ──────────└────── GSA + PPS ────────└─────────── GST ────────────┘
(82) {"class":"VERSION","release":"3.22","rev":"3.22","proto_major":3,"proto_min
or":14}
(293) {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyGPS","driv
er":"NMEA0183","activated":"2024-11-26T23:03:49.023Z","flags":1,"native":0,"bps"
:9600,"parity":"N","stopbits":1,"cycle":1.00},{"class":"DEVICE","path":"/dev/pps
0","driver":"PPS","activated":"2024-11-26T23:03:10.224Z"}]}
(122) {"class":"WATCH","enable":true,"json":false,"nmea":false,"raw":2,"scaled":
false,"timing":false,"split24":false,"pps":true}
(72) $GPGSV,4,1,15,02,13,094,23,05,07,271,34,07,45,091,31,08,13,040,36,1*6F
(72) $GPGSV,4,2,15,09,10,158,33,13,35,312,36,14,66,296,33,15,05,320,21,1*68
(72) $GPGSV,4,3,15,17,37,180,36,19,11,194,36,21,11,075,36,22,50,264,37,1*6D
(52) $GPGSV,4,4,15,30,70,032,32,20,00,241,,46,,,37,1*67
(77) $GPGGA,230350.00,3429.940000,N,11949.070000,W,1,12,0.5,636.6,M,-22.0,M,,*56
...

This shows that my station’s GPS has a fix and I see the lines with a $GPG prefix scroll by. I had to restart gpsmon a couple of times, however, it was just showing some cryptic info (JSON). I wonder what it shows for you…

GPS should work even when the modem doesn’t connect

I changed the SIM card in my modem for one that doesn’t have service so the modem retries connecting all the time, just like in your case. The GPS works fine nevertheless. So there’s something fishy about your modem… It’s the same model, just AsiaPac version.

Notes:

If you copy/paste the output here please put it between two lines with three backticks ```. You can also make a section collapsible by selecting it and using the “hide” option in the gear icon at the top of the forum text entry box.

Sooo, my modem eventually connected. Unfortunately it happened about 2 minutes after I stopped the sensorgnome service (the main software that runs the sensorgnome data processing and web ui). Now I don’t know whether there’s causation or just correlation… The sensorgnome service doesn’t tell the modem to do anything, it just queries its state, but who knows. I didn’t take note of the time when I swapped the SIM card but I think it was around 7 hours ago. So one version is that it took the SIM card 7 hours to connect, the other is that it tooke the SIM card 2 minutes to connect after the sensorgnome service was stopped.

You could try via SSH:

  • stop the sensorgnome service (no more web interface after this)
sudo systemctl stop sg-control
  • ignore the SG for at least 10 minutes, then check the cellular connection:
mmcli -L
mmcli -m 0

(The first command is to list the modems so you know which number it got assigned, then use that for the second command.)

Look in the status section whether it says “connected”:

  Status   |                   lock: sim-pin2                                                
           |         unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), sim-puk2 (10)  
           |                  state: connected                                               
           |            power state: on                                                      
           |            access tech: lte                                                     
           |         signal quality: 94% (recent)                                            

If it doesn’t, let it sit for an hour and run the same mmcli command again to check the status.

If it says connected you can make sure it’s usable. Run ip route and look for a line with dev wwan0:

default via 100.64.0.1 dev wwan0 proto dhcp src 100.64.0.2 metric 10001 mtu 1430 

This means linux thinks it can route to the internet via the cellular network device. You can now try it out by pinging 1.1.1.1 (cloudflare dns service):

gnome@SG-7F5ERPI46977 ~> ping -I wwan0 1.1.1.1
PING 1.1.1.1 (1.1.1.1) from 100.64.0.2 wwan0: 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=324 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=212 ms

(That’s a capital i in -I)

I just did a power cycle on my SG (only way to really reset the modem) and it connects right away. So I guess now I can’t test a non-connecting SIM card anymore… :roll_eyes:

Hello!

Thank you for all the suggestions, I will start working through them. (My background is software engineering with liberal chunks of sysadmin and systems integration, so I have no qualms about getting into the RPi CLI - in fact, I have a monitor and keyboard plugged into it as a console for just that reason :slight_smile: ).

One bit of good news for today, the SixFab SIM has sprung to life mysteriously overnight, and the SG web interface is now reporting a good mobile network connection. I assume there was just some latency in the updates making their way through various databases.

For extra fun, it looks like the SixFab IoT kits are out-of-stock at the moment; so if my academic client wants to start doing conversions, I may have to prototype the Waveshare option as well. (However, sufficient unto the day is the evil thereof, etc… I’ll worry about that when I have one on hand.)

Anyway, one way or another, we shall figure things out!

Regards Andrew Hide

Alright, sounds like some good news!

I have not tried the Waveshare HAT, but at the end of the day they’re really just carriers for the modem M.2 card… Just don’t make the mistake I made to buy the USB-attached cell modem 'cause you can’t power it from the rPi.

If you have any questions don’t hesitate to reach out!

Edit: it looks like your GPS is not doing it… Do you have the GPS antenna connected and have you placed the SG outdoors with reasonably clear view of the sky? A window sill may work depending on the glass (solar radiation blocking “energy efficient” glass also tends to block GPS).

For anyone coming here in the future, I have captured the info and more in the SG user guide: https://docs.motus.org/sensorgnome-v2/software-installation/cell-modem-troubleshooting

Hello,

The mobile network connection is definitely up and running (I can ping the test address via wwan0 successfully). The GPS remains in its sulk :slight_smile:

I’ll put up the results of the diagnostics first:

gnome@SG-E3E4RPI4CED5:~ $ mmcli -L
    /org/freedesktop/ModemManager1/Modem/0 [Telit] LE910C4-AP
gnome@SG-E3E4RPI4CED5:~ $ mmcli -m 0 --location-status
  ------------------------
  Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msb
           |      enabled: 3gpp-lac-ci, gps-nmea
           |      signals: no
  ------------------------
  GPS      | refresh rate: 30 seconds
gnome@SG-E3E4RPI4CED5:~ $ mmcli -m 0
  ----------------------------------
  General  |                   path: /org/freedesktop/ModemManager1/Modem/0
           |              device id: fc9dd91daf3a558c4f3e01bd94e3abbfebe07f3a
  ----------------------------------
  Hardware |           manufacturer: Telit
           |                  model: LE910C4-AP
           |      firmware revision: 25.21.680  1  [Mar 04 2021 12:00:00]
           |         carrier config: default
           |           h/w revision: 1.20
           |              supported: gsm-umts, lte
           |                current: gsm-umts, lte
           |           equipment id: 357575100273804
  ----------------------------------
  System   |                 device: /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3
           |                drivers: option, qmi_wwan
           |                 plugin: telit
           |           primary port: cdc-wdm0
           |                  ports: cdc-wdm0 (qmi), ttyUSB0 (ignored), ttyUSB1 (gps),
           |                         ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net)
  ----------------------------------
  Status   |                   lock: sim-pin2
           |         unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (10), sim-puk2 (10)
           |                  state: registered
           |            power state: on
           |            access tech: lte
           |         signal quality: 88% (recent)
  ----------------------------------
  Modes    |              supported: allowed: 3g; preferred: none
           |                         allowed: 4g; preferred: none
           |                         allowed: 3g, 4g; preferred: 4g
           |                         allowed: 3g, 4g; preferred: 3g
           |                current: allowed: 3g, 4g; preferred: 4g
  ----------------------------------
  Bands    |              supported: utran-1, utran-6, utran-5, utran-8, eutran-1, eutran-3,
           |                         eutran-5, eutran-8, eutran-9, eutran-18, eutran-19, eutran-26,
           |                         eutran-28, utran-19
           |                current: utran-1, utran-6, utran-5, utran-8, eutran-1, eutran-3,
           |                         eutran-5, eutran-8, eutran-9, eutran-18, eutran-19, eutran-26,
           |                         eutran-28, utran-19
  ----------------------------------
  IP       |              supported: ipv4, ipv6, ipv4v6
  ----------------------------------
  3GPP     |                   imei: 357575100273804
           |          enabled locks: fixed-dialing
           |            operator id: 50501
           |          operator name: Telstra Mobile
           |           registration: roaming
           |   packet service state: attached
  ----------------------------------
  3GPP EPS |   ue mode of operation: csps-1
           |    initial bearer path: /org/freedesktop/ModemManager1/Bearer/0
           |     initial bearer apn: super
           | initial bearer ip type: ipv4v6
  ----------------------------------
  SIM      |       primary sim path: /org/freedesktop/ModemManager1/SIM/0
           |         sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active)
           |                         slot 2: none
  ----------------------------------
  Bearer   |                  paths: /org/freedesktop/ModemManager1/Bearer/1

The enabled list for the Location data includes the gps-enabled element.

The gpsmon command comes back with blank screen initially, then a “tcp://localhost:2947 Unknown device>” prompt after hitting Enter. So it doesn’t appear to be recognising the GPS.

Will the GPS device still appear on the web interface, even if it doesn’t have a position fix? Or does it need to get a fix before the modem HAT will make the GPS device accessible? I ran an extension lead outside and set up my test rig in the open air, with a clear view of at least 50% of the sky (which at my latitude [32 S] should have included a good chunk of the GPS constellation), and left it there for about twenty minutes without any change of status.

I was actually talking about the Waveshare 6700 USB modem dongle, rather than the HAT, though that might also be worth a try when I’m feeling adventurous.

Regards Andrew Hide

Andrew, I wrote up a bunch of troubleshooting steps for the GPS at Cell modem troubleshooting | Sensorgnome V2 User Guide, could you try these out? Please try a gpsd restart in particular.

The GPS info in the web interface is entirely dependent on gpsd so if gpsd (e.g. via gpsmon) doesn’t know about the GPS then the web ui can’t show anything. Gpsd only knows about a GPS after it receives and can parse some stanzas.

I cannot recommend this unit for use with a Sensorgnome or rPi in general. The problem with it is that it is powered through USB and the rPi cannot provide enough power. It will seemingly work but not maintain a reliable connection. I have one and had to solder some power cables into the unit to power it separately. You can, of course use a powered hub, but that’s also extra expense and another power adapter to deal with. (Plus some powered hubs backfeed power into the rPi, which is not a great situation either.) This is why a HAT is really recommended. (More info on Sensorgnome power and these issues at Sensorgnome power | Sensorgnome V2 User Guide)