Low power wireless check-in solution

[Ditiris]

I have a sensor that needs to wake up periodically and check in with a controller wirelessly. The final solution has many of these sensors, and there can be multiple controllers. In the simplest case, a laptop could be a controller. I would like for the wireless communication method to be well-supported and built into existing laptop-class hardware. The wireless data required for the exchange will be very small, basically enough to say hey I'm awake need me to do anything? If the controller tells the sensor to turn on, it will, and then a more powerful wireless module will take over.

Based on this article: https://pcbartists.com/design/embedded/stm32-wifi-options/, it looks like a low-power STM32 + some ESP32 variant would be a good solution.

I'm pretty comfortable with the STM32, it's well supported, and there are a million variants. Each sensor will have several sensors, some of which will need their own microcontrollers where low power is less important (their power will be shut down while we're asleep so who cares). Is the above a reasonable solution? Any gotchas? Should I consider something else?

Thanks!

[Ditiris]

Forgot, the other reason for STM32 is the built-in support for peripherals - I need SPI/I2C/CAN/ETH across the various sensors within the sensor. This would actually be nice for the part that wakes up and talks wirelessly but probably too much power - will just throw on a different STM32 with that stuff.

[woody]

Difficult to say anything sensible without knowing the specifics, but when I hear 'low data', 'many sensors', 'multiple controllers' I think 'Lora(Wan)'.

[fchk]

Look here:
https://www.analog.com/en/products/ltc2956.html

This is a power controller chip with timer functionality. The chip turns on the main system via EN pin of the main voltage regulator, then the system runs, and when it is done then it pulses the sleep pin so the power controller can turn off the main system, wait a predefined time (set by external resistors), and then the cycle starts again.  When pulling down the sleep pin the system goes into permanent shut down mode. When turned off the only thing consuming power is the power controller chip, and this is in the sub-uA range.

[Ditiris]

Difficult to say anything sensible without knowing the specifics

Fair enough - I kind of left it vague to cast a wide net, but maybe too vague. The battery is a standard 12V marine battery, but it needs to last years. It's going to be a tradeoff of waking up more frequently versus battery life lasting longer. Due to the use case, the timer functionality needs to be programmable. Please let me know what else you need to know.

I think 'Lora(Wan)'

I think I like this idea, especially as it's on STM32s.

Look here:
https://www.analog.com/en/products/ltc2956.html

Almost perfect, but needs to be programmable (I should have mentioned this). I couldn't find any 12V programmable versions - but a similar chip that is programmable operating off a few coin cells might work:
https://www.analog.com/en/products/max16163.html

Anything else I should look at?

[woody]

Funny; a while ago I created a solution to fix a personal irritation in a marine (yachting) environment, using LoraWan.

This device monitors the charge state of a couple of batteries in a boat as well as checks and controls some other stuff. It has its own small, 1000mAh LiIon cell, connected via an MP2667 that manages charging/discharging, to remain powered when not connected to shore power. The MCU in that design spends most of its time asleep and is woken up by an interrupt from either a power event (shore power down/up) a changed input status or from an Epson RX8111 RTC, the interval of which is programmable (i2c) from anything between one second and 32 years. Upon waking the device does some checks, sends / receives a LoraWan message, reprograms the RTC if necessary and then everything goes to sleep again.

Supplying anything for multiple years from a standard 12V marine battery (lead acid) might not be a good idea; these batteries self-discharge quite fast and fail when not regularly charged, especially when the temperature gets below freezing.

[nctnico]

I have a sensor that needs to wake up periodically and check in with a controller wirelessly. The final solution has many of these sensors, and there can be multiple controllers. In the simplest case, a laptop could be a controller. I would like for the wireless communication method to be well-supported and built into existing laptop-class hardware. The wireless data required for the exchange will be very small, basically enough to say hey I'm awake need me to do anything? If the controller tells the sensor to turn on, it will, and then a more powerful wireless module will take over.

Based on this article: https://pcbartists.com/design/embedded/stm32-wifi-options/, it looks like a low-power STM32 + some ESP32 variant would be a good solution.

If you have an ESP32 available, it makes no sense to add another microcontroller. Just use the ESP32 to do everything as these have oodles of processing power available. If the range doesn't need to be large then using BLE will do just fine. Either a laptop has support for Bluetooth or a simple USB Bluetooth dongle will do.

[Ditiris]

This device monitors the charge state of a couple of batteries in a boat as well as checks and controls some other stuff...

Thank you for your detailed answer - there's a lot of overlap between use cases here so very valuable for me.

What batteries were you monitoring? All the battery monitors I'm looking at seem to want to monitor single cells, not a full 12V battery.

Supplying anything for multiple years from a standard 12V marine battery (lead acid) might not be a good idea; these batteries self-discharge quite fast and fail when not regularly charged, especially when the temperature gets below freezing.

Ah, I hadn't thought about this. I don't know too much about batteries. Lead acid self-discharges faster as temperature rises but the charge available decreases as temperature falls, right? Li-Ion performs better and worse in some of these areas but is harder to charge - I think its main advantage would be you can discharge it more, right? Hmm, any recommendations here? I wonder if I could wake up the system periodically and run the engine to charge the lead acid battery...

[bookaboo]

I have a sensor that needs to wake up periodically and check in with a controller wirelessly. The final solution has many of these sensors, and there can be multiple controllers. In the simplest case, a laptop could be a controller. I would like for the wireless communication method to be well-supported and built into existing laptop-class hardware. The wireless data required for the exchange will be very small, basically enough to say hey I'm awake need me to do anything? If the controller tells the sensor to turn on, it will, and then a more powerful wireless module will take over.

Based on this article: https://pcbartists.com/design/embedded/stm32-wifi-options/, it looks like a low-power STM32 + some ESP32 variant would be a good solution.

If you have an ESP32 available, it makes no sense to add another microcontroller. Just use the ESP32 to do everything as these have oodles of processing power available. If the range doesn't need to be large then using BLE will do just fine. Either a laptop has support for Bluetooth or a simple USB Bluetooth dongle will do.

Agree with this.
One possibility is to have the ESP32 act as a beacon in advertising mode, the master controller (laptop) could connect if they wish.

Sleep currents of under 10uA possible with ESP32 variants, or for even lower power, Nordic have offerings that can do 2uA deep sleep.

[NorthGuy]

Forgot, the other reason for STM32 is the built-in support for peripherals - I need SPI/I2C/CAN/ETH ...

Do you believe that other MCUs don't have peripherals?

[SiliconWizard]

I have a sensor that needs to wake up periodically and check in with a controller wirelessly. The final solution has many of these sensors, and there can be multiple controllers. In the simplest case, a laptop could be a controller. I would like for the wireless communication method to be well-supported and built into existing laptop-class hardware. The wireless data required for the exchange will be very small, basically enough to say hey I'm awake need me to do anything? If the controller tells the sensor to turn on, it will, and then a more powerful wireless module will take over.

Based on this article: https://pcbartists.com/design/embedded/stm32-wifi-options/, it looks like a low-power STM32 + some ESP32 variant would be a good solution.

If you have an ESP32 available, it makes no sense to add another microcontroller. Just use the ESP32 to do everything as these have oodles of processing power available. If the range doesn't need to be large then using BLE will do just fine. Either a laptop has support for Bluetooth or a simple USB Bluetooth dongle will do.

Agree with this.
One possibility is to have the ESP32 act as a beacon in advertising mode, the master controller (laptop) could connect if they wish.

Sleep currents of under 10uA possible with ESP32 variants, or for even lower power,

Yes, around 5µA with ESP32-C3/C6, for instance. But keep in mind that ESP32's standby (lowest power mode) requires a full "boot" when waking up, taking up to a few hundreds of ms. That's usually fine for a typical "sensor node" which wakes up infrequently and for which wake-up latency doesn't matter, but certainly something to keep in mind when designing something "low-power" around an ESP32.

Other MCUs with "better-behaved" low-power modes can allow even lower currents while waking up in just a few or a few tens of µs (like the STM32 and many others).

Also, if you want to use WiFi, then ESP32 would definitely need to be considered, but if you're going for say, BLE, then there are better options out there. Unless cost is a major concern.

[nctnico]

Ah, I hadn't thought about this. I don't know too much about batteries. Lead acid self-discharges faster as temperature rises but the charge available decreases as temperature falls, right? Li-Ion performs better and worse in some of these areas but is harder to charge - I think its main advantage would be you can discharge it more, right? Hmm, any recommendations here? I wonder if I could wake up the system periodically and run the engine to charge the lead acid battery...

There are chips which can charge a small Li-ion battery (these are typically a linear regulator with an adjustable current limit). A simple solution to keep it charged is using a small solar panel as a power source. Starting an engine without being present sounds like a really bad idea to me.

[nctnico]

Forgot, the other reason for STM32 is the built-in support for peripherals - I need SPI/I2C/CAN/ETH across the various sensors within the sensor.

The ESP32 has all that (although ETH would require an external chip like Wiznet W5500 but you'll need an ethernet PHY anyway for an STM32) together with a software ecosystem which is easier to use compared to ST's HAL. The value for money an ESP32-S3 offers is mind boggling.

[woody]

Starting an engine without being present sounds like a really bad idea to me.

I could not agree more 

[hans]

Forgot, the other reason for STM32 is the built-in support for peripherals - I need SPI/I2C/CAN/ETH across the various sensors within the sensor.

The ESP32 has all that (although ETH would require an external chip like Wiznet W5500 but you'll need an ethernet PHY anyway for an STM32) together with a software ecosystem which is easier to use compared to ST's HAL. The value for money an ESP32-S3 offers is mind boggling.

The first ESP32 series had an ethernet MAC built in. Phy's are much more generic&cheaper to get than those Wiznet chips, although those have their advantages too (like for example, having to manage a TCP/IP stack in your own code).
Yes the value for money of ESP32 silicon is great, but my mental health cannot cope with ESP-IDF.

The ESP32 itself has some power saving features, but they are nothing in comparison to any STM32 (or actually any other MCU, even NXP's industrial parts do much better). In particular series like SiLabs chips, or STM32U or STM32L parts can be interesting, as they feature low power regulators and more internal oscillator modes that allows a balance between 'race to sleep' or more of an "autonomous" operation (some MSP430s also feature this).
I think most MCU's will resume code execution after a sleep instruction, while maintaining all of RAM state with just a few uA and much much shorter wakeup latencies than ESP32. For some reason the ESP32s always perform a soft reset, run through the bootloader (which can be painfully slow) and only keeps RTC SRAM state.

If OP is choosing an energy guzzling wireless standard such as WiFi, then trying to optimize sleep currents is penny pinching in comparison. For example, you can store the WiFI AP network channel to speed up the connection process (having it near <=300ms is great). However, if the AP (like most modern consumer ones by default) will periodically hop channels depending on environment conditions, then you'll need to have the sensor node perform a SSID list scan which often takes several (2-5) seconds to complete.

BLE is probably a much better option though if more frequent wake ups are needed. But personally I haven't used it much yet. I was planning to with some EFR32MG22 chips (of which there is also an Arduino variant with EFR32MG24 SoC), but that project is collecting dust for 2 years already.

Oh and regarding peripherals.. CAN and Ethernet are often not part of these ultra low power parts. The Phy's for those communication standards are energy guzzlers, so it doesn't make much sense to include them. Even for many sensor nodes, the radio is a major energy consumer which is highly complex subject as it can optimize various parameters for various scenarios (think latency vs throughput, but also more factors)

[woody]

I don't know how well BLE works when taking 'The final solution has many of these sensors, and there can be multiple controllers' of OP into account. And then there is the limited range.

For my own project I looked at Wifi but I didn't like the power requirements, the limited range and the fact that I had to somehow be able to enter network credentials in an otherwise headless device. LoraWan did not have these drawbacks. It had others, of course