We did some tests, and it seems that the firmware stores the system time in non-volatile memory from time to time. When rebooting, without network access, the system time still incremented monotonously from the time before the reboot. (which would be great!)
Is that correct?
What is the system time on a brand-new device that boots for the first time before it first connects to the network? (We can’t test that right now, have no brand-new devices left) Is it something close to 0L, or some arbitrary time like January 1st, 2010?
Also, is there some way to get a callback or such when system time is adjusted by the firmware, particularly if it makes a big jump?
(I’m asking because we are trying to integrate some measured values over time, and if we don’t understand the system time behavior, our integral will be completely off — e.g. we might have thought we integrated over 5min, but it was from 1970 or 2010 across a system time set to now.)
@jernstlun, Particle.syncTimeDone() only returns true or false:
Returns true if there is no syncTime() request currently pending or there is no active connection to Particle Cloud. Returns false when there is a pending syncTime() request.
@ScruffR, Starting with 0.6.1-rc.1 “starting” unitialized time is 2000/01/01 00:00:00.
@jernstlun, There is no function that returns the delta, but Particle.timeSyncedLast() can give you the timestamp received from the server during last synchronization and there is also a time_changed system event which should be fired when new time is applied to the RTC (either when setting time manually or when a synchronization occurs).
Apparently, when the system time is set, whatever sub-second counter that is being used to increment the time is not being reset. That is, the time may roll over to the next second anywhere from 1 to 1000 milliseconds later. Someone, like NtpTime that is trying to keep the system time close to the actual second is pretty much out of luck.
I know the system time resolution is only to a second, but for someone OCD about time like me, it would be nice if the second would “tick” close to the second.
Thanks,
Doug
Unfortunately it’s a hardware limitation. Unlike STM32F4 RTC peripheral [1], which provides subsecond resolution out of the box, as well as resets a subsecond counter when a new calendar time is written, STM32F2 [2] does not expose subsecond counter (prescaler) as a register and there is no way to reset it either (although I am not really sure that it does not reset it same as F4). Well, perhaps stopping/restarting the RTC peripheral completely might reset it, but it still sounds a bit useless, because the RTC setup time would still introduce ‘some’ latency.
The only viable option would be to have an external RTC IC if accurate subsecond calendar time is a requirement.
