Pytrack GPS delayed 5-6seconds NMEA
I have a Pytrack2 and a Lopy4 and I am trying to get accuracte coordinates. The GPS accuracy is fine, but I get the coordinates with a very bad delay of 5-6 seconds.
I have tried several libraries such as L76GLNSV4 and L76micropyGPS and found that the parsing adds additional time adding up to up to 10-20 seconds delay, but that the initial delay is already when reading the NMEA messages.
So the i2c.readfrom(GPS_I2CADDR, 255) returns 5-6second old coordinates/timestamps.
I have tried various configurations of the L76-L as well, baudrate, update frequency etc.
Did anyone have this issue before? Any tips? I do not think a delay of 5-6 seconds is normal or tolerable. I tried a different Pytrack as well, with active antenna, with passive antenna. Any ideas?
Thank you I will look into that.
I would like to get one GPS location per second, or at least every 2 seconds if possible. I was thinking of some internal buffer in the GPS running full or something. I am now trying to read out more of the buffer and process only parts as you suggested. this still shows a delay of 1-2 seconds, but that would be acceptable.
I noticed this phenomenon in my earlier gps handling code and ended up refactoring my code completely.
My aim was to transmit the position of the device over LoRa every 10 seconds if it was moving, or had just stopped moving, and otherwise, every 20 minutes when stationary.
I ended up using MicropyGPS. My code reads and discards all data from the GPS during the 10 second gaps, then when it is time to get a fix, feeds data into a fresh instance of MicropyGPS. When it receives an instance of the RMC message, call unset_satellite_data_updated(), then wait until I have received a full set of wanted messages and until satellite_data_updated() returns true, at which point I know that MicropyGPS has received a full set of NMEA messages and should be able to produce a fix, which I then use. Then it is back to reading and discarding data. The previously used instance of MicropyGPS is destroyed and a new one used each time.
So, to sum up, I don't try to process all the data coming out of the GPS, I just process enough to get a fix when I need a fix and dump all the rest.
I also use MQTT to report on the status of the navigation code and can see that the latencies are now very low, as measured from the embedded time-stamp in the MQTT data, set from GPS time, and the time of arrival of the MQTT data on my PC. There is perhaps some jitter, but not much. This code has also been very stable, achieving an up-time of just over 1 year, but sadly that came to an end when I moved house and had to reconfigure the wifi credentials.
Hope this helps.