[Yup, I’m determined to find out what the quota for concurrent build logs is 
]
I’ve been using my own little wireless room sensors for many years, here’s a somewhat beaten-up and hacked-up one:
These use an STM32L072 and a RFM69 FSK radio. They work well after I spent a lot of time tuning the radio parameters, but they have a pretty short range, at least at the 50kbps modulation I use. I made some with sx1276 LoRa modules as well, but never managed to get over the hump to actually switch everything over. The LoRa modules also aren’t/weren’t that cheap…
Since I want to get familiar with the STM32WLE5 series I figured I’d create a fresh design so I learn the RF design part and also to get some real-world experience with LoRa.
My first step was to acquire some stm32wle5 parts, which hasn’t been easy. Now that I have them, I started to plop down stuff onto a schematic until I hit a roadblock: do I need a power switch to turn the temperature/humidity sensor on/off or is their sleep mode low enough?
There’s only one way to answer that (other than building and measuring), which is to create a spreadsheet and total up the mAh’s (milliampere-hours). For this design I’d like to power everything straight from CR2032 cells without voltage regulator and I find that totaling up mAh is easier than to total up Wh or Joules because I mostly get to ignore the varying voltage (from ~3V down to ~1.8V). The switch mode power supply in the stm32wle5 throws a bit of a monkey wrench into that, but it should be close enough.
So here’s my spreadsheet, which assumes that the device collects a measurement once a minute (green columns) or once every 5 minutes (blue columns) and sends it off plus gets an ACK (this is not LoRaWAN).
I divided the scenarios further into 14dBm TX power at 125-10-5 modulation (bandwidth - spreading fct - redundancy) in the upper rows and 0dBm TX power at 125-7-5 in the bottom rows. So this represents distant devices vs nearby devices.
For each scenario I took the major components: stm32 cpu, lora radio, bme280 sensor, and sht31 sensor. Then broke out the major phases, such as sleep and measuring and finally poured through the datasheets to see how much current each phase consumes and how long it would take.
The avg[uA] columns shows the average consumption over the whole period and the avg[%] shows it relative to the total consumption. The red cells show the bottom line, which is expected run-time on a (good quality) CR2032 with 30mA current pulses.
What jumps out from all this is what I’ve already experienced with my RFM69 FSK sensors, which is that TX power is almost all that matters! The low bit rates of LoRa compared to the 50kbps FSK I use make that even worse. I wonder how the trade-off between the better margin of LoRa vs. the longer TX times will play out in real life.
Here’s a screen shot of the TX power over the past 24 hours for a collection of current FSK sensors. These sensors adjust their TX power based on the ACKs they receive from the gateway in order to hit a pre-determined SNR.
Clearly the sensors at the bottom will loose from using LoRa 'cause they can’t go lower power so they will just suffer from longer TX times (at least that’s what I expect). But the ones at the top, i.e., the ones that annoy me by having to swap out batteries every couple of months, hopefully will gain ! ? ! ? ?
[Side project: why do the TX levels of some sensors swing so much?]
Back to my original question: do I need a power switch to fully turn the sensors off when idle? It’s pretty clear that I don’t!
(Note that I expect to only use one of the two sensors, I haven’t made up my mind yet and the easiest thing was to pretend I’d use both.)
Comments, suggestions, or questions appreciated!
