I have made some useful updates to my OLA by connecting a LiPo 700 mAh battery and remote control PWSC and reset switches.
I’m using it for in-car acceleration measurements, it is now super easy to operate and the data looks very plausible.
But a big practical problem is that the date and time stamp on the files doesn’t seem to work reliably. I have already updated the time and date several times through the main menu, but it doesn’t apply the stamps to the files all the time and it looks quite random. Sometimes the files are getting the right time and date, but mostly not and sometimes it’ll only stamp the correct year, but the rest remains zeros. Any thoughts?
The RTC battery may not be fully-charged; let it charge for ~24 hours and re-try
Which timestamp token are you using? OpenLog Artemis Hookup Guide - SparkFun Learn
I’ll give that a try. The LiPo battery was fully charged yesterday evening, so hopefully tomorrow I’ll have more luck when I’ll be doing more measurements. I’ll let you know.
Regarding the timestamp token, I’m using the menu options 4 and 6 (manual entry)
Unfortunately I cannot get the date stamp to work reliably. It all seems to be very random: in one and the same session I’m getting no date/time stamp at all (2000/01/01 00:00) or everything (2025-04-21 20:27) or partially date stamped (2025:01:01 00:00) and I cannot see any pattern. I’m also seeing non-date stamped files containing measurement data lines with some or all of the correct date/time data. I have had the unit left hooked up to the USB port overnight and it is also powered in parallel by the LiPo battery, which is confirmed to be fully charged (orange LED turns off), so I struggle to see how the RTC isn’t getting charged. When I leave everthing switched off for a couple of hours but with the LiPo battery hooked up again all time/date date is lost.
The other really difficult problem is that the sampling frequency is resetting itself regularly. I need to measure everything at 100 Hz and it keeps resetting itself to 10 Hz unexpectedly, yesterday I lost hours of testing time in the believe that I had some very good measurements. When I copied the files they were all too small and turned out to be sampled at 10 Hz, very frustrating…
Today I thought I had everything running more or less reliably at 100 Hz, but the runs with USB disconnected (ie just running on LiPo battery) turned out to be sampled at 63-ish Hz. Reconnecting to USB immediately made it return to 100 Hz. In the last hour the sampling switched itself again to 10 Hz.
All of the above makes me feel that I’m doing something wrong, but I think that I’m following all of the instructions in the on-line hook-up and configuration guides.
One point drew my attention in the guide that I had missed before: apparently if you have the power switched off and you press reset the RTC resets itself, losing the timing/date information. Almost certainly I have done that in the last days unknowingly a few times, but today I have been very careful not to do that. Any suggestions? Due to the unpredictability of how it will take data this system is almost unusable for my purpose, but I haven’t given up yet: I did take some useful data in the last few days and the quality of the data is then really good.
Hi @adevlugt ,
If you haven’t already, please have a read through this section of the hook-up guide:
especially the section on “Stop Logging and Reset Buttons”. If you need to disconnect the power or USB between measurements, the trick is to “stop logging”, then disconnect, then reconnect, then reset if needed. Reconnecting USB should generate the reset to “wake” the Artemis. You will need to press the reset button after reconnecting LiPo power.
If you are changing the settings via the serial menu, make sure you fully exit the menus before putting the Artemis to sleep. The settings are only saved when you exit the main menu and the firmware returns to logging.
I hope this helps,
Paul
Hi Paul,
Thanks for the additional advice.
I have read through this section again and I have installed a remote stop logging switch (between pin 32 and GND) on the board. And I have taken extra caution to make sure that every time I make changes in the menus they are saved correctly.
Now here comes the frustrating part: I have tested everything at home on the bench and was starting to get a warm feeling about the stability, but out in the field, testing again it was totally unworkable: again losing time and date stamps, even between test runs (when I was only operating the reset and stop-logging buttons) I saw on the terminal things getting out of control: after one stop logging event, the unit starting dumping data to the screen again, resetting the frequency to 10 Hz, lost the DLPF settings and lost the power menu options setting for using pin 32 for stop logging, so couldn’t even stop by pressing that switch.
To make matters worse Tera Terminal started printing unreadable non-ASCII characters again, which I have seen randomly happen before and usually it sorts itself out, but even after shutting down everything and restarting it kept doing that. After 1.5 hour fiddling with everything on the side of the road I gave up and went home.
I’m starting to really scratch my head now…
Hi @adevlugt ,
Apologies for the hassle.
Please try a different microSD card. Some cards take a big gulp (in-rush) of current at power-on, enough to make the OLA power circuit brown-out. Hopefully you can find a card that the OLA is happy with.
Apologies again,
Paul
Hi Paul, thanks for staying with me on this one.
I owe you a bit of an update, but I’m afraid the bottom line is not happy days.
After the last post I have experimented a lot on the desktop including with different SD cards before getting into the car again. I had two successful days of testing after making the following changes.
- I run my laptop in the car no longer off the internal battery but have installed an inverter and keep the laptop running 100% of the time
- I do not unplug the OLA from the USB port once it’s running until I have all measurements completed.
- I accept that the RTC is not at all reliable, cannot get anything reliable to record, but it’s not a biggie for me: I stop after each measurement and write down the filename manually. Not ideal, but it works for me.
- With terminal logging switched on I cannot get above 40 Hz, but with terminal logging switched off I can reach 100 Hz, so the SD card is not the bottleneck. Couldn’t always get it to start at 100 Hz, but after several resets it would eventually pick up the 100 Hz again. BTW the SD card I use is a SanDisk Extreme Plus 32 Mb V30 HC1 A1.
This all worked well until this morning when two measurements (which typically last 120 sec) prematurely stopped after appr 60 sec.
After a further reset I received the error message on the terminal as displayed in the screenshot. After trying everything including reformatting the SD card I gave up and drove home.
At home I reinstalled the firmware, but kept getting the same error message. Then I noticed that the SD card also didn’t want to read/write anymore in a normal card reader on the laptop. The SD card was cooked.
Good news: with other SD cards I could get the OLA to start up again. On some cards, I cannot get any higher than 60 Hz sampling, but on two other cards I can get back to 100 Hz (identical spec to the one that blew up) and on a SanDisk Ultra Plus 256 Gb I can get to 90-95 Hz. But here comes the most annoying part: totally at random the system throws in a switch from 100/90 Hz to 60/65 Hz and back. I have tried different formatting, but it is completely random.
And to top it off, also randomly the system deletes all settings, including filter settings, goes back to 10 Hz sampling, screen dumping data after a reset.
I cannot find any pattern in why this is all happening.
I have done a lot of similar acceleration measurements professionally in the past and when the system works, these results are as good or better than any I have ever seen from far more expensive measurement system, but the unreliability is its Achilles heel. In the moment it is unworkable. Do you have any other suggestions?
Could it be that there is any hardware problem on my OLA?
Any further help is much appreciated. I’m on a timeline to produce results for a scientific paper and I’m getting nervous…
instead the latest OLA firmware try earlier versions. while in new versions there are bug fixes, there are also new sensors supported. Maybe they are in your way.
For info about changes made in OLA see: OpenLog_Artemis/CHANGELOG.md at main · sparkfun/OpenLog_Artemis · GitHub
For the older firmware: OpenLog_Artemis/Binaries at main · sparkfun/OpenLog_Artemis · GitHub
I’ll give it a try in the next couple of days
1 Like