Assuming the RTC of the Artemis Open log has been synchronized to GPS when the board is first powered up, then GPS board is disabled, then using pin 11 as a trigger input to the open log board applying a 2 Volt rising edge, what is maximum permitted trigger rate that the Artemis Open log can trigger and time stamp date and time.
Hopping the trigger input can cope with a trigger rate of several hundred Hz ?
Assuming all onboard sensors are disabled, serial logging is disable, analog logging is disabled and I only wish to record the absolute date and time when pin 11 is triggered by a rising edge.
Not sure what the timing drift is on the RTC but if the board is powered by an external battery figured the RTC should remain precise for a long time as long as the battery is topped up from a USB charger.
You are entering unchartered territory! In theory, you should be able to achieve the same maximum rate as what the OLA achieves when logging “freely”. The interrupt code is very efficient and should not slow down the logging rate at all. Please test it and let us know what you find.
Thanks, I’ll see what I find out, once Iv’e done some tests. When the OLA is triggered using pin 11 and logs absolute time, what is minimum time format resolution can be achieved in its log, is it to just to nearest millisecond or lower resolution microsecond or even nanosecond. i.e. HR:MM:ss.SSSSSSSSS
The OLA code logs time from the internal Real Time Clock and that has a resolution of 0.01 seconds.
It would be straight forward to add a feature to let you log the microsecond count from the processor too BUT you need to be aware that that value will reset if the OLA goes into its low power mode. If you are logging continuously, then this should not be a problem for you.
Nanosecond resolution is not possible.
If this is something you need then please raise a “Feature Request” issue on GitHub:
Was wondering whether it is possible to consider the feature request idea for a firmware update to the OLA to improve the precision of the triggered time stamp from its current 10ms down to mico second ideally or at least 10 microsecond.
Don’t worry - we haven’t forgotten about your request. These things go in cycles. I’m working on other projects at the moment but will be revisiting the OLA in the next 1-2 weeks. Thank you for your patience.
Just tried out V 1.8, thats looking good, I was initially a little confused as the microseconds log appears as a separate column and not joined up with the milliseconds from the main time stamp. As the main time stamp has a resolution of 10milli second, am assuming the number on the left side of the microsecond log is 1 millisecond, the next number being 100 micro second resolution and so on. Would be great if the microsecond log count was joined up with the main time stamp time instead of being a separate column.
Noted one other observation that sometimes the log data for the microseconds can show a negative symbol before its number which I dont understand, seen this a couple of times, normally after enabling and disabling various logging options from the main menu, its micro log can get confused ?
Re. ‘linking’ the RTC and micros timestamps: I really don’t think it would be sensible to do that. The hours, minutes and seconds come from the Artemis’ Real Time Clock, whereas the microseconds come from an internal counter. Micros will reset whenever the Artemis goes into deep sleep, whereas the RTC keeps going. Thus you would have discontinuities each time this happened. I’m afraid you will need to manually ‘add’ the two columns when you analyze your data.
Also, please be aware that micros uses a 32-bit unsigned integer and so it will wrap around to zero every 71.583 minutes.
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
“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.
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.