I am currently developing sensor nodes using LoRa class A to send the data. However, to reduce battery consumption on the arduino (Heltec ESP32 + LoRa v2.1), I wanted to know if it was possible not to listen for downlink messages after an uplink. Instead, I would like to immediately go back to deep sleep. Is it something that is possible?
The image below shows, in blue, the actual power consumption when sending and in red, what I would like to get (i.e. going back to sleep immediately)
That wouldn’t be LoRaWAN compliant and as neither the stack or you would be able to adjust any settings remotely, you aren’t going to see much enthusiasm for such a scheme.
You can sleep in the seconds between end of Tx and the Rx1 window.
Or put in a slightly larger battery.
Or both.
Or dual power with solar/LiPo with backup non-rechargeable battery.
What is the use case? If you extend the device life from say 3 years to 5 years, will it still be relevant in 4 years time?
The goal was just to be able to reduce the battery consumption even more (if possible). Now, you confirmed me it would not be LoRaWAN compliant. Thanks!
To increase the battery life, I in fact used multiple batteries.
Yes, in fact, we are using this board: https://www.amazon.fr/dp/B076T28KWG the current goal is to prototype. Is there any other (low power) board you would recommend?
RocketStream will soon have a Mini-Ultra-Pro-LoRa with a RHF0M062 radio and M0 processor… Its designed for very low power, battery operation.
The RHF0M062 radio contains the full LoRaWan 1.0.3 stack and is control via AT commands from the SAMD M0 CPU on the base board…
Battery charger options for a number of battery chemistry, options for a GPS and other sensor on the board…
Same pin-out as their current Mini-Ultra-Pro
(All of my project for my customers have move away from the RFM95 and unsupported LiMC to the RHF0M062 or the newer RHF0M0E5 radio… Never going back to LiMC and RFM95 radios…)
If your prototyping, for a commercial product, then the ESP32 is actually OK.
You can build your own ESP32 bares bones board which has a deep sleep current of circa 25uA, its not difficult.
Once you get down to the 25uA or so sleep current level, you can more or less ignore it, since the batteries are going to self discharge a lot quicker anyway.
@descartes mentioned Alkalines as an OK choice and I would agree, they have a shelf life of around 5 years and are real cheap from places like Ikea. In 5 years a 25uA sleep current would use around 50% of an AA Alkalines potential capacity.
Yes you can get sleep current for nodes down to 2uA and lower but unless your trying to run a node on tiny button cells, there is little to be achieved by going this low apart from improving your marketing hype.
Rising HF will soon have a 1.0.4 firmware for there modules, and 1.1.1 is in development, firmware upgrades are easy to do with this module. The difference between 1.0.3 and 1.0.4 are minor.
MCCI has done a great job at keeping LiMC alive, but moving on to a complete integrated asynchronous solution for about the same cost as an RHF95 make design decision easy.
The CPU can concentrate on the sensor code and its power management and let the radio module do it work asynchronous. Best of both worlds. In high volume application the user code can be integrated into many of the module if needed.
Rising HF, RAK Wireless, Ai-Thinker, Ebyte, Murata, Microchip and others, all make modules. We have looks at many of them for our projects.
