The existing RT clock on the imp006 is coarse and when it receives updates from the agent, it can skip whole seconds. Is there any plan to either expose the UTC clock source on the BG96 GNSS integration, or to provide a sync to the impOS time() that is preferable to the one is gets from the agent?
The BG96 library only offers lat & long, but the same Quectel call also returns UTC time, I believe.
A transparent implementation of it could inform the date() call on the imp006. Previously, the usec field has always been 0 on the device, but successful integration with the GNSS could populate that field with millisecond precision.
I don’t know whether the inner workings of the impOS time() are receptive to improvement. The GNSS source could also be used as the reference source for real-time that time() could use for synchronisation instead of agent time. Presently, there can be very abrupt adjustments to real-time on the device when a device connects to the cloud after being offline for a period. If the device in informed that it is running slow, it should be instructed to “catch up” n seconds. It could achieve this by stretching the clock over a period of a many seconds. Similarly, time() can slow down by clipping a small amount off each second for a prolonged period.