[Bug]: GPS Checksum errors, HGLRC M100_MINI #3310
Comments
|
@GPSFan any ideas? |
|
How did you connect the gps to your Heltec board? Does it have the GPS power switched by a mosfet? |
|
Does this GPS module have a battery for config backup? I can't tell from the pictures on Amazon. If it does not, power cycling it will loose the config, but Meshtastic won't know this. The default baud rate for this module is 38400, so if the config is lost the baud rates will be out of sync. The same thing could happen even it the GPS module has a battery, but it hasn't had enough power on time to charge. |
|
I'll do some testing with my modules this weekend and see if I can replicate the issue. |
|
I have the GPS connected as follows:
My understanding is that the 5V line comes (almost) directly off of the USB and doesn't go through a power switching mosfet (see schematic). I'm not able to probe the pin with my multimeter at the moment, but I believe the power should be constant since I had it connected to my PC the whole time to get the serial logs. (For others following along: I plan to eventually move power over to the Heltec's Ve line (which I believe is switchable) but that's not how it is set up at the moment.) The GPS PCB is entirely dominated by the antenna on one side and an RF can on the other. There is no sign of a battery or capacitor, but its possible something lurks under the can. Any energy storage would have to be rather small; the (what appears to be) battery/cap on a BN-180 module that I also have looks like it would take up a not-insignificant portion of the RF can's volume. |
|
Some updates:
|
|
The complete power cycle re-initializes the GPS and thus sets the baud to 9600. If you leave the GPS powered for a while (several hours?) maybe the internal battery will charge enough for it to coast through the sleep period without losing the config. |
|
No luck leaving the GPS powered for a while. I discovered that the problem would not occur if I turned the update interval all the way down to 10 seconds. The logs appear to indicate that the GPS is not put to sleep for such a short interval. Slightly longer intervals like 30 seconds do put it to sleep, however. I let the system run with the 10 second interval yesterday for 19 hours. Over that time I did see random checksum failures, but no real problems. This morning I changed the config to 30 seconds and the problem immediately reappeared. If there is a battery or capacitor which needs to be charged, I assume 19 hours of charging should have been enough to handle a 30 second outage... Logs just prior to rebooting with the new config Logs after the config change look very similar to the initial post. |
|
That almost seems to indicate that either: |
|
Alright, I think I've been able to confirm that the GPS has some kind of battery-backed RAM: I don't have access to a Windows-based system, but was able to get u-center 23.08 working under Linux with Wine. I could see the position messages received from the GPS coming over over the Packet Console, as well as configuration messages being sent back and forth when modifying things in the Configuration View. I made a change to the device's baud rate (38400 -> 115200), first sending the change the device and then (after reconnecting at the new baudrate) saving the configuration to the BBR/Flash devices (the default selection). The GPS would reliably start up at 115200 when power was applied. I then removed power, and then reconnected after waiting 10 minutes. Once again, it connected at 115200. Just in case having "Flash" selected when saving the config was the cause, I reset back to 38400, saved the config to BBR/Flash, removed/reapplied power, verified the device was operating at 38400, and then once again changed the config to 115200 (except this time being sure to only select "BBR" before saving). After removing power for another 10 minutes and re-connecting, the device came up at 115200 again. |
|
Good to hear that someone other than me runs u-center under wine! IMHO it runs better under wine than on Windoze. |
* Portduino multiple logging levels * Fixes based on GPSFan work * Fix derped logic * Correct size field for AID message * Reformat to add comments, beginning of GPS rework * Update PM2 message for Neo-6 * Correct ECO mode logic as ECO mode is only for Neo-6 * Cleanup ubx.h add a few more comments * GPS rework, changes for M8 and stub for M10 * Add VALSET commands for u-blox M10 receivers * Add VALSET commands for u-blox M10 receivers tweak M8 commands add comments for VALSET configuration commands * Add commands to init M10 receivers, tweak the M8 init sequence, this is a WIP as there are still some issues during init. Add M10 version of PMREQ. * Add wakeup source of uartrx to PMREQ_10 The M10 does not respond to commands when asleep, may need to do this for the M8 as well * Enable NMEA messages on USB port. Normally, it is a good idea to disable messages on unused ports. Native Linux needs to be able to use GNSS modules connected via via either serial or USB. In the future I2C connections may be required, but are not enabled for now. * Save the config for all u-blox receiver types. The M10 supports this command in addition to saving using the VALSET commands for the RAM & BBR layers. --------- Co-authored-by: Jonathan Bennett <[email protected]> Co-authored-by: Ben Meadors <[email protected]>
|
Just FYI, I applied the fix on top of 2.2.23.5672e68 and the updated firmware is not experiencing the endless checksum failures anymore. The GPS seems to now always start up at 9600 baud instead of the 38400 that was its default. I assume that was intentional. |
|
Yes, Meshtastic really wants the GPS to run at 9600 baud, although only the u-blox modules are commanded to change from what they start out as to 9600. The UC6580 on the Heltec Wireless Tracker defaults to 115200, which is the lowest it can go, so Meshtastic leaves it alone. |
Category
Hardware Compatibility
Hardware
Heltec V3
Firmware Version
2.2.23.5672e68
Description
I've just purchased an HGLRC M100_MINI GPS module from Amazon and wired it up to my Heltec V3. After sorting out the RX/TX pins in the configuration, I've been able to get Meshtastic to read an initial position fix. Unfortunately, after this initial fix things stop working. The GPS goes to sleep, and when awoken 2 minutes later it reports an endless series of "GPS checksum failures" messages. This continues for 15 minutes, after which the system gives up and puts the GPS to sleep for another 2 minutes. When the GPS wakes up again, we run into more checksum failures.
Highlights from the serial log:
System probes for and finds the GPS module:
Shortly after the probe succeeds, an initial fix is obtained and the GPS is put to sleep:
The GPS is awoken 2 minutes later, but reports a bunch of checksum failures:
After 15 minutes of failures, the system gives up and puts the GPS back to sleep:
Two minutes later, the GPS is re-awoken and the checksum failures continue:
Relevant log output
logfile.txt
The text was updated successfully, but these errors were encountered: