Hi, I am looking for feedback on my ultra low power design to see if there would be any long term problems with it.
My application is using an Electron or Boron with replaceable batteries so I wanted an ultra low sleep current (around 2 uA). I achieved this by using an external STM32L0 processor to cut the power going to the Electron/Boron instead of using sleep mode. This way, the only current consuming device remaining is the STM32L0 which consumes about 2 uA in stop mode.
Specifically, when the Electron/Boron wants to be shut down, it communicates over UART to the STM32L0 how long it wants to be shut down for, then the Electron/Boron enters sleep mode. The STM32L0 waits 60 seconds before cutting power (using a P-FET in series between the battery and Electron/Boron power pin) so there is enough time for the cell modem to shut down properly.
My application has the system waking up every 8 hours, and it only turns the modem on about once per week to check in (unless my sensor senses something suspicious).
Are there any issues that could arise from power cycling the Electron/Boron this frequently?
Just brainstorming here:
What’s your thoughts on having the STM32 wanting to kill the Electron/Boron’s power after 10 minutes (for example), as a failsafe, if it doesn’t receive a Kill/Sleep request.
The Electron/Boron would be able to request a longer wake time when required (for an Alarm Condition).
So if something goes wrong with the Electron/Boron’s Code or Cloud connection, you wont burn through your battery by not being able to request a Kill/Sleep event.
A long period watchdog, of sorts.
Although this doesn’t quite pertain to my question, doing that would also be a good implementation as an external watchdog with a very long timeout compared to a conventional watchdog (which is useful for ultra low power applications).
I haven't experienced any issues nor have I read of any issues pertaining to a low duty cycle as you've detailed. I'm interested to hear about your results.
You should be in great shape, as it appears you are reading the sensor(s) on a timed schedule, verses interrupt driven.
