Skip to content
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

Closed
BobsBlueNorth opened this issue May 3, 2024 · 5 comments
Closed

[Bug]: RAK12500 GPS Checksum Failures #3779

BobsBlueNorth opened this issue May 3, 2024 · 5 comments
Labels
bug Something isn't working

Comments

@BobsBlueNorth
Copy link

BobsBlueNorth commented May 3, 2024

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

INFO | 20:44:05 1485 [GPS] Setting GPS power=1

WARN | 20:44:05 1485 [GPS] 1 new GPS checksum failures, for a total of 8.

DEBUG | 20:44:07 1487 [GPS] WANT GPS=0

DEBUG | 20:44:07 1487 [GPS] GPS Lock took 2, average 7

INFO | 20:44:07 1487 [GPS] Setting GPS power=0

DEBUG | 20:44:07 1487 [GPS] Sleep Time: 112763

DEBUG | 20:44:07 1487 [GPS] publishing pos@66354c98:2, hasVal=1, Sats=6, GPSlock=1

DEBUG | 20:44:07 1487 [GPS] New GPS pos@66354c98:3 lat=61.309072, lon=-147.529347, alt=173, pdop=1.86, track=133.38, speed=0.00, sats=6

DEBUG | 20:44:07 1487 [GPS] onGPSChanged() pos@66354c98, time=1714769047, lat=613090720, lon=-1475293471, alt=173

INFO | 20:44:07 1487 [GPS] updatePosition LOCAL pos@66354c98, time=1714769047, latI=613090720, lonI=-1475293471, alt=173

DEBUG | 20:44:07 1487 [GPS] Setting local position: latitude=613090720, longitude=-1475293471, time=1714769047

DEBUG | 20:44:07 1487 [GPS] Node status update: 5 online, 8 total
@BobsBlueNorth BobsBlueNorth added the bug Something isn't working label May 3, 2024
@GPSFan
Copy link
Contributor

GPSFan commented May 3, 2024

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.

@GPSFan
Copy link
Contributor

GPSFan commented May 4, 2024

I have a 12500 and 13002 on order, and will be able to investigate further soon.

@polamnus
Copy link

polamnus commented May 5, 2024

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.

@GPSFan
Copy link
Contributor

GPSFan commented May 5, 2024

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.

@rc-adammikolajczyk
Copy link

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.
Finally, and this one seems weird, but I wanted to mention it, it seems like it almost ALWAYS obtains a lock within 3 minutes if it's plugged into USB-Serial. Is it possible, something about being plugged in, maybe something to do with power, is to blame?

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.

GPSFan added a commit to GPSFan/firmware that referenced this issue May 15, 2024
Remove NMEA sentences that are not processed by TinyGPS++ or Meshtastic.
thebentern added a commit that referenced this issue May 15, 2024
* 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 <jbennett@incomsystems.biz>
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants