Deep sleep modes: enter deep sleep for power saving & Restart recording/detection automatically

[EDsteve]

This is actually an important topic which i haven't talked about yet. And maybe challanging? I am not sure.

Scenario: The ELOC is running with solar power and recording in the jungle. Now there is 2 weeks no sun, the battery gets drained and the ELOC turnes off. After a while the battery recharges slowly and the ELOC starts again (if it does not get caught in some weired boot state?). But recording has stopped so it needs to be started manually through the app again. Rangers only check the devices every two or 4 weeks.

Wishful solution: The ELOC should put itself in deep sleep mode when the battery level is critical (Let's say <10%). In deep sleep it can stay in a stable state for a few days, wakes up every few hours to check the battery level and if the battery is full enough, the ELOC starts recording automatically.

Is that a realistic thought?

[LIFsCode]

Just to link the discussion from here

@OOHehir Yes. You got it right. If the device is ON, and not doing anything (No BT connection, no recording, no EI) it should go to sleep. Let's say after 5 minutes or so for now. With the firmware before the merge. The device wakes up from the knock sensor on GPIO12 (This might not help in the walking-through-jungle scenario). But let's keep it for now like that.

If i remember correctly some pins are able to wake up the ESP32 from deep sleep. Maybe that's the reason the ESP32 still uses 6mA instead of <1mA in deep sleep? @LIFsCode

Hi @EDsteve @OOHehir Let me intervene at this point ;-)

deep sleep @EDsteve asked for a intruder alarm based on accelerometer repeated action that will cause the buzzer to constantly beep. If that's still the case, I doubt that anyone would carry around the ELOC with forgetting to turn off.

Anyway if the deep sleep option remains a requirement we should be very careful with condition for entering deep sleep to avoid other problems, e.g. a ranger won't notice that the device entered deep sleep and wandering why it won't respond.

Concerning wakeup source: I assume a simple power cycle by the on/off switch would be the more stable (I know and less elegant ^^)variant. It avoids accidentally turning it on by something pressing on the button in the backpack. The on/off switch is a bit more robust.

Light sleep This is already enabled by the power config. The freeRTOS is automatically entering light sleep, once no wake locks are taken. Light sleep means that the main system clocks are stopped and only the low power RTC clock is running.

That means the following modules prevent light sleep:

• Bluetooth (unless provided with an external crystal
• I2S (as mentioned above)

Besides that there is an effect of the PSRAM on power during light sleep, but I would treat this as negligible as it's in the range of a few 10s uA.

Sorry it has been a long post, but the power management is quite a topic. I hope I've been comprehensible

@EDsteve Based on the above do you still think this feature is a requirement?

@LIFsCode If this is a requirement perhaps this could be implemented by a simple task that:

• sleeps for 30 sec then,
• wakes & checks to see if the wav file writer, Bluetooth & EI inference tasks are running.
• • if they're all inactive/ disabled increment a simple counter
• • if any are active clears the counter
• sleeps again & repeats the above
• if counter gets to X, enters deep sleep & doesn't return, requires a power cycle to exit.

@LIFsCode @OOHehir

Intruder alarm:

I doubt that anyone would carry around the ELOC with forgetting to turn off.

I had the same thought when making the buzzer table :) Therefore I was already thinking about a setting in the app "Arm device during record. ON/OFF". That would only have the device armed while recording after it's already set up and not while setting up or carrying around for example. It's not a mandatory feature. But I would love to test that because i am sure it will help with monkeys and humans.

Sleep: I have been out in the field with rangers. They will deal with 50 and more devices. Forgetting to turn some devices off is a common mistake. Then the battery gets drained while sitting in the basecamp or on the way in the jungle. Its no fun to realize that you carry around a few KG of empty batteries for a few days. (Not all ELOCs use solar panels)

But your doubts are true too. It can be confusing for the rangers when the device doesn't respond. It's similar with the BT time-out. Easy to get confused when i don't find the ELOC in the BT list of the app any more. And wonder what happened. (Yes. The app is online, but still work in progress.) That's because BT timout is now set to 60 sec just for testing. But later will be set to 30 minutes or more to give enough time setting up the device. (BLE could be always on and would make life easier in that regard. But that's a huge task if i see that right.) Also the sleep mode should happen after one hour or so and not after 5 minutes as i sugested earlier for testing. That should reduce the chances of confusion.

Waking up the device from the ON/OFF switch sounds good to me. I think that is the first thing everybody does when something doesn't respond: Restart :)

Deep sleep or intruder alarm are handy features which would make a difference in my opinion, but this feature might be more impartant which also uses deep sleep.

@LIFsCode Now i feel more sorry for a even longer post :) @OOHehir Thanks for the new commit. I will check it out soon.

[LIFsCode]

@EDsteve @OOHehir I try to make a flow diagram to visualize this to bring things together.

@EDsteve any other conditions triggers which should enter deep sleep and/or wake it up?

[EDsteve]

@LIFsCode

any other conditions triggers which should enter deep sleep and/or wake it up?

Nothing i can think of right now.

[LIFsCode]

Ok so If I understood you correctly @EDsteve we are talking about 2 different scenarios for deep sleep:

1. Deep Sleep after idle

See comments above. This scenario leaves a lot of open questions:

Sleep mode Triggers:

1. No Recording active (I think that's clear)
2. No Detections active (I think that's clear as well)
3. No BT connection (or should we allow sleep with BT connection, but just inactivity?) --> potential source of handling issues
4. No knock activity (accelerometer) --> don't know if that makes sense depends on the scenario.
5. Idle time? --> should be configureable, default? 60 Minutes?

Sleep mode Behavior:

1. Infinite sleep mode , wake up through power cycle (on/off)
   • (simple, the device will always restart from PoR, no need to save any pre-sleep states
   • robust on/off switch has to be explicitly handled, no accidently wakeup
   • matches the scenario of a "forgotten to turn off ELOC"
2. external wakeup source:
   • could be accelerometer --> does not make sense in my opinion, when the ELOC is carried around, but would match the wake up behavior for Bluetooth --> to be discussed
   • GPIO-Button : not very robust, pressing duration could not be set for wake up triggers as far as I know--> possibility of accidently wake ups
3. timed base wakeup
   • possible, but with what benefit? time must be large enough to get a power saving effect. But if it's large the ELOC won't be responsive, hence an impatient ranger would most likely power cycle the ELOC to get a connection

2. Deep Sleep with low battery

This scenario is actually new to me, I interpret it the following way:

@EDsteve : is that correct?

1. Should the ELOC return to previous operation? This would require that we store the current operation mode to either SPIFFS or SD card (prefereabe SPIFFs)
2. What should be the trigger for restart? what battery level do we require to guarantee a certain amount of operation, so that it makes sense to restart. I assume a runtime of a few minutes would be way to less.

Problems I see here:

1. Definition of high/low Battery state of charge is extremely difficult based on voltage alone and very errorprone
2. The timebase will be very inprecise (or maybe even reset) during deep sleep. This causes the timestamps after wakeup to differ significantly from the ones before. --> does this keep the data useable?

[EDsteve]

@LIFsCode Sorry for the late reply. Was pretty busy the last days.

1. Deep Sleep after idle

Since this (similar) feature was already implemented in the FW before the merge, I didn't expect it to become that big of an issue. I was assuming it will be a 30 minute fix or so. But i guess it never is and now i realize it needs some brainstorming :) This feature has lower priority and we can deal with it any time. But to answer your questions:

Sleep mode Triggers:

1. No Recording active -> Correct
2. No Detections active -> Correct
3. No BT connection -> Correct
4. No knock activity (accelerometer) -> Debateable but i also think this is the best way
5. Idle time? --> 60 minutes or even more

Sleep mode Behavior:

• Push buttons are only accessable when you open the casing. So that should prevent accidentaly pressing it in the backpack. For that reason both would work in my opinion: Wake up from GPIO0 and/or restart with ON/OFF switch.
• Time based wake up: no
• Wake up from knock sensor: no

2. Deep Sleep with low battery

To resurrect the ELOC once the battery recovers is a very good feature to have in think. Specialy In detecting mode. If there is no need for the rangers to change SD cards every few weeks, it will stay in the jungle for months without being checked on. Not sure if the deep sleep solution is the best way to achieve that. But that's what came up in my mind.

Your flowchart shows exactly what i meant. I have added the SPIFFS-check in the flowchart. To make it complete.

Problems:

1. Inaccurate battery readings are indeed a problem. But worth a shot. I would start with values like these and see what happens (LiFePo4): Deep sleep at <3.00V and continue operation at >3.25V
2. The ELOCs without LoRa/GPS module will have the time drift problem. And from what i have just read it is a few minutes per day. Hmm. That's ineed a bit much. Didn't realize that. External oscilator could solve that. But not sure if it's worth it though. ELOCs with the LoRa/GPS module can get the tiime from GPS. So these should be fine.

For the end-product (detector with LoRa) this feature (or similar) is a must have. But has no high priority for the next few weeks/months.