Tech notes and thoughts on entrepreneurship.
As part of a modding/tuning excercise I disassembled the radio. I used this opportunity to measure this radio’s latency properly, using test equipment.
Tl;dr: the best-case latency observed was 13 ms, the worst-case was slightly over 43 ms. The typical was between 25-35 ms. Not great, not terrible.
The Helium Network is a LoRaWAN (~IoT) network provider — similar to TheThingsNetwork — which incentivize people by giving away its own cryptocurrency for creating network coverage. So far only a handful of us were trying to create LoRaWAN coverage in Hungary. Nowadays hordes of clueless fucks climb their roof to install their €500-1000 “miners” (most of them facing 5+ years of ROI).
The results are awesome. This is one of those rare occasions where stupid people can make a great service for the majority.
In this post I’ll show a relatively easy way to scale the MCU clock dynamically.
There is a section in the STM32L4 MCU’s datasheet called “Supply current characteristics”, and it has an interesting table detailing power consumption for various payloads as µA/MHz.
Such a table suggest to clock the MCU to a reasonably high frequency, and go to SLEEP mode as soon as CPU is not used. Unfortunately, having the CPU in SLEEP mode at 8 MHz consumes ~250 µA (range 2, 25 °C), while SLEEP mode at 48 Mhz sets you back by ~1.34 mA (range 1). There is more than 1 mA difference for the same task (doing nothing), and it increases significantly at higher ambient temperatures.
In general, the way to long battery life are the STOPx and STANDBY modes. However, if your project needs fast clocks only for a short period of time, and works fine at lower speeds in the rest of the time, this trick will come handy.
STOP2 and STANDBY modes are great way to achieve uA and sub-uA consumption. When using an RTOS, the tasks must synchronize when to go to deepsleep, especially to STANDBY mode, which requires most hardware modules to be re-initialized.
I’ll show here the latter one.