Feature Request - add an "always on" option for continuous serial logging with slow sensor sampling

[Beepnblink]

(also posted on sparkfun community)

I am using the OLA to log sensor data every 60s and also serial data.
The serial stream (38400Bd) consists of 4-5 packages 1s apart and repeats every 60s. I have recently upgraded the OLA to FW 2.9

Here is the problem: The serial log records the column headers sent first and one set of values and then stops. All the logged data is correct.
I can see that the serial data going to the logger is continued, but the file on the SD card does not contain any of the on-going 60s data logs. The analog data logs continue without issue, meaning the SD card is fine.
Here is serial data going in - the log stops at the start of the 4th row:

This used to work and I am a bit perplext as to why the serial loggin stops this way. I monitored all inputs and the ‘stop logging’ signal on Pin32 is not to blame here.

Has anyone experienced a similar issue with the V2.9 firmware, or is there a setting that I overlooked somehow?
Peter

[PaulZC]

Hi Peter (@Beepnblink ),

Which version of the firmware were you using previously? Does reverting to that earlier version fix your issue?

We did make some improvements to serial logging / token timestamp printing at version 2.8. I'm wondering if something in those changes has causing the issue...

Also, you say you are logging analog data too. What is the logging interval? I'm wondering if the analog logging is dominating and preventing serial logging. Have you made any changes to the analog logging interval since the upgrade?

Thanks and best wishes,
Paul

[Beepnblink]

Hi Paul,

I was using Version 2.6 before. Will revert back to that later to check the behaviour and report back.

As for the timestamp: I am still unclear at which part of the logging data sequence I should send the \r to insert the timestamp. Currently it is at the end. Starting the logging data sequence with \r caused the timestamp to be inserted after the first character of the sequence.

The analog data is temp/humididy and barometric pressure every 60s. It used to be every 10s, but there is no need to record ambient data that fast. I will try different logging rates to see if that makes any difference here.
Thanks for your asistance!
Peter

[Beepnblink]

Hi Paul,

Update: We found that the OLA was going to sleep between the analog readings. This is a default setting for analog log intervals >2s. Setting the min awake time to match the logging interval keeps the logger awake and the serial data logging.

Two comments on this behaviour:

1. Setting sleep based on analog data logging completely ignores the fact that the OLA does not wake up on new serial data arriving. Therefore when logging serial it needs to stay awake.
2. Setting the minimum awake time from the menu only allows a max time of sample interval -1s. Not sure why this limitation was necessary. I did change the value in the OLA settings file to match the sample interval. An option to switch the sleep off, or keeping it off when serial logging is selected would be better.

So there is a workaround to the problem we saw.
And food for thought to make this neater in a future revision.

Regards,
Peter

[PaulZC]

Hi Peter,

Many thanks for the update. Glad you got it working.

The firmware changed a lot over the first couple of years. You can see how the firmware developed by the Terminal Output menu numbering - new features were added to the end of the menu. Initially, you could only set one logging interval / rate. If the interval was > 2 seconds, the unit went to sleep between samples to save battery power. Then users asked for fast and slow logging. Then - based on feedback from users - we added the minimum awake time to give the user time to open the serial menu when logging at slow intervals. But slow logging was always intended to be: wake, log one sample, sleep, repeat. I think this explains why you're having difficulty with the sample interval.

Slow analog logging, but always being awake for serial logging is a new twist. I think you are the first person to request this. It's a good request. It should be straightforward to add an "always awake" option, preventing the unit from sleeping between samples. But I would need to walk through this carefully, to make sure it didn't conflict with anything else.

I'll leave this issue open as a reminder. I can't make any promises about when I'll be able to look at this. If you have the time and resources, please modify the code and send us a Pull Request.

Regarding the timestamp, the timestamp is inserted into the log file stream immediately after the token is received. You could wrap your data with line feed at the beginning, carriage return at the end, and then choose which to stamp.

Best wishes,
Paul

[Beepnblink]

Hi Paul,
Thanks for the explanation. The OLA was conceived as a sensor data logger with added serial logging capability. Based on my application I looked at it the other way round: A serial datalogger with added sensor reading option.
I may have a look at the code if I find the time. However, I am a hardware developer with some firmware skills, not a dedicated firmware guy. I may have a few questions about the implementation when it comes to it.

P.S. Looking at the datasheet it might also be possible to wake up the chip when serial data has been received. Needs more investigation though.

Regards,
Peter