What is max time stamping rate for Artemis Open log ?

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.

Thanks.

Hi Nick,

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.

Best wishes,

Paul

Hi Paul,

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

Thanks,

Apologies for confusion but think number format i.e. HR:MM:ss.SSSSSSSSS may be something different.

So more interested to know how many decimal places the time stamp data has. so if board is triggered at 10am , is it recorded as 10:00:00.000000000

i.e with 9 decimal places gives nano second resolution. But I can live with microsecond time stamp resolution.

Hi Nick,

This is going to be difficult to achieve…

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:

https://github.com/sparkfun/OpenLog_Artemis/issues

Here is a recent example:

https://github.com/sparkfun/OpenLog_Artemis/issues/42

Best wishes,

Paul

Feature request added via Github.

Hi Paul,

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.

Best regards, Nick

Hi Nick,

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.

Best wishes,

Paul

Hi Nick,

Thank you for your patience!

I have added the code you wanted. Details are available here:

https://github.com/sparkfun/OpenLog_Art … -734812868

Best wishes,

Paul

Hi Paul,

Many thanks, look forward to trying out the beta version and V 1.8 bin when they become available.

best regards,

Nick

Hi Nick,

Firmware version 1.8 has just gone live. You can find update instructions here:

https://github.com/sparkfun/OpenLog_Art … UPGRADE.md

And the new binary file is here:

https://github.com/sparkfun/OpenLog_Art … r/Binaries

Please let me know if this fixes the issue. I’ve tested it here - but you never know!

All the best,

Paul

Hi Paul,

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.

Best regards, Nick

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 ?

Hi Nick,

Thank for spotting the negative micros issue. I will need to investigate that. I have opened an Issue here:

https://github.com/sparkfun/OpenLog_Artemis/issues/57

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.

Best wishes,

Paul

Hi Nick,

Thanks again for spotting this. I’ve fixed the problem and have created a “BETA” version of the firmware which you can try.

Details are here:

https://github.com/sparkfun/OpenLog_Artemis/issues/57

The V10_v19_BETA version is here:

https://github.com/sparkfun/OpenLog_Art … r/Binaries

Very best wishes,

Paul

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

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

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