-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: RAK12500 GPS Checksum Failures #3779
Comments
A few things to try, update to a more recent firmware (yeah they always say that), try removing the RAK 1901. See if anything changes, I don't have a RAK 12500 to test with, but I have seen GPS checksum failures on ESP32 platforms with different GPSs. |
I have a 12500 and 13002 on order, and will be able to investigate further soon. |
Rak19700 + Rak4631 + Rak12500 here...no environmental sensor. I'm seeing an incrementing number of GPS checksum errors. It seems like the 12500 is working, however. I believe there's not always an instant update between the GPS internal location data and what it's sent to the app...don't quote me on this exactly, but I believe it can be up to a minute before it updates the client app via Bluetooth. Regardless, I'm happy to help test anything...I just got my Rak12500 so wasn't sure if the checksum errors were anomalous or not, as it seems like I'm tracking satellites and getting location updates reasonably well enough. I have noticed what feels like an inordinately long time (~3-5 minutes)before I get a GPS lock from a cold-start with an open sky picture...relative to what I'm used to on a cell-phone, for instance...but as I said I just got my 12500 recently so wasn't sure of what to expect on that front. LMK if I can help provide any diagnostic data. Regards! Edit: Adding, I'm seeing this on two different Rak12500's installed on any number of three 19700/4631 combo's...same experience on all iterations of those, so I'm reasonably sure it's not a hardware issue. All other aspects are identical. |
It's just a hunch, but I think it might be a TinyGPS+ issue. It also may be related to the NRF52 running at ~60MHz and not being able to handle the workload. Neither has any basis in fact as yet, but I'm certain that the Zoe is producing correctly checksummed NMEA sentences. |
FWIW, I'm starting to see some additional inconsistencies on my two Rak12500's. Namely, about 25% of the time, they will just never get lock. I've left one overnight, outside, with a clear sky picture and it'll just never get a lock. What I've found is that by constantly rebooting it, I can often make it lock...simply by rebooting it again. If it doesn't obtain a lock within 5 minutes, it's almost never going to, so reboot, wait 5, if not locked, try again. Also, and I don't mean to conflate issues, but feel it's worth mentioning, my accuracy while locked it terrible. I'm seeing up to a 100 meter discrepancy between every successive position update. I did test by moving my 12500's to slot D on the 19700 but obtained the same results. Same results on the alpha and previous two beta firmwares. Same results on two independent units. It really seems like every time I try to plug myself in to USB to troubleshoot, I get a lock almost immediately after plugging in. Once again, glad to run any tests, collect any logs or diagnostics if that would be helpful. I've got two 12500's to test with, and two. 19700/4631 combos. |
Remove NMEA sentences that are not processed by TinyGPS++ or Meshtastic.
* 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. * Address Issue #3779 RAK12500 GPS Checksum failures Remove NMEA sentences that are not processed by TinyGPS++ or Meshtastic. --------- Co-authored-by: Jonathan Bennett <[email protected]> Co-authored-by: Ben Meadors <[email protected]>
Category
Hardware Compatibility
Hardware
Rak4631
Firmware Version
2.3.4.ea61808
Description
DEVICE:
Rak Wisblock
Baseboard: RAK19007
Core: RAK4631
GPS: RAK12500
Temp/Hum Sensor: RAK1901
PHONE:
Samsung S21, Android 14, Mesthtastic App 2.3.4
I appear to be having an issue with the GPS. It works about 50% of the time but I am getting Checksum failures and the Device doesn't appear to be sending its position to the phone for display in the app often or sometimes at all. Anyone run into this?
The attached log shows a different location and a different number of sats in view vs my phone.
Relevant log output
The text was updated successfully, but these errors were encountered: