Error: Unedited V4 data logger >GPS output shifted by 1 row

[AbhIoT]

Hi ,
I used the current updated datalogger firmware for my v4.
I received the data as expected, except GPS one. Most of the time GPS output is correct but sometimes GPS data gets shifted by one row, DTE - 0 , UTC - value of DTE, LAT - value of UTC .... .... SAT - value of SPD which is 0.
I tried to solve the issue but couldn't. Anyone faced similar problem?
Also I just came to know that GPS is connected to STM 32 controller. If this is the case then how to debug GPS firmware since we don't have access ? We can only change firmware running on ATMega 32.

thank you,

[jonathan]

I just wrote a script that ignores the data where the GPS data is messed up. I assume it's a problem with the GPS firmware.

[mikebolt]

I also have this issue. When it occurs, I get data like this:

Code: Select all

6,DTE,0
0,UTC,240916
0,LAT,18562050
0,LNG,35195680
0,ALT,-27563
0,SPD,200
0,SAT,36

The DTE, UTC, ALT, SPD, and SAT values are incorrect. However, because LAT and LNG still appear correct, I don't think they are all shifted by one row.

In the past I was filtering the data by looking for GPS samples with extreme ALT values. However, I now realize that you can simply check for a DTE value of 0.

I am curious if this issue also occurs with the gpstest sketch. I plan to incorporate the TinyGPS library into the datalogger anyway.

[AbhIoT]

Thank you, @mikebolt and @jonathan
I found only ALT, LAT, DTE values(though shifted by one row) are correct other values are incorrect in that incorrect GPS packet.
@mikebolt, I never run gpstest sketch. but since this is an issue with GPS firmware which is running on ST32 controller, error will occur.
Also how TinyGPS library will remove this issue? thanks.

[mikebolt]

I'm not sure if it will resolve this issue, but here's my reasoning:

The datalogger sketch uses the results of $GPS command. This command combines the useful information from both the GPRMC and the GPGGA NMEA messages. It is probably handled by the STM32.

There is also a function that returns the "raw" GPS values, which appear to be unmodified NMEA messages. The TinyGPS library has functions for parsing values out of these raw NMEA messages.

If the only problem is that the firmware that handles the $GPS command is buggy, then using the TinyGPS library could solve the problem. It is also possible that the raw NMEA messages also contain bad values, in which case TinyGPS won't help.

[superrobe]

It seems that the values for DTE, UTC, ALT, SPD, and SAT are all off. But I don't think they are all off by one row because LAT and LNG still look fine.
In the past, I used GPS samples with extremely high ALT values as a criterion for data filtering. But now I know that all you have to do is look for is a DTE of zero word hurdle
I was wondering if the gpstest drawing has the same problem. Even so, I intend to incorporate the TinyGPS library into the data logger.