Well.. why is he using the ESP32? That thing is everything but not a low power microcontroller. The use of BLE/Wifi increases the power consumption like crazy.
I've build a solar station with an ESP32 using LoRa module. Even that wasn't much fun as I was forced to keep in light or even deep sleep as often as possible.
An option would be to use a Nordic NRF or STM32WB and use the BLE long range mode.
Because the two guys involved in this are "social media" expert and a "self improvement coach." Did you read the post? It says things like "you can use UDP but you'll have to adjust your server to use UDP."
This submission was a blatant attempt to boost his blog and in turn his product's website; the whole thing looks to me like a scam.
The other guy has a lot of "look at my expensive stuff" and "the secret to success!" videos (and some videos about using AI to make videos...)
The company's website is a joke. Hilariously bad attempts at SEO in the title, the ad copy is littered with grammar mistakes, and so on. "Best canadian dog tracker"...what?
I'm somewhat skeptical about your conclusion that the TCP handshake and other possible overheads are the problem.
1) In the worst case you're transmitting one packet for each connection, this requires you to send two handshake packets. The TX time alone cannot be more than a few milliseconds per packet. Once every 5-15 minutes is negligible
2) MQTT uses TCP by default, unless you use one of its variants
3) Leaving RX on is inevitable if you want real time connection, this is likely a far larger draw than the handshake
4) You could also configure the keep alive tcp connection value on the server and reuse the same connection
ESP32 is generally not a good choice for infrequently-charged battery powered devices IMO, unless they have massive batteries. Power consumption always goes up with the sophistication of the communication stack, both hardware and software, and the ESP is toward the upper end of that spectrum (unlike, say, something based on 802.15.4).
That said, were you using TLS? I'd be curious to know how that impacts power consumption during HTTP calls.
This reads as if you did multiple API calls per "ping", and opened a new http connection for each API call?
Did you try reusing the http connection (one per ping)? How about putting all data in a single API call and let the server handle that?
Did you try compression?
Not sure if compression makes sense, but a simple+fast compression like gzip could also be worth a try to reduce the actual bytes to put on the air; especially if your data is very verbose or repetitive. (Do that before connecting to wifi, even if that means not using http's compression).
I suppose you're talking http, not https. The latter will of course use much more energy.
Using UDP and the ensuring TCP-like qualities seems like a last resort solution.
Sorry if I misread your article and the suggestion were tried or are not feasible for you.
I just made sewer temperature guard, which reports via Wifi when something undesirable happens. It lasts SIX MONTHS on AA-batteries. Attiny checks the temp every 10 minutes using micro amperes and only starts ESP-01 Wifi when needed.
Undesirable thing is that I have left faucet running and the sewer stays too hot/cold for half an hour.
I feel like this is a finding/experience worth sharing. We ran into battery problem when developing our MVP using esp32 c3 MCU. ESP32 have high current consumption during network calls and we resolved this problem by avoiding TCP protocol in our network calls (Moving away from REST API calls).For Details, I am linking full article here:
https://khalsalabs.com/iot-101-minimizing-esp32-wifi-battery...
I’m guessing professional EEs have better tools but in my hobbyist experience the power profiling kit II works well for analyzing low power (0-5v) circuits.
The software tool provided by Nordic is fairly capable and easy to use. At $89 from DigiKey it’s sort of a no brainer to pick one up to play with.
I doubt, it's likely some inherent issue with their setup. E.g they use http on top of the TCP, at that point I'd stop and discard the rest of the article.
OTOH, UDP is totally fine depending on what you are doing, it's a very simple (NON-stream) protocol to boot.
Thank you for the article, very interesting. In my low power project I also switched away from my usually preferred esp32 in favor of a more battery efficient MCU. I also am not using wifi nor ble but lora instead.
Not OP, but Atmel AVR or TI's MSP430 are good choices if you need low power. The nRF24L01+ from Nordic Semiconductor is a good RF alternative for low power and long distance.
This is blatant blogspam to promote a product from a company that seems to be a self-declared social media expert and a wannabe life coach whose youtube video content includes 'how to make money using AI to produce videos.' The social media guy appears to be using ChatGPT to spam links to his blog about dogs.
Well.. why is he using the ESP32? That thing is everything but not a low power microcontroller. The use of BLE/Wifi increases the power consumption like crazy.
I've build a solar station with an ESP32 using LoRa module. Even that wasn't much fun as I was forced to keep in light or even deep sleep as often as possible.
An option would be to use a Nordic NRF or STM32WB and use the BLE long range mode.
Because the two guys involved in this are "social media" expert and a "self improvement coach." Did you read the post? It says things like "you can use UDP but you'll have to adjust your server to use UDP."
This submission was a blatant attempt to boost his blog and in turn his product's website; the whole thing looks to me like a scam.
The other items on the blog are clear keyword-of-the-day click-chasing and this is obviously ChatGPT output: https://khalsalabs.com/the-essence-of-paul-graham-essay-on-h...
One of the authors seems to enjoy using ChatGPT to respond to questions on Quora to spam links to his shitty blog site about dogs. Or this:
https://www.quora.com/What-is-the-difference-between-learnin...
The other guy has a lot of "look at my expensive stuff" and "the secret to success!" videos (and some videos about using AI to make videos...)
The company's website is a joke. Hilariously bad attempts at SEO in the title, the ad copy is littered with grammar mistakes, and so on. "Best canadian dog tracker"...what?
Yeah, the depth of this post is (first time making a hardware product) not (experienced insider sharing domain knowledge).
I'm somewhat skeptical about your conclusion that the TCP handshake and other possible overheads are the problem.
1) In the worst case you're transmitting one packet for each connection, this requires you to send two handshake packets. The TX time alone cannot be more than a few milliseconds per packet. Once every 5-15 minutes is negligible
2) MQTT uses TCP by default, unless you use one of its variants
3) Leaving RX on is inevitable if you want real time connection, this is likely a far larger draw than the handshake
4) You could also configure the keep alive tcp connection value on the server and reuse the same connection
ESP32 is generally not a good choice for infrequently-charged battery powered devices IMO, unless they have massive batteries. Power consumption always goes up with the sophistication of the communication stack, both hardware and software, and the ESP is toward the upper end of that spectrum (unlike, say, something based on 802.15.4).
That said, were you using TLS? I'd be curious to know how that impacts power consumption during HTTP calls.
It takes notional 3 seconds to boot and get an IP address alone.
If you use ESP-NOW then you can wake up send msg and sleep again in 35ms.
It's a layer 2 protocol.
Second that, espnow + broadcast mesh is the way to go
This reads as if you did multiple API calls per "ping", and opened a new http connection for each API call?
Did you try reusing the http connection (one per ping)? How about putting all data in a single API call and let the server handle that?
Did you try compression? Not sure if compression makes sense, but a simple+fast compression like gzip could also be worth a try to reduce the actual bytes to put on the air; especially if your data is very verbose or repetitive. (Do that before connecting to wifi, even if that means not using http's compression).
I suppose you're talking http, not https. The latter will of course use much more energy.
Using UDP and the ensuring TCP-like qualities seems like a last resort solution.
Sorry if I misread your article and the suggestion were tried or are not feasible for you.
I just made sewer temperature guard, which reports via Wifi when something undesirable happens. It lasts SIX MONTHS on AA-batteries. Attiny checks the temp every 10 minutes using micro amperes and only starts ESP-01 Wifi when needed.
Undesirable thing is that I have left faucet running and the sewer stays too hot/cold for half an hour.
I feel like this is a finding/experience worth sharing. We ran into battery problem when developing our MVP using esp32 c3 MCU. ESP32 have high current consumption during network calls and we resolved this problem by avoiding TCP protocol in our network calls (Moving away from REST API calls).For Details, I am linking full article here: https://khalsalabs.com/iot-101-minimizing-esp32-wifi-battery...
Hope you all enjoy!
Has anyone used the Nordic power kit? Or any other recommendations for measuring power consumption?
I would recommend the UM34C USB tester, cheap, good, has BLE connectivity and a 3rd party open-source python app[1] to log and monitor the data.
[1] https://github.com/kolinger/rd-usb
I’m guessing professional EEs have better tools but in my hobbyist experience the power profiling kit II works well for analyzing low power (0-5v) circuits. The software tool provided by Nordic is fairly capable and easy to use. At $89 from DigiKey it’s sort of a no brainer to pick one up to play with.
Sounds like TCP is in dire need of an upgrade that makes the protocol more power-friendly.
Everybody implementing their own protocol over UDP seems highly undesirable.
I doubt, it's likely some inherent issue with their setup. E.g they use http on top of the TCP, at that point I'd stop and discard the rest of the article.
OTOH, UDP is totally fine depending on what you are doing, it's a very simple (NON-stream) protocol to boot.
Thank you for the article, very interesting. In my low power project I also switched away from my usually preferred esp32 in favor of a more battery efficient MCU. I also am not using wifi nor ble but lora instead.
What did you use? I'm planning a lora project too.
Not OP, but Atmel AVR or TI's MSP430 are good choices if you need low power. The nRF24L01+ from Nordic Semiconductor is a good RF alternative for low power and long distance.
MSP430 are pretty much legacy (exception: the MSP430FR has its niche) since ST released the STM32U0.
AVRs can be serious power hogs, though. Not all have the Power Reduction Register.
This is blatant blogspam to promote a product from a company that seems to be a self-declared social media expert and a wannabe life coach whose youtube video content includes 'how to make money using AI to produce videos.' The social media guy appears to be using ChatGPT to spam links to his blog about dogs.
The whole thing smells like a scam.