time between logs in seconds not accurate

[jiggermole]

It seems that the time between logs is done with a signed 8 bit integer. If I want to take a reading every 5 minutes I put in 300 seconds and it logs every 40 seconds.
Input 600 seconds and it logs every 80 seconds
Every input under 128 seconds is logged correctly. Anything over that is incorrect.

Currently using v1.3 of the firmware.

[adamgarbo]

Hi @jiggermole,

The OpenLog Artemis generally relies on a 64-bit unsigned integer representing the number of milliseconds based on the day of the year for its timing.

That being said, I am observing the same behaviour you've described.

// Interval: 300 seconds
09:54:52.255 -> rtcDate,rtcTime,output_Hz,
09:54:52.255 -> 05/05/2020,09:54:52.28, inf,
09:54:52.293 -> ⸮05/05/2020,09:55:30.31,0.05,
09:55:30.301 -> ⸮05/05/2020,09:56:08.34,0.04,
09:56:08.318 -> ⸮05/05/2020,09:56:46.37,0.04,
09:56:46.346 -> ⸮

// Interval: 600 seconds
09:57:16.079 -> rtcDate,rtcTime,output_Hz,
09:57:16.079 -> 05/05/2020,09:57:16.08, inf,
09:57:16.079 -> ⸮05/05/2020,09:58:31.97,0.03,
09:58:31.970 -> ⸮05/05/2020,09:59:47.85,0.02,
09:59:47.860 -> ⸮05/05/2020,10:01:03.74,0.02,
10:01:11.799 -> ⸮05/05/2020,10:02:19.63,0.02,

My guess is it has something to do with the code that converts between milliseconds and microseconds, and the calculations of ticks to sleep using a 32kHz clock.

I expect @nseidle should be able to shine a little more light on this.

Cheers,
Adam

[adamgarbo]

A quick note that this bug is also present in OpenLog_Artemis-v14-RC1.bin.

// Interval: 300 seconds
10:50:05.490 -> 05/05/2020,10:50:05.48,inf,
10:50:43.635 -> beginDevices: No devices detected
10:50:43.635 -> 05/05/2020,10:50:43.62,0.05,
10:51:21.795 -> beginDevices: No devices detected
10:51:21.795 -> 05/05/2020,10:51:21.77,0.04,
10:51:59.958 -> beginDevices: No devices detected
10:51:59.958 -> 05/05/2020,10:51:59.91,0.03,

[PaulZC]

Hi @adamgarbo & @jiggermole ,
I think I've got to the bottom of this issue. It was a gremlin to do with converting settings.usBetweenReadings into 32768Hz sysTicksToSleep. A 32-bit multiply was overflowing.
Fixing that revealed a second issue that large values for settings.usBetweenReadings weren't being saved correctly to SD card. sprintf wasn't able to cope with large values.
I've added fixes for both issues to the v14 branch:
https://github.com/sparkfun/OpenLog_Artemis/tree/v14
If you have time, could you please download and test?
Sincere thanks!
Paul

[adamgarbo]

Hi @PaulZC,

I uploaded the OpenLog_Artemis-v14-RC1.bin to the OLA and have been testing the logging frequencies. Unfortunately, it appears that the issue is still present.

// Interval 300 seconds
09:00:08.338 -> 06/24/2020,09:00:18.36,549.32,-220.21,719.24,7.00,2.20,-2.05,-15.00,-17.10,69.60,50.19,inf,
09:00:08.374 -> ⸮beginDevices: No devices detected
09:00:46.507 -> 06/24/2020,09:00:56.51,523.93,-372.07,922.36,13.51,-3.13,-7.81,-16.80,-16.20,70.05,25.60,0.05,
09:00:46.507 -> ⸮beginDevices: No devices detected
09:01:24.648 -> 06/24/2020,09:01:34.66,410.64,-5.86,856.93,14.10,0.48,-2.40,-17.40,-17.10,70.35,25.22,0.04,
09:01:24.648 -> ⸮beginDevices: No devices detected
09:02:02.788 -> 06/24/2020,09:02:12.80,622.56,131.35,697.27,8.31,-0.07,-3.81,-16.80,-16.50,70.05,25.12,0.03,
09:02:02.788 -> ⸮beginDevices: No devices detected
09:02:40.933 -> 06/24/2020,09:02:50.95,613.28,188.96,766.11,5.98,-2.36,-7.98,-15.60,-16.95,69.00,23.30,0.03,

// Interval 600 seconds
09:03:26.974 -> 06/24/2020,09:03:36.99,698.73,-133.30,725.10,11.89,3.69,-5.13,-13.65,-15.45,75.90,47.02,inf,
09:03:26.974 -> ⸮beginDevices: No devices detected
09:04:48.755 -> 06/24/2020,09:04:53.00,522.95,-110.35,936.52,11.22,0.96,2.44,-13.65,-15.00,75.15,46.02,0.03,
09:04:48.755 -> ⸮beginDevices: No devices detected
09:05:59.454 -> 06/24/2020,09:06:09.00,549.80,-186.52,887.21,5.06,-4.20,-3.49,-13.35,-15.15,74.55,41.99,0.02,
09:05:59.454 -> ⸮beginDevices: No devices detected
09:07:24.939 -> 06/24/2020,09:07:25.01,613.77,-65.43,850.59,14.15,1.35,-0.04,-15.60,-14.25,75.60,45.30,0.02,
09:07:24.939 -> ⸮beginDevices: No devices detected
09:08:37.891 -> 06/24/2020,09:08:41.01,512.70,-275.39,905.27,11.18,-1.89,-0.60,-13.20,-15.45,75.90,41.85,0.02,
09:08:37.891 -> ⸮beginDevices: No devices detected

Should I have exported a new compiled binary? I can't try to do so if needed once I reinstall all the necessary libraries.

Cheers,
Adam

[PaulZC]

Hi @adamgarbo ,
Many thanks for trying this.
Can I just check that you tried the binary from the v14 branch? You will need to download it manually.
Here's what I see on my X04 board. It has a faulty IMU so I'm only getting the time, but 300 secs works OK for me.

17:02:04.939 -> x) Return to logging
17:02:14.486 -> 01/01/2000,03:56:09.26,inf,
17:07:15.036 -> ICM-20948 failed to init.
17:07:15.036 -> beginDevices: No devices detected
17:07:15.036 -> 01/01/2000,04:01:09.83,0.01,
17:12:15.603 -> ICM-20948 failed to init.
17:12:15.603 -> beginDevices: No devices detected
17:12:15.603 -> 01/01/2000,04:06:10.39,0.00,

I've attached a zip of the latest binary just in case.
Thanks!
Paul

OpenLog_Artemis-v14-RC1.zip

[adamgarbo]

Hey @PaulZC,

Sorry about that! My clone of the v14 branch was missing some commits from upstream.

I just uploaded the newest version of the firmware and the sleep timing appears to be working now! I also see that the sleep duration appears to be now limited to 129,600 seconds (36 hours).

12:48:41.518 -> 01/01/2000,00:28:23.55,-252.93,-14.65,-1002.44,13.08,3.60,-3.15,93.15,9.60,-55.35,27.61,inf,
12:53:47.498 -> beginDevices: No devices detected
12:53:47.498 -> 01/01/2000,00:33:23.84,-177.25,-153.32,-1061.52,8.44,2.27,-2.50,92.10,9.15,-56.40,42.18,0.01,
12:58:42.075 -> beginDevices: No devices detected
12:58:42.111 -> 01/01/2000,00:38:24.14,-25.88,-2.93,-896.48,0.81,1.27,-3.50,90.00,8.70,-57.60,46.88,0.00,

I'm looking forward (once I find the time) to incorporate my Apollo3 RTC functionality into the OLA to get alarms working!

Cheers,
Adam

[PaulZC]

Nice one Adam (@adamgarbo) - thank you! Glad it's working for you.
I'm going to leave this issue open until V1.4 of the code goes public.
Yes, it turns out that the sleep function we are using is limited to uint32_t's worth of 32768Hz system clock ticks. 2^32 / 32768 =131072 seconds = 36.4 hours. I rounded that down to 36 hours.
I'm guessing that most users would be happy with logging once per day. But if we can add RTC alarms that work beyond a day then so much the better.
I've just added features to let you set the RTC from GNSS and automatically adjust for your local UTC offset, but they haven't made it into .bin format - yet. They're in the V14 branch if you want to pull them.
Thanks again to you and @jiggermole for the continued support - great to be working with you,
Paul

[PaulZC]

Hi @jiggermole & @adamgarbo ,
Thanks again for opening this issue. This has been corrected in v14 of the firmware.
I'm going to close this issue but please re-open if you have any further problems!
Very best wishes,
Paul