PyTrack 2.0X not displaying continuous GPS-tracks

[SanOls]

Hi,
I'm currently working with a program that tracks the RSSI between two Pycom-modules using PyTrack 2.0X and its GPS. I'm displaying my tracks using Pandas and Bokeh, but it's not displaying a continuous track, dispite using only 2sec sleep between each value reading (and GPS-track). I've checked the coordinates in other softwares aswell, and they are all spaced the way I describe. Is this caused by some limitations in the GPS, or does it have anything to do with some kind of buffer? I'm using the main part of the example code for PyTrack provided by Pycom to get the GPS-tracks.
Attached is a snippet showing the problem.

[jcaron]

It could be GPS coverage issues, but that seems quite unlikely to me, there's a form of regularity here which is troubling.

Can you share the file, or at least the timestamps?

Also you say you track the RSSI between two Pycom modules (using what? Wifi? BLE? LoRA?...), so this clearly changes the way the script works, can you share that script?

[SanOls]

@jcaron Thanks for answering! Here is a part of the script that tracks the coordinates with the RSSI using LoRa:

I did't track the timestamps, but when running the script I can see in the CLI that the coordinates is printed in a regular interval.

[robert-hh]

@SanOls What is the real time duration of each on/ off phases? Could it be something like 17 minutes? That is the time needed for ticks_us() to overflow.

[jcaron]

@SanOls

When you look at the file, do you see any lines with coordinates with values null or 0 or something similar?

I think you need to add more logs, including:

• Timestamps, ideally before and after send, coordinates and recv
• Logs of the return value of coordinates in all cases
• Logs of any retries (which I believe would happen if recv returned something other than 'bob'

What is the duration of each good/bad phase? Looks like about 8 to 10 points, which should be 15-20 seconds each, is that the case?

What is the range of the RSSI values?