- Mon Dec 07, 2020 1:26 am
"micros" is a count of microseconds. It starts at zero each time the Artemis is reset, increases by 1 every microsecond, until it reaches 2^32 - 1 = 4294967295. Then it "wraps round" back to zero and repeats.
The RTC is different. It always keeps running, so long as the Artemis has power (from its back-up battery). The RTC only provides a resolution of 0.01 seconds. The RTC is only updated when the user sets the time through the menus.
There will be a discontinuity between the RTC and micros. E.g. if the user sets the RTC time to 09:00:00.00 when micros is at 12345678, then: if you "add" the last four digits of micros to the RTC time; at the second roll-over you will see:
So, in summary, to get _absolute_ time, you need to use the RTC data. Micros will give you the microsecond-resolution _relative_ timing from reading to reading.
There is no way to give you what you really want (true RTC time with microsecond resolution) using just the Artemis. RTC + micros is the best we can do.
A GNSS module will give you better resolution. u-blox GNSS modules can provide nanosecond-resolution time. The OpenLog Artemis firmware can read time (and position) from a u-blox module, but, at the moment, only millisecond resolution is provided. It would be possible to upgrade the code to support GNSS microseconds.
**BUT**, even then, there is a problem. Yes, the module can provide nanosecond resolution, but it can only provide messages at the "navigation rate". Usually this is 1Hz but OpenLog Artemis supports up to 10Hz. So you get nanosecond resolution timestamps in 0.1 second increments.
So even a GNSS module cannot provide the exact time _now_ with nanosecond resolution.
I think you might be asking for the impossible?