artemis forgets time

I set the time using an arduino serial interface. I use two digit months and days (after reading some other posts). I have a switch for reset and a switch for supply voltage, which comes from the lipo battery that came with the bundle. When I power off, a red LED stays lit for maybe 5 or 10 seconds and fades out. If I look later, the time has been forgotten and reverted to the default. This is true even if I never use the reset switch. I have had the system plugged into usb overnight and had similar results so I don’t think that my backup battery is not charged.

I’m also using the quiic scale breakout. I have seen the system forget the parameters for it (offset and gain settings that correspond to a weight). This doesn’t happen when I’m messing with it over days, but did happen when I left it for a week or two.

My project is a sea kayak paddle with a strain gauge. Since I seldom am inclined to take my laptop on the water… is there something else I should try? I was thinking of changing the backup battery, but it seems to be soldered into place. I can wield a soldering iron but I thought I’d try asking first.

which Artemis board do you use?

can you share the sketch ?

I’m using SparkFun OpenLog Artemis. There’s no sketch. It logs automatically. I “program” it by using the menu through serial.

Thanks

Actually, I noticed that 2 weeks ago when working on a project as well. I assumed that, as I had not used the Openlog for a longer time, the rechargeable battery for the RTC might have run low. As it was not the focus of the project I left it for what it was. Let me find time to check that in the coming days.

A couple more clues. If I plug it in using USB but don’t connect the battery it starts logging, creating a new file every 5 minutes (as I’ve specified). The files start at the default at time (year 2000, jan 1), and start increasing by about 5 minutes each file. The backup battery measures around 3V. When I disconnect the USB, cutting power to the board, a new file is created. The timestamps in the file continue but the file’s creation time is 1:00 AM. Within a minute, the backup battery was very low (a few hundred mV). This makes me think the artemis didn’t make it into “deep sleep”.

I next plugged it in using USB and did connect the main LiPo battery. I let it run for a half hour and then disconnected the USB. It continued running as expected. I then disconnected the LiPo. The LED went off immediately. In this case the backup battery measured 3.04V, dropping much more slowly (1mV every 6 seconds). This is an improvement but it will still be dead in an hour.

I took time today to look into this.

The name ‘RTC Backup Battery’ is actually misleading: it not only powers the RTC module in the Apollo3 chip, but it powers the complete Apollo3 chip. (VCC1) This starts as soon as you remove the USB and the LIPO battery. Attached is a chart that shows the different discharge times/speeds.

The difference in discharge rate between using the library V1.2.3 or the V2.2.0 is actually neglectable, BUT there is a very important aspect to take into account. See below.

The more internal Apollo3 peripherals, SRAM and flash memory are disabled the less power consumption and thus the longer backup battery will last. With power savings, you actually only see one line in the chart, although both are plotted. That is how close the results are between V1.2.3 and V 2.20. Without power saving, the time to discharge is MUCH shorter and you can see some difference between V1.2.3 and V 2.2.0, but that might also be because this test has not been done in a laboratory environment.

Only by testing, I was able to detect that as soon the RTC battery falls below ~2.3V, the RTC values are lost. In the chart, you can see that is already after 20 seconds without power saving !!

With power-saving, it takes a LONGER time. In the beginning, I see a big drop. I have tested for 50 minutes. In the first 2 minutes, the drop is on average 0.002V per second to 2.89V. From there it is on average 0,0001V per second. So in deep sleep with power savings, after ~ 100 minutes the battery would have reached 2.3V and thus we lose the RTC values.

The issue with V2.2.0 with OpenLog is that most of the power saving on the Apollo3 is NOT performed. Look in LowerPower.ino, function gotosleep(), none of the Apollo3 peripherals are powered disabled. The reason is the way the V2.x.x Sparkfun Apollo3 library interacts with the embedded mbed-os. A call to end(), either SPi / I2C / UART etc, is not causing the Apollo3 hardware layer (HAL) to de-initialize, and a begin() does not (re) initialize that HAL after wakeup and thus cause a crash if used after powered enable.

Note1:

The OpenLog backup battery should recharge itself within 20 minutes according to the information.

Note2 :

Just for reference, looking at the often used external DS3231 RTC module, the backup battery could last for years (How long will a DS1307 RTC run on a CR2032 coin cell battery? - Electrical Engineering Stack Exchange)

Attached also added the sketch that I used, in case others want to try this as well.

Example1_Get_Time_sleep.zip (2.86 KB)

RTC.jpg

Thanks for your time and the detail that you’ve provided.

It’s not what I expected. I guess it renders the backup battery not very useful. If I want to retain the time, I’ll have to leave the main LiPo connected. I guess it will last a while. My battery that came with the kit is 1250mAh compared to 1mAh for the backup. So I should get something like 100 minutes*1250 =86 days (not including actual use of course).

I was under the impression that pulling reset low would reset the time, but that’s not the case so that’s a bit of good news.

I’ll have to repurpose my power supply switch to be a pin 32 switch. I’m a little worried about that because pin 32 is pretty sensitive: just touching 10 inches of wire to the pin caused it to go into low power. It seems like it might need a pull-up. I guess if it tends to spontaneously shut off I’ll add one.

Thanks again.