-
Notifications
You must be signed in to change notification settings - Fork 15
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
sporadic 'no GPS data' #66
Comments
'no GPS data' arises as soon as date->valid == false. See OBP60Extensions.cpp lines ~210 ff. date is invalidated by main esp-nmea2000 code. |
No invalid dates occurred on M5Stack-Atom, fed by SK on Raspi via WiFi |
'no GPS data' occurs on plain OBP60 as well: according to log page is drawn every second, on screen however seconds are incremented in 2 second steps! [2022-05-31 09:17:06] GPST freezes same happens right again at: detailed log below, Detailed log. Click to expand!
|
screenshot-video and logs covering a 'GPS no data' event at 14:08:09 UTC raw MFD out.log NMEA0183 SNAG-0000.mp4 |
Not completely sure what you have logged in the raw...log.
Where do they come from?
The records are really strange:
So we see that the GPS time does not evolve, then we get an invalid record (140816) with a timestamp more in the future then the next ones. |
BTW: Does the same happen with disabled internal GPS? |
thanks Andreas for jumping in!
It's the MFD's TCP server 0183 output as seen on default port 10110. This seemed to be the only possibility to examine the MFD's (internal) NMEA 0183 records without disrupting the system by excessive logging.
of course there is no 0183 output at all when internal GPS is disabled. Feeding external GPS data introduces alien hardware, software and possibly whacky data transport. That's the route I took when started to analyze this bug - the current setup can be easily reproduced by anyone Observing the time pattern of 'no GPS data' events, I have a strong gut feeling that we are seeing the very same issue when using any external 0183 GPS sources - this favours your hypothesis of buffer overflow or alike.
Excellent - I haven't spotted that so far. Maybe Norbert can shed some light on that as I am quite limited in understanding the tasks involved. |
Just to verify I ran another test - MFD fed by Raspberry/SK/Moitessier GPS data (logs available). There is just a single format of RMC records with no records out of time order. This might indeed be an issue of the MFD internal GPS - 'no GPS data' continue to appear in the very same manner, so it's an issue not related to this |
Do we have logs for this second scenario? |
Here they are: com6 is the display's logging output, telnet is the display's complete 0183 output. |
We must have bought fake China chips again. The UBlox NEO-6M is probably an ATGM332D that should be pin-compatible with the UBlox NEO-6N. The AT6558 chip is installed in the ATGM332D module. This can be recognized by the first lines of output immediately after switching on. It is quite possible that the ATGM332D shows such erratic behavior. More details can be found here: |
no GPS dropouts were observed during 7 days live on board using a different OBP60 with no GPS and BME280 installed. This supports Norbert's hypothesis. Occasional reboots however still occurred. |
In my current setup I have 2 OBP60 installed, data fed from same SK on RPi4. The device with GPS/BMP280 installed (but deactivated in config) again displays dropouts, the device without those sensors runs smoothly |
The problem is a software timing in the GPS data reading routine. Only all 1s read the GPS data. The data rate form GPS has the same rate. The data transmission is asynchronous and produce the problems. With al reading rate from 2 Hz is all good. The problem is fixed in the new firmware dev20240920 for the new hardware V2.1 |
This bug has been hunted for since end of march - the reason unfortunately remains unclear.
This issue is created to summarize different findings in a single place.
Sporadically, 'no GPS data' is displayed, time and position data disappear. Signal usually is recovered within a few seconds.
No obvious pattern
The text was updated successfully, but these errors were encountered: