I have two LILY TTGO T-Beam v1.1 units running firmware 2.1.17.7: INFO | ??:??:?? 1 Meshtastic hwvendor=4, swver=2.1.17.7ca2e81
At all times, these units show “No GPS Module” on the OLED status screen.
However, the GPS appears to be functioning and useful.
The GPS Red LEDs blink once per second, and in sync. DEBUG | ??:??:?? 60 [GPS] GPS is not communicating, trying factory reset on next bootup.
Is in the log, but it appears to correct itself later when a Position is requested: Module 'position' wantsPacket=1
and the correct clock time is updated Upgrading time to RTC 1688540938 secs (quality 2)
Both screens show correct distance/relative position, and the logs show good lat/lon responses.
I’m not sure what to make of this. I did find some bugs discussed in the past here, about GPS not working in Dec '22, but this looks like a different in-between issue.
From what I can tell, the GPS is working, yet the UI doesn’t appear to know it.
Perhaps it latched onto the no-GPS-Module during boot, and later connected but did not update the status?
I’ve used these same T-Beams with other (LoRaWAN) firmware, where the GPS performed very well, so I have no reason to suspect the GPS is actually wonky. Both are the same ublox M6 units.
Any ideas? I know I’m on Alpha, but happy to help debug if this is not a known issue.
Thanks!
Thanks for pointing this out. There is likely a bug with the GPS status reporting that was introduced in 2.1.16, as someone on Discord pointed this out as well. Hopefully this will be fixed in a next release, but you could also downgrade to the latest beta (2.1.15), which works fine.
Is it possible that the U-Blox Neo-6M in the T-Beam v1.1 does not support the UBX-CFG-GNSS command that is being sent during init?
I don’t see any mention of that command (Class 6, 0x3E) in the Protocol 6 these modules use:
Instead, 6 (v14) uses UBX-CFG-SBAS only, and doesn’t support Glonass at all.
(only GPS, SBAS, WAAS, EGNOS, MSAS)
I do see this command in v15 (used by u-blox M8).
The UBX-CFG-ITFM is supported, but also returns a failure. The docs suggests a different config word should be used here. Every boot looks something like:
DEBUG | ??:??:?? 1 WANT GPS=1
WARN | ??:??:?? 2 No response for class 06 message 3E
WARN | ??:??:?? 2 Unable to reconfigure GNSS, keep factory defaults
WARN | ??:??:?? 4 No response for class 06 message 39
WARN | ??:??:?? 4 Unable to enable interference resistance.
WARN | ??:??:?? 5 No response for class 06 message 23
WARN | ??:??:?? 5 Unable to configure extra settings.
WARN | ??:??:?? 7 No response for class 06 message 01
WARN | ??:??:?? 7 Unable to disable NMEA GGL.
DEBUG | ??:??:?? 7 GxGSA NOT available
WARN | ??:??:?? 7 GPS FactoryReset requested
The NAVX5 configuration message is also “too advanced” for Neo-6M, which has no ADR.
All in all, this feels like the code really wants an M8 module instead of our 6M?
I suppose I just don’t understand how TinyGPS++ is working with this Neo-6M.
The Meshtastic code has some hard-coded UBX packets that enable/disable different NMEA sentences, and then… the library is supposed to parse them and report updated positions.
What I can’t figure out is this:
The Position request works fine. Nothing else appears to work – no UI elements show live GPS stats, but the clock is correct. So how does the GPS “half-work”?
I’ve tried taking out all the messaging that is incompatible with T-Beam v1.1 6M module. The other packets confirm correctly.
and yet gps->getIsConnected() is always false.
GPS::runOnce() doesn’t appear to call setConnected() but why?
Why doesn’t it see one of the NMEA messages that it requested?
No mistake @claesg – I think you’re onto the right idea here.
I’ve used these T-Beams extensively for Helium Mapping, where my software probes the GPS, sets it to 115200bps and then saves those settings. I don’t see any kind of probe/autobaud in the Meshtastic code, so maybe that’s related. That is, the settings saved in the module are incompatible (partly?) with Meshtastic and the code to reset-to-defaults isn’t working quite right.
If there’s interest, I’ll see if I can split the UBlox support into detecting Module 6 (v14) with Module 8 (v15) protocols, autobaud and configure it from scratch each boot. Today the code appears to not probe at all, and just assume TBeam has a Module 8, and ignore all the failed commands. Could be better. I haven’t worked with TinyGPS++ before, but written similar code.
In my experiments elsewhere, if you want to run full NMEA sentences (instead of UBLOX polling), it helps to have a higher bitrate… less CPU activity, less message stacking.
I’ve used these T-Beams extensively for Helium Mapping, where my software probes the GPS, sets it to 115200bps and then saves those settings. I don’t see any kind of probe/autobaud in the Meshtastic code, so maybe that’s related. That is, the settings saved in the module are incompatible (partly?) with Meshtastic and the code to reset-to-defaults isn’t working quite right.
Yes, it’s related, please use the default baud rate.
In my experiments elsewhere, if you want to run full NMEA sentences (instead of UBLOX polling), it helps to have a higher bitrate… less CPU activity, less message stacking.
No, it’s not true, higher bitrate => more power, more bugs for DIY wiring. Also, why did you set 115k speed, what is the update rate of your GPS module?
Yes, it’s related, please use the default baud rate.
Alright, I’ll set up for 9600. Can I add some code to auto-baud if the GPS isn’t found at 9600? Since we never know what software ran before, it’s a good recovery path.
No, it’s not true, higher bitrate => more power, more bugs for DIY wiring. Also, why did you set 115k speed, what is the update rate of your GPS module?
I use 500mS update rate, but Tracking is more demanding of fresh and frequent GPS updates when in fast motion.
myGNSS.setNavigationFrequency(2); // Produce X solutions per second
I’ve measured the low-power draw of GPS modules and haven’t seen a difference, but Meshtastic supports a very wide array of devices, and I’ve only measured the Heltec and TTGO platforms.