For some reason I don’t understand, Chirpstack appears to be pushing a GPS epoch time that’s about 134 seconds in the future. My system is NTP synced, and the time in the LORAWAN FRAMES matches actual epoch seconds exactly. I know about the 18 second leap second adjustment, but this is a bit more than that.
Here’s a screen capture that shows the correct “Oct 24 7:44:00 PM” (EDT), but the timeSinceGPSEpoch is 1350690392, which is 2022-10-24T23:46:14, or 2 minutes and 14 seconds ahead. The device profile is configured for Class C, although I don’t think that would make any difference.
What might cause this?
I use GWOSC to convert between GPS epoch seconds and current time.
I am having a similiar problem, with an even increased time gap.
All LoRaWAN frames that I receive are having timestamps (in the rx-data) about 45 minutes in the future.
A frame that was received at 13:46 UTC+2 = 11:46 UTC shows the following tx-data:
time:“2022-10-27T12:31:06.809517Z”
timeSinceGPSEpoch:“1350909085.809s”
The system that the chirpstack runs on is a raspi 4 and shows the correct time.
The overview of the received frames shows the correct time, exactly as jcwren wrote.
I did investigate a bit more what happens when and under what circumstances.
My conclusion is:
It seems to me that the unprecise time is taken from the gps-module of the rapsi.
The more I place my antenna to a “better” spot, the more accurate the time is.
If this really is the reason, how am I able to change the chirpstack to use the systemclock to provide a more accurate time in the mqtt-frame?
