Time from core library off by 13 seconds or so?

Troubleshooting
1

Hi Folks!

I am writing a small program to simulate a GPS NMEA string, and I very easily got the Time from the built in core library - but it seems as if it is off by a significant number of seconds (13 right now).

Is anyone else noticing this? I was hoping to avoid having to write some code to check an NTP server for time, since the functionality already existed.

Thanks,

Matt

2

You can sync time every day or move often as shown in this example: https://docs.particle.io/reference/firmware/photon/#spark-synctime-

Also, i think the new v0.4.5 firmware accounts for latency…

3

Interesting - ok… if I call Spark.syncTime() it does make it better - I am guessing what is happening is that the wifi connection I have is a MiFi and there is quite a bit of latency built in - so i am losing time when the sync actually happens.

Matt

4

So I am guessing that 0.4.5 doesn’t actually account for the latency - otherwise I would have expected the timing to be more accurate. I will check on a quicker wifi later tonite and see if the timing is much closer (i expect it to be).

Matt

5

Hi @mathewbeall

There is also a software filter that tries to smooth out some jumps in time after a sync. If the time jump from syncing is greater than 127 seconds or less than -127 seconds, the jump happens quickly. If the time jump from syncing is not beyond those limits, then the time corrected over two times the jump in time seconds, so for a 100 second correction, the change will happen over 200 seconds.

So wait a few minutes after a sync to see the filtered change.

6

It’s definitely less than that - generally between 4 and 10 seconds - which is why I think it’s just the MIFI latency that is skewing the time.

Matt

7

I can’t remember the place but I’ve read somewhere (in this forum, github issues or slack) that a latency correction is planned, but no ETA yet.

I think I found it again

8

I seem to have a reasonable work around - it’s odd… I have a loop that calls Spark.syncTime() 5 times - each with a delay of 10 seconds… the time is the second field in this string… after 5 times I don’t call it again - and it seems to be ok.

$GPRMC,195539.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A46 --> initial grab
$GPRMC,195547.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4F --> 8 seconds
$GPRMC,195600.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4F --> 13 seconds
$GPRMC,195610.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4E --> 10 seconds
$GPRMC,195620.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4D
$GPRMC,195630.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4C
$GPRMC,195640.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4B
$GPRMC,195650.000,A,5220.531,N,00011.797,E,0.0,0.0,220915,A4A

After 5 or so calls to the sync - it is very close - about a second within. Strange that I have to call it multiple times however - but it seems to work fine! I will try on the slower internet connection and ensure that it also works there.

Matt

9

Last update…

I call Spark.syncTime a couple of times in the beginning and drop back down to once a day (no need to overwhelm the spark service). It seems to be about 2-3 seconds off NTP/GPS time. This is being used to sync a clock - and it’s right next to a clock that has it’s time set by GPS - so it was really obvious that the time was off by a few seconds.

Matt