Latest timestamp issues (2019)

[davidfokkema]

When the GPS does not track satellites, the GPS time can be wildly wrong. We've seen 1999 and 2019 a lot. When the timestamp jumps to 2019, the _latest_timestamp variable will always be later than the correct timestamp. This means that once the GPS time is correct again, all subsequent events will still be rejected. We should probably track the GPS time status, but make sure there are no race conditions.

[153957]

The One Second Messages contain the satellite Signal Values, perhaps you can use those to determine if timestamps are reliable.

[davidfokkema]

When the status byte is equal to 1, the Trimble doesn't have GPS time. So it should not be very hard to determine when the timestamps are not reliable. I worry about race conditions, though. The GPS first loses GPS time, then when the hardware triggers unreliable events are generated, and only then will the software receive the GPS status byte. Maybe require a GPS status message for every event? Something else to throw into the stew. If we can make that work, we will never have 1999 or 2019 events again. That's worth something.

[153957]

That is indeed worth something, especially in 4 years 3 years 1 year when it is actually 2019..

[davidfokkema]

Haha, I thought about that, too! Not too distant, anymore. Really need to make sure the server does not drop events in 2019.

[davidfokkema]

While it is an issue to upload events with incorrect timestamps, I believe events are never blocked or thrown away. There is a problem that the _latest_timestamp variable will be incorrect, and that will result in endlessly keeping track of old messages. That may result in the app running out of memory.

[davidfokkema]

Damn. One year.

[davidfokkema]

This just happened again on pysparc1. GPS time jumped to April 17, 2019. Must fix this.

[153957]

related: HiSPARC/firmware#3