SparkFun Forums

[naltieri]

Hi Paul, look forward to try the BETA version, so the aspect which is still confusing is that as the RTC provides a time stamp for hours, minutes, seconds and decimal seconds to 2 decimal places, and the microsecond log uses an internal counter to provide a microsecond time stamp, which starts at the forth decimal place how does one obtain the millisecond count which would be the 3rd decimal place. Adding the RTC time stamp and log micro time stamp is ok but seem to be missing the milliseconds from the data, Thanks Nick

[PaulZC]

Hi Nick,
"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:
09:00:00.005678
09:00:00.995677
09:00:01.005678
etc.
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?
Best wishes,
Paul

[naltieri]

Dear Paul,
Thanks for the detailed explanation, it sounds like it is only possible to get a relative time using the micros log data, not absolute time, so two sequential time stamps as an example from the Artemis with a 100 milli second delta is given below. With the micros log data, as the micros log is independent from the RTC it sounds like this only provides a relative difference between two subsequent readings. I dont follow the math of how the micros log data is added to the RTC data.
07/12/2020,17:27:09.85,266619272,
07/12/2020,17:27:09.95,266715403,
So I'm more interested in being able to know the absolute time stamp with millisecond resolution,
I also have several U-blox GNSS modules but as pointed out these have nanosecond resolution by only stream at max 10Hz. Perhaps I need an upgraded RTC which when synchronized to GNSS offers 1ms time stamp resolution. Thanks for your guidance but sounds like the onboard RTC doesn't quite provide enough resolution.
Best Regards,
Nick