search

sparkfun / OpenLog_Artemis

The OpenLog Artemis is an open source datalogger the comes preprogrammed to automatically log IMU, GPS, serial data, and various pressure, humidity, and distance sensors. All without writing a single line of code!
https://www.sparkfun.com/products/15846
Other
86 stars 45 forks source link

RTC data may not persist if configuration instructions are followed precisely #88

Closed VancouverUmbrella closed 3 years ago

VancouverUmbrella commented 3 years ago

Subject of the issue

The problem is that RTC date and time set in the OLA via a terminal do not persist after the unit is powered down. Investigation suggests that entering a month value between "1-12" as suggested by the configuration prompts may be the cause of the problem. When a month value of "6" was entered, the RTC data did not persist. A default date and seemingly arbitrary timestamp appeared in log files. When a month value of "06" was entered the RTC data persisted as expected.

Your workbench

Steps to reproduce

  1. Set the RTC date and time on OLA via USB. I used CoolTerm. When prompted for a month between "1-12", enter "6".
  2. Power OLA down.
  3. Power OLA up via 1S Lipo and log some data.
  4. Power OLA down and examine the logs from the SD card. The RTC data has reset to default or arbitrary values.

Expected behavior

RTC data would persist.

PaulZC commented 3 years ago

Hi Andrew (@VancouverUmbrella ), Thanks for reporting this. I will dig into this on Monday when I have access to my OLA hardware. Right now though, I'm struggling to see how the preceding zero can make a difference. Here is where the date is requested and set: https://github.com/sparkfun/OpenLog_Artemis/blob/b8bab7732d70572dad3ea398ba46e56a58277a93/Firmware/OpenLog_Artemis/menuTimeStamp.ino#L135-L141 Looking at that code with fresh eyes, it is clear that it will set the time back to what it was when the date entry started. I will fix that. But for now if you set the date first, then the time, all will be well. The code uses a function called getNumber to accept the date from serial. The critical bit of that code is here: https://github.com/sparkfun/OpenLog_Artemis/blob/b8bab7732d70572dad3ea398ba46e56a58277a93/Firmware/OpenLog_Artemis/support.ino#L217-L232 A preceeeding zero should make no difference... Puzzling. Until Monday, Best wishes, Paul

PaulZC commented 3 years ago

Hi Andrew, It seems more likely that this issue is linked to how you are powering your OLA up and down. Please talk me through the exact steps you take when logging data, especially at what point you disconnect the battery, reattach the battery and/or USB cable and/or press the reset button. The OLA will lose RTC time if you attempt to wake it while no external power is connected. Please see this section of the hook-up guide for more details: https://learn.sparkfun.com/tutorials/openlog-artemis-hookup-guide/low-power-considerations Best wishes, Paul

VancouverUmbrella commented 3 years ago

Hi Paul,

Wow! Thank you for the wonderfully thoughtful and detailed replies.

Did I jump the gun in declaring the leading zero to be the culprit? You may well be correct. Before writing this post, I reconfigured the OLA with "6" as the month and failed to reproduce the original issue. I went so far as to reset the device (power-off reset) and start with a clean SD card. Still, the RTC date and time persisted in log files as expected.

But I'm getting ahead of myself. Let me walk you through the steps I've been using:

Configuration

  1. Open CoolTerm. I'm using Mac.
  2. Connect OLA to PC via USB. The OLA has no battery attached. An SD card is inserted. I've tried this step both with and without the bmp280 connected.
  3. Set Baudrate in CoolTerm to 115200. Open the USB connection to OLA.
  4. Configure the OLA RTC date. I've always done this step first.
  5. Configure the RTC timestamp.
  6. Return to logging in terminal.
  7. Close the USB connection to the OLA. Or, quit logging, then close the connection. I've tried both methods.
  8. Unplug the OLA from the PC.

Logging

  1. Power up the OLA with 1S Lipo power. I tap into the balance lead on a 3S flight pack for 1S power.
  2. Before I stumbled on the supposed 'leading zero fix', the OLA would usually start logging immediately. After the fix, pressing the reset button was always required to initiate logging. Incidentally, at one point before I applied the supposed fix, the green Tx LED on the OLA started flashing during logging. It had not done that previously. It always flashes since then.
  3. Fly an RC model airplane with OLA on board for at least 20 minutes.
  4. Land the model. Disconnect power from OLA.
  5. Sometimes, I've flown and logged a second flight. Before the fix, the OLA usually started logging on power up, but not always. Sometimes pressing reset was needed. And sometimes no log file was recorded at all. That happened on three occasions. After the fix, logging only begins after pressing reset (as expected).

Results I've reviewed the 14 log files that predate my supposed fix. In all but one of them, the RTC date and timestamp were reset. That one oddball is a real puzzler. I can't think of anything I may have done differently on that occasion. Is it possible that the charge state of the RTC battery does play a role? And that the battery happened to be well charged on that occasion?

If there's an obvious error in how I'm powering or depowering the OLA, I'm missing it. More puzzling is that I can no longer reproduce the problem. I'll have another go over the weekend and post again if I succeed.

Thanks again for your help. I hope this bug report hasn't turned into a wild goose chase to no useful purpose.

Kind regards, Andrew

E97A3D5B-0B66-4AC2-9A39-A7BCD95678FB 386ABCB0-4D13-43B9-AE39-F4A0B9081688

VancouverUmbrella commented 3 years ago

Hi again Paul,

I made some discoveries over the weekend.

On Saturday, I logged a flight with the OLA. The device started logging as soon as it was powered up. The log file showed that the RTC date and time had been reset. The green Tx LED did not flash during the logging.

I take it that the reset of the RTC data was a result of my having done a power-off reset of the OLA the previous evening. My new understanding is that such a RTC reset does not take effect immediately. Rather, the RTC battery must fully discharge first. Perhaps it would be more precise to say that the power-off reset action initiates the discharge of the RTC battery, which when complete causes the RTC data to revert to default values. Does that sound right? The Low Power Considerations docs seem to support the idea. The nuance escaped me on previous readings.

Now for part two: After looking at the log files on Saturday, I set the RTC via CoolTerm as before. Then I put the device away again overnight. On Sunday morning I used it to log another flight. In that case, pressing the reset button was required to initiate logging, the green Tx LED flashed continuously, and the RTC data was correct in the resulting log file. In other words, things pretty much worked as expected. The possible exception might be the green Tx LED. From the docs, I had expected it to flash only for USB traffic. Does it also flash whenever serial logging is enabled, even if no serial device is attached?

So where does that leave us?

A power-off reset of the OLA reproduces my original issue of the RTC data setting between logging sessions. However, I'm as certain as humanly possible that I didn't do that, not least because I had initially read the Low Power Considerations (if not fully understood them).

In practical terms my issue seems to be solved. Closing this bug seems appropriate if you agree.

All the best, Andrew

PaulZC commented 3 years ago

Hi Andrew (@VancouverUmbrella ),

Nice detective work!

Let me summarize what happens when you disconnect power from the OLA: If the OLA is running and logging normally and you disconnect the power, the battery voltage monitor tells the Artemis to go immediately into a deep sleep state. It does not have time to close the SD log file nicely, it has to leave it 'open'. There is a risk of data loss as a result. The way around this is to add a "stop logging" button as described in the hook-up guide. The tiny back-up battery on the OLA can only deliver a few uA of current. If you try to draw more than that, the voltage collapses and the RTC will reset. So, the back-up battery will keep the OLA RTC running but can only do so if the Artemis is in deep sleep. If you accidentally press the reset button without a power source being attached, the Artemis comes out of deep sleep and draws mA from the RTC battery. The voltage collapses and the RTC resets. The correct sequence is: connect a power source; then press reset to wake the Artemis. For your application, I do recommend adding a "stop logging" button if you can.

The TX LED indicates transmit traffic on the USB TX line. You might expect it only to flash when you actually have USB connected, but I've just tried it here and I see the same thing as you. The TX LED flashes even though I don't have a USB cable connected. My guess is that the CH340 USB interface chip flashes the LED if it receives serial console data from the Artemis regardless of whether a USB cable is actually attached or not. In summary, this is nothing to worry about. But thank you for identifying this. You can disable it by disabling the "Log to Terminal" option in menu 1 ("Configure Terminal Output").

I think we can indeed close this issue, but please re-open if you think we've missed something. Best wishes, Paul

VancouverUmbrella commented 3 years ago

Superb summary, Paul. Thank you.

You anticipated a follow-up question I was tempted to ask about the stop logging button. Specifically, your reply confirms my suspicion that simply pulling the power from the OLA prevents the proper incrementing of log file names. Mind you, that's a trivial consequence compared to possible data loss or corruption. I'll add the button as you suggested.

Thanks again for your wonderful help. I've only scratched the surface of the OLA's capabilities. That's something I plan to remedy.

Kind regards, Andrew