I’ve found some fleeting references to the IMP’s onboard RTC. But all I can really determine is that there is an RTC, and it’s used to populate the time() and date() functions with “one-second resolution”.
I need a sub-second accurate RTC and I assume the imp RTC is actually more accurate than +/- 1 second. Is there any way to access this underlying resolution? Also, how does time get set initially? Does the IMP communicate with an NTP server somewhere? Does it re-sync periodically, or can I trigger a re-sync?
The RTC hardware is actually only 1s resolution in the STM32. This gets set at boot and resynced periodically (every ~10 mins as I remember) but again only to second resolution. Sync is with our servers which are ntp-synced.
Obviously you can do ensure the 1s is lined up perfectly with actual second ticks, but we don’t do that yet. That, along with at least some improvement on time setting accuracy (unlikely to be ntp-grade) is on the to-do list.
The agent servers run NTP and their time is both accurate and precise (date().usec is precise to 1us, and probably accurate to ~1ms). The imps themselves currently don’t run NTP, so their time is neither (precise to 1s, accurate to 1-2s). If you need better accuracy than that in the imp, your best bet might be to look into radio time modules and/or an external RTC (but sub-second RTCs seem hard to find). Note that without an external RTC, neither NTP nor radio time can provide accurate time immediately after power-on.
The imp003 module, unlike imp001 and imp002, has an RTC with (effectively) 1/256s precision.
If you only need precision, not accuracy, then you could use time() once at startup and treat it as an offset for the hardware.millis() timer. The crystal timebase for hardware.millis() is less good than the RTC timebase (but not terrible: 30ppm IIRC, that’s a few seconds per day). Note that this technique is not monotonic: it can give the same answer twice if the imp wakes from deep sleep twice during the same RTC second.