Teseo-LIV4F position offset issue

[jori]

Tested with FW ver.: 4.6.8.5.9 and 4.6.8.5.10

Data: 
https://earth.google.com/earth/d/1mJeIeQjGAp2WDpIKkoNUQNGgshZ4bpLU?usp=sharing

I am working on a car tracking device and decided to use Teseo-liv4f, but during the tests I came to the following problem, as the GPS module shows the real position, it suddenly sends several coordinates 100 or 200 km from it, then returns back and starts showing the real position again. There are two examples in the link above from the uploaded data between points 84 and 87 and between points 759 and 763. The settings are standard for the firmware, only parameter 1303 has been changed from 1 to 0.2.

[Tesla DeLorean]

Is it possible it's getting spoofed or jammed?

What would perhaps be more helpful is the NMEA stream illustrating the failure.

Is the NMEA checksum on the sentences correct? Any byte/data loss apparent?

[jori]

The checksum is calculated and only a message with a correct checksum is used. For the purposes of the test, a debugging file has been created in which messages with an error in the calculation of the checksum are recorded, currently no message in it. Thanks for the idea, tomorrow I will make the data from the nmea be recorded in this file and I will provide it.

[jori · Accepted solution]

It turned out that the problem is in my code :) . I am using the data processing code written for the previous version of the device which uses quectel l26 and Teseo-LIV4F is more accurate and gives 1 more character for longitude and latitude and the result is overflowing of the string buffers and all this mess.

[Tesla DeLorean]

Yes, should really allow for free-form representation of numbers, DDDMM.mmmmm to 6 or 7 dp should be considered. Use doubles (64-bit) not floats (32-bit) for latitude / longitude to maintain precision.

Parse the lines, using the comma delimiters, time can also be reflected to 3 dp