BLE + Deep Sleep?

[weberc2]

Hey folks, I’ve never touched ESP32 nor BLE before, but it seems like a good fit for a soil moisture monitoring application. The plan is to have soil moisture sensors connected to an ESP32 (battery powered) that remotely send data to a server on some interval (probably exceeding 1 hour). To maximize battery life, I’m was planning on putting the ESP into its deep sleep mode and then waking up to take a reading and send data to the server before disconnecting and sleeping. In this architecture, I figured it would be easier and less power-intensive for the ESP to be the BLE client; however, from what I’ve read it seems like most people have the sensor serve as a BLE server that is polled—I’m wondering if my proposed architecture is overlooking something or if it makes sense for my use case? Does anyone see any problems that I will run into / should be aware of up front? Thanks in advance for the help!

[ESP_Sprite]

Why specifically use BLE? If you're only gonna wake up once an hour, it may be more viable to simply use WiFi.

[weberc2]

My assumption was that BLE would be lower power.

[ESP_Sprite]

It depends, I think Tx and Rx power is similar. The thing that will mostly define the power usage is the amount of time the ESP32 spends out of deep sleep, communicating. That is somewhat implementation dependent, though.

[MicroController]

The idea to have the sensor act as the BLE client seems reasonable. I'm not sure if it would actually save power though; it boils down to whether scanning+connecting (client) uses less energy than advertising+accepting (server).

However, for small one-shot data transfers, the process of establishing a connection (whether via BLE or joining a WiFi) will take more time and consume more energy than the actual transfer.
As an alternative, you can look into having the sensor (as a master/server) include the payload data directly into its BLE advertisement. Advertisements are not acknowledged though, so this may not be reliable enough.

If you have ESPs at both ends, ESP-NOW may be a good option as it is connection-less and acknowledged. The sensor would turn on its WiFi RF, send only one ESP-NOW packet, receive the acknowledgement and go back to sleep.

[bidrohini]

Using the ESP32 as a BLE client means it will need to actively scan for and connect to a nearby BLE server (the sensor). This scanning process consumes some additional power compared to the server mode, where the ESP32 would remain in a more passive role.

[OutOfLine]

ESP-NOW may be a good option as it is connection-less and acknowledged.

Yes, it may be a good option, but no, it is not acknowledged.
It is not difficult to program an acknowledgement if you want to have that.

[MicroController]

ESP-NOW may be a good option as it is connection-less and acknowledged.

Yes, it may be a good option, but no, it is not acknowledged.

That is incorrect.
See e.g. https://www.instructables.com/ESPNow-a- ... -ACKs-Ret/
Unfortunately, the documentation is not explicit about it, but if you squint you can read into it that the send callback will get an "ESP_NOW_SEND_FAIL" if "the destination device doesn’t exist; the channels of the devices are not the same; the action frame is lost when transmitting on the air, etc", all of which wouldn't be possible for the sender to detect without an acknowledgement mechanism.

[OutOfLine]

Thank you for the interesting link.

Now I would like to know what exactly happens regarding retransmissions and akknowledge when sending to all know peers, like

Code: Select all

esp_now_send(NULL, data, len);   /* send to all known peers */

Will there be retransmissions?
In what sequence (when multiple peers are not reached)?