SparkFun Forums

[cjlyth]

Hello all!
I recently got one of these fine boards along with the combo environmental sensor to monitor my 3d printer. When the OpenLog is hooked up to my computer or raspberry pi, everything seems to work as expected. However, when I operate it on battery power, it sometimes does not log anything to the SD card. It seems that the reset will fix it sometimes. The problem with that is, I have mounted this board in a case in a way that allows me to remove the SD card to access the log files. Doing this makes the reset button unavailable.

What is the reset button required for?
Should logging to the SD card on battery work without the reset button?
Can I work around the button with software?
Where is the best reference for this board?

Thanks in advance for any help with these! I am happy to provide picture or additional info if required

[cjlyth]

I have pictures and brief documentation of the problem here: https://github.com/cjlyth/monenv/blob/m ... gn-flaw.md

[PaulZC]

Hello cjlyth,
Apologies for the very slow reply.
This is just a quick note to let you know that we are investigating the issues you have been having.
The next version of the OLA will include a Reset pad so you will be able to connect a remote reset switch - should you need to.
But we will be investigating your RTC and logging issues too.
Thank you for your patience,
Paul

[PaulZC]

Hello again cjlyth,
I forgot to thank you for the photos.
If you want to, you can connect your power switch to the PSWC breakout pads instead of breaking into the LiPo battery cable.
When the PSWC switch is closed, the OLA is powered down. The advantage of doing it this way is that you can still recharge the battery while the OLA is powered down.
Best wishes,
Paul

[cjlyth]

Thanks for the reply, I had already cut into the lipo battery cable when I noticed the breakout pads unfortunately. I may fix that if I can get board to remember the time setting or for the reset problem to be fixed. I was considering buying a GPS module to provide time since that appears to be supported but I doubt I will be able to get a signal where I plan to use this board. The RTC on this was a critical part of the design.
I am currently planning to just not use this board. I could work around the RTC issue by turning off that feature and using a raspberry pi to prepend the correct time to the record. But the fact that it will not consistently log data without hitting reset is a problem I have no workaround for. I was really hoping for a system that I could set up once and forget about it. Not a system that requires constant checking and prodding to keep running. If there is a power interruption, the SD card is removed or usbc state change, I have to hit the reset button or power cycle and reset to get it working again. I did not figure out a consistent sequence that would work before I gave up in frustration. I did try updating the firmware a few days ago just before I gave up on it.

If there is any other info I can provide please let me know.

[PaulZC]

Hi cjlyth,

Thanks again for reporting this issue - and thank you for your patience. It has had us scratching our heads somewhat for the past week!

The OLA has a helpful feature that when the external power fails or is disconnected, it switches over to drawing power from the small on-board rechargeable battery to keep the RTC running. What we had forgotten to do was to add any way to bring the OLA out of that state. As you correctly identified, you needed to:

• connect external power and then press the reset button

• or wait for the small RTC battery to discharge and then reconnect power

• or connect via USB and open the serial monitor (which also triggers a reset)

If you uploaded code via USB, then disconnected USB and then connected your LiPo battery, it would have ended up in the low power state. You would have needed to press the reset button to wake it again.

We have corrected this in version v14 of the code. The GitHub repo now contains instructions on how to use the Artemis Firmware Uploader to upgrade the OLA firmware:

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

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

Please try the new OpenLog_Artemis-X04-v14_BETA binary. We added a WatchDog Timer feature which will automatically bring the OLA out of its low power state when power is reconnected. This will, I hope, resolve your needing-to-reset issue.

The RTC keeps running while the OLA is in the low power state. The RTC should only ever lose track of time if:

• you update the firmware via USB

• the small RTC battery discharges completely

I can't tell from your description if this is why you were seeing the RTC being reset. Can you please try v14 and let me know if you see an RTC reset again? The RTC battery does take some time to charge. Please let it recharge either from USB or LiPo before trying this.

v14 also includes a new feature which will let you set the time from a u-blox GPS module. This will set the RTC to UTC, but we have included an offset feature too which you can use to set the RTC to local time instead. You will find this new feature in the Time Stamp menu but will only be able to see it if you have the GPS module connected.

I do hope the new code resolves all of your problems. Please give it a try and let us know.

Thank you,
Paul

[cjlyth]

I just installed the v14 BETA out of the master branch of your repo. After setting the time and disconnecting the power, it seems to still be logging and the correct time. I will let it run for a couple of days and report back. Thanks again for providing an update!

[maj8]

Before I found this thread I spent many hours trying to get the Artemus to log reliably to SD when powered by battery - without success. I am keen to use the Artemis Open Log for a large scale citizen science project in the sea - with the idea that the Artemis will connect via Bluetooth to upload logged data when it is hauled to the surface. In addition to the battery/ SD challenge is the firmware being upgraded to include the BLE? Grateful for any advice.
Thanks

[cworsdale]

I am experiencing this issue as well.

I am using a DEV-16832 OLA Artemis board with a 2Ah SparkFun lithium ion battery. Board works as expected and logs data to a microSD card when using a USB-C connection, but when using the battery the board seems to remain in deep sleep and requires the reset button to be pushed to turn it back on. After the reset button is pushed the board logs data to the microSD card.

Pressing the reset button overrides the RTC time and date. I tried updating the firmware to "OpenLog_Artemis-V10-v25.bin" but am still having the same issue. Do you have any suggestions?

[PaulZC]

Hi,

Please have a read through this post: viewtopic.php?p=240667#p240667

I hope this helps,
Paul

[cworsdale]

Hi Paul,

After reading through the Low Power Considerations section in the guide another time I'm understanding that it is actually the serial communication that wakes the board from deep sleep, not just connecting the USB-C cable. I am using the OLA Artemis to capture IMU data in a remote setting where it is not always convenient to make a serial connection. Is there a way to wake the board from deep sleep whenever an external battery is connected without having to press the reset button? Or is there a way to not have the reset feature wipe the configured time/date stamp?

[PaulZC]

Hi,

The No-Power-Loss version of the firmware may solve your issue. But, sadly, the RTC is reset each time power is connected. Please see: https://github.com/sparkfun/OpenLog_Art ... UPGRADE.md

OpenLog_Artemis-V10-v25-NoPowerLossProtection.bin is a special build of v2.5 which has no power loss protection

With the normal firmware, the OLA goes into deep sleep if the power fails or is disconnected. This allows the Real Time Clock to keep running, but it does mean that a reset is required to wake the OLA again.

With the NoPowerLossProtection firmware, the code does not go into deep sleep when the power is lost, meaning that it will restart automatically as soon as power is reconnected.

This can be useful for embedded OLA systems which are hard to access. The downside is that the Real Time Clock setting is lost when the OLA restarts.

I hope this ~helps,
Paul