Feature Request: Check status of pin 11 to exit Slow Logging Mode.

[ryanneve]

@PaulZC , while BLE is our #1 want right now (any updates?), #100 made me think of a similar feature. Right now you can use pin 11 to go into slow logging mode (longer sleeps). It would be nice if you could exit low power mode if the status of pin 11 changes while asleep. It would even improve your example sunlight monitor by waking sooner when there's light.

For example, we might have logging set to every 5 minutes when PIN11 is low and 60 minutes when PIN11 is high. The OLA would sleep for 5 minutes at a time, but only wake up enough to check pin11's status (no . If it was still unchanged, and less than 60 minutes had passed since the last sample, it would go back to sleep. In theory you could set the slow sleep period to infinite.

As far as implementation, I think rather than set a longer sleep time with checkSleepOnFastSlowPin(), you'd need to split wakeFromSleep() into two levels. The first level would be just enough functionality to check some critical status items, like pin 11. You'd need to calculate time since last sample, and compare it to settings.slowLoggingIntervalSeconds. Hopefully this brief change from fully asleep to partially asleep wouldn't have major power consumption ramifications so long as the fast sampling interval isn't too fast.

This intermediate sleep level might also be useful for waking on IMU interrupts as was requested in #100, or just IMU changes. I could see "wake if any IMU orientation value has changed more than X% since OLA started sleeping" could be useful for some people.

[PaulZC]

Hi Ryan (@ryanneve ),

Thank you for the suggestion! But it may not be straight forward to implement. If the battery voltage goes low while the OLA is asleep, using Pin 11 to wake it will cause the OLA to glitch, reset and lose the RTC setting. It is similar to #105.

In summary, I will need to think about this... (And that might take a while!)

Re: BLE. It is still on the things-to-do list. But we are a small team and we have many other projects on the go. The new smôl boards are taking up most of my time at the moment. So, it is still coming, but, right now, I can't give you any kind of estimate of when I will (finally!) get around to it. Sorry about that.

Very best wishes,
Paul

[ryanneve]

@PaulZC , I'm not suggesting to use pin 11 to wake the OLA (as an interrupt). I can see difficulty that would cause. I'm suggesting to wake up more often, at the fast sample rate, and check pin 11.
If you split wakeFromSleep() into two parts, the first part would just initialize enough to read pin 11, and compare the clock to the last sample time. If the ring conditions are met, it would go on to wake up fully. If not, back to sleep.

As a bonus, I don't think any menu changes would be necessary. This would only take effect for reasonably slow sample rates (> 5 sec?).

[PaulZC]

Hi Ryan,

Ah, sorry, I had misunderstood.

We should be able to do that. The pin 11 part should be straight forward. Getting the IMU involved would require a lot more code and testing.

Best wishes,
Paul

[PaulZC]

Hi Ryan (@ryanneve ),

I wasn't able to include this in v2.2. It would have taken a lot of thought and testing to add this feature. Including a fairly major re-write of howLongToSleepFor and wakeFromSleep. The testing would have to be very thorough to make sure these "slow logging" changes didn't change anything for the normal "sleep between reads" functionality.

I'm going to leave this issue open and I may be able to get to it in the future, but sadly I don't have time to implement it right now.

Best wishes,
Paul

[ryanneve]

Paul (@PaulZC ),
We have seen such a big improvement in battery life by powering our BLE module off of the qwiic bus, that we no longer use an external sensor to vary sample rates. We just sample fast (6 min) all the time. As such, this is a low priority.
Still might be a nice feature for someone.
Thanks!