10 Year Battery Life?
-
Hi All,
I have a specific LoRa use case of temperature monitoring (using the DS18B20) which must read and transmit messages every 15 minutes and the battery life should last approximately 10 years.
Some established LoRa temperature sensor vendors state that they can achieve a battery life of 10 years with 10 minute message intervals using SF7.
Using the LoPy, the best that I can achieve is approximately 8 seconds wake/deep sleep cycles, which will make my goal extremely difficult to achieve even when using a 19000mAh battery.
-
Has anyone been able to achieve significant improvements in the end to end wake(read, transmit) / deep sleep cycle (e.g. 1-2 seconds)?
-
Has anyone been able to improve the times by optimizing the ESP32 source code?
-
How can those vendors get such efficient battery life?
-
-
Pyboard's (v1.1/Lite/D SF2/3/6) has boot time about tens of ms instead of hundreds of ms of ESP32. Even for Pyboard's slower than ESP32.
I'm about to measure boot time on nRF MCU's.
About RAM : even 16 kB of BBC Micro:bit allows to do a lot of things in MicroPython, by using optimised software (drivers for low memory usage, etc), etc. For example, I've ported ulab module for BBC micro:bit, not yet published because I need to optimise the workflow for changing some source code files, then I've tested FFT for 512 float point numbers !
So 64 kB on nRF52832 or STM32WLE5, with a well developed MicroPython firmware and good practices, could be enough for many LoRa(Wan) node applications. Obviously some applications need a lot (even 1-2 MB) of RAM, so there is always a need of 'super-microcontrollers' for intensive Edge Computing, etc.
-
@rcolistete The big question with all these MCUs when it comes to using them with MicroPython is whether (enough) RAM is still powered during deep sleep.
If there's no RAM or very little RAM powered during deep sleep, then it's still the same issue as with the ESP32, the whole micro python startup time uses a lot of time and power. Using chips that are slower than the ESP32 will probably be a trade-off of lower instantaneous consumption and longer boot time.
I may be wrong, but my impression is that if you want to really get the most out of any MCU in these low power scenarios, you don't have much choice but lower-level languages like C (or even assembler) and careful optimisation of the memory needed so that it all fits in memory that stays powered during deep sleep (or any state is saved to flash).
Also even if you can run MicroPython with 64 kB of RAM, I suspect you will quickly hit limits if you try to do anything meaningful, won't you?
It would be interesting to find out what takes MicroPython so much time to start up (at least on the LoPy), though. It's quite possible there's a ton of stuff which could be removed if not needed to optimize all that.
The other place where I think there's quite some optimisation to be done is the delay between TX and the RX windows. It should be possible to switch to light sleep during that time somehow.
-
@rcolistete Thanks for the suggestion. I am using Tadiranbat LiSOCI2 19000mAh batteries.
-
@robert-hh Thank you for the suggestion.
-
But my hope for 2021 is that Pycom (or another company) releases a MicroPython board using the STM32WL microcontroller, the 1st SoC (System-on-Chip) MCU with LoRa. STM32WLE5CC/JC has 64 kB of RAM and 256 kB of flash, enough to port
MicroPython.STM32WL doesn't have WiFi, so it will be useful only as LoRa(Wan) node (not to be used as LoRaWan nano-gateway). It runs @ 48 MHz, with low power specs :
- deepsleep : 31 nA (shutdown), 360 nA (standby with RTC), 1.07 μA (stop2 with RTC);
- < 72 μA/MHz x 48 MHz = 3.456 mA;
- 5.4 mA in LoRa RX;
- 15-87 mA in LoRa TX (10-20 dBm).
- MCU @ 2 MHz uses 0.6-0.7 mA;
- has LPRun (Low Power Run) mode so that @ 2 MHz is uses 0.22 mA, while @ 0.4 MHz it uses 52 uA.
-
I'm almost receiving (due to arrive in few days) a RAK4600 LoRaWAN Breakout Module, US$18 at :
It has :
- a MCU Nordic nRF52832, i. e., ARM Cortex-M4 32-bit with FPU @ 64 MHz, 64 kB RAM, 512 kB internal flash, Bluetooth 5.2 2 MBps, NFC, 1 ADC 12 bits 200 ksamples/s 8 channels, 2x I2C, 3x SPI @ 32 MHz, I2S, 32x GPIO, 3x 4-channel PWM, 5x 32-bit timers, 3x RTC, 2x UART, USB 2.0, 128 bits AES HW encryption;
- SX1276 LoRa transceiver.
- power consumption from RAK :
- Tx mode LoRa @20dBm = 125 mA with LoRa @ PA_BOOST & BT sleep;
- Tx mode LoRa @14dBm = 92 mA with LoRa @ RFO & BT sleep;
- Rx mode LoRa @37.5Kbps = 17mA with LoRa @ Receive mode & BT sleep;
- Tx mode BT @4dBm = 9mA with BT Tx mode & LoRa sleep;
- Rx mode BT @2Mbps = 11.5mA with BT Rx mode & LoRa sleep;
- sleep mode = 2.0uA with LoRa & BT sleep.
RAK4600 accepts 4 ways to use/develop :
- AT commands sent by a microcontroller or computer using UART;
- Arduino with support from RAK :
- MicroPython with support from RAK, but with less LoRa(Wan) features and documentation than Pycom implementation;
- Rakwireless Unified Interface (RUI).
-
@kyushin As mach as I like the Pycom devices, the Lopy4 may not be the best device for this kind of task. Better are small Lora Modules designed for low power consumption, like e.g. https://wireless-solutions.de/products/lora-solutions-by-imst/radio-modules/im880b-l/. Obviously using them may be more difficult.
-
Are you using LoPy alone or with some board (Expansion Board v2.0/v2.1/v3.0/v3.1) ?
Which type of battery are you using ?
Li-Ion/Li-Po have self discharge incompatible with 10 years of operation. LiSOCl2 (lithium-thionyl chloride) primary batteries have very low self-discharge, for example :
One option to decrease power consumption is to use SparkFun Nano Power Timer - TPL5110 to define the total period of deepsleep+active cycle using the dip switches, so that the current during deepsleep is 0.04 uA.
-
@jcaron Thanks very much for the suggestions.
-
This post is deleted!
-
@kyushin The LoPy is clearly not the best device when it comes to extracting the best lifetime out of a battery.
The issue is that the advantage of using a higher-level language such as micropython comes at a cost: there's a quite a significant overhead, both when starting up (a good 1-2 seconds with a pretty high consumption, and since deep sleep means a reset, that happens on every cycle), and while running, even when doing nothing (waiting for the RX windows).
However, 8 seconds seems a bit long to me. How long does it take to read a temperature sample from the DS18B20? What are the network's RX windows delay settings?
One cycle should be:
- Wake-up on timer, startup: about 1-2 seconds (depends a lot on firmware version, size of your code...)
- Read sample
- Send data: at SF7 it should take less than 100 ms
- Wait for RX windows: up to 2 seconds with default LoRaWAN settings
- Go back to sleep
From what I understand, one can get a sample from a DS18B20 in less than a second.
So in total, you should be able to get down to about 5 seconds.
Counting about 100 mA average current while awake and about 20 µA while sleeping, on a 15 minute cycle this would give you an average current of about 600 µA. 10 years would then require a 52000 mAh battery :-( Average awake current is probably less than that, but even at 50 mA you'd still need 26000 mAh.
Things you can try:
- Make sure your code is the smallest possible
- Freeze your code into the firmware
- Go to light sleep while you wait for the sensor to give an answer
- Make sure you send the smallest data frame you can
- Measure current consumption during a cycle
Last time I checked (a looooong time ago), the LoRaWAN stack was running on a 1 kHz loop rather than being fully interrupt-driven. I don't know if that has changed since then. This causes a pretty high current draw while the LoPy is waiting for the RX windows, even though it has nothing to do. I don't know if going to light sleep during this time is an option? Never tried it.
NB: make sure the network does not use longer RX window delays. A network I had to use had a 5-second RX window delay. That sure makes things a lot worse (this adds 4 seconds to the total awake time).
I have no idea of the best option for the DS18B20, but for some sensors (and intervals), it is best to switch off the sensor during sleep, even if that takes a little longer on wake up, while for others, you're better off keeping the sensor on even during sleep. Or use various power saving modes.
Devices that are programmed "closer to the metal" (in C or other lower-level language) can startup a lot quicker. Also an optimised device will go back to some form of sleep during the RX windows wait. This cuts the actual awake time to less than a second per cycle, even if parts of it are only light sleep and not deep sleep. Smaller microcontrollers will also retain what little state they maintain while sleeping, which makes things a lot easier.
Good luck!
