ajlennon
commented
5 years ago The way I usually visualise the sleep/wake cycle is something like this.
So the cycle is
- deep sleep (most of the time)
- wake, load code, setup, house keeping
- radio on transmitting
- radio on receiving
- radio off, house keeping
- back to sleep
Deep Sleep / Low Power
Over long periods (months/years) of time the quiescent currrent consumption becomes important. To deal with this we need to look at
- core consumption of the chip in deepest possible sleep we can wake from
- pin leakages (from pin setup in software and hardware design)
- other components on the board e.g. regulators, battery chargers, USB-serial ICs, etc., which are in a quiescent mode (for good design we would want to be able to power down their power domain)
Most notably we don't need a battery charging circuit for our design and we don't need a USB<->serial bridge on board for production units. This also impacts cost.
Other considerations are that early TTGO variants have external flash which can't be turned off. The upcoming Wifi Stick in #6 apparently uses an ESP32 variant which addresses this
Runtime
-
We need to be able to wake as quickly as possible. Questions here are around clocking for speed and loading code from flash / SPI memory to RAM which seemst to take considerable time. We may wish to look at how the load can be speeded up (is it being decompressed? what's the SPI clock rate?)
-
Then there is setup house-keeping. Often in poor code there are delays hardcoded in here and we could look at some analysis with a 'scope to see where time is going
Radio On Time
-
Radio on time is orders of magnitude more power consumptive than other modes of operation so we need to completely understand the minimum requirements for on time. In particular poorly coded radio stacks often have un-needed timing delays. We should evaluate what is happening in the LMIC stack.
-
Also spreading factor very significantly impacts radio on time so this needs to be determined in terms of Tx power and distance we need to achieve in specific environments.
-
Radio Rx on time impacts consumption significantly so we need to understand how long we are waiting for RX1 and RX2 windows, why we would use RX2 windowing and so forth
Guesstimates
I've put some finger in the air figures in here
- 10uA for deep sleep
- We're looking at say 10mA for run with radio off
- Then 50-13mA with radio on depending on Tx power
What I'd normally do is put a spreadsheet together based on the above model which allows us to play with consumptions and timings to give an overall power budget and thus device lifetime
Aiming for a 150mAh battery, which gives 3hrs of operation at high power, but 2 years at 10 microAmps. Does the battery control circuit become significant then?
What wiring pins should it take to get past the regulators?
How do we recharge the battery? (when the microUSB is not accessible)
How does the device measure its battery use?
A final board would have its battery regulator on the board, connected to a bare lipo, and this may have the information on battery use known to it.
In the meantime, the device should estimate its cycle time and up time in order to calibrate its battery use. A fast frequent cycle that runs it down in less than a day should get estimates pretty quickly.
We should have a mode that operates on a frequent wakeup cycle (of long durations) to be able to make estimation experiments automatically and pretty quickly in order to know the variability (a) per battery, (b) per microcontroller board, (c) at different temperatures, (d) after storage.