10 Year Battery Life?

[kyushin]

This post is deleted!

[kyushin]

@jcaron Thanks very much for the suggestions.

[rcolistete]

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 :

• Saft;
• Tadiranbat.

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.

[robert-hh]

@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.

[rcolistete]

I'm almost receiving (due to arrive in few days) a RAK4600 LoRaWAN Breakout Module, US$18 at :

• RAK Store;
• RAK at AliExpress.

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 :

1. AT commands sent by a microcontroller or computer using UART;
2. Arduino with support from RAK :
3. MicroPython with support from RAK, but with less LoRa(Wan) features and documentation than Pycom implementation;
4. Rakwireless Unified Interface (RUI).

[rcolistete]

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.

[kyushin]

@robert-hh Thank you for the suggestion.

[kyushin]

@rcolistete Thanks for the suggestion. I am using Tadiranbat LiSOCI2 19000mAh batteries.

[jcaron]

@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]

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.