How to send different Bluetooth beacons every ms?

[dizcza]

(This forum hangs when I click the search field button. Therefore, I could not search if there are any posts related to my question.)

I'm trying to come up with a solution to send sensor beacons via Bluetooth each ms. Let's say, I'm sending iBeacons with the UUID payload represented as sensor data, although any other beacon type is OK.

• Is it physically possible? What's the minimum rate I can send Bluetooth beacons in ESP32?
• If yes, which ESP-IDF function should I use to send one beacon at a time?

I know there are several GAP functions in ESP-IDF that advertise beacons.

Code: Select all

esp_err_t esp_ble_gap_config_adv_data_raw(uint8_t *raw_data, uint32_t raw_data_len);
esp_err_t esp_ble_gap_start_advertising(esp_ble_adv_params_t *adv_params);

But how to send a new beacon every ms? I haven't found the API to change the raw data an ESP32 board is advertising. Calling these functions one after the other in a loop, as shown below, takes ~16ms, which is too long for my scenario.

Code: Select all

static esp_ble_ibeacon_t ibeacon_adv_data;

// register the callback with esp_ble_gap_register_callback(esp_gap_callback));
static void esp_gap_callback(esp_gap_ble_cb_event_t event, esp_ble_gap_cb_param_t *param)
{
    esp_err_t err;
    switch (event) {
    case ESP_GAP_BLE_ADV_DATA_RAW_SET_COMPLETE_EVT:
        esp_ble_gap_start_advertising(&ble_adv_params);
        break;
    case ESP_GAP_BLE_ADV_START_COMPLETE_EVT:
        if ((err = param->adv_start_cmpl.status) == ESP_BT_STATUS_SUCCESS) {
                // modify the beacon data here
        	ibeacon_adv_data.ibeacon_vendor.proximity_uuid[0]++;
        	esp_ble_gap_config_adv_data_raw((uint8_t*)&ibeacon_adv_data, sizeof(ibeacon_adv_data));
        }
        break;
    }
}

If you know a dedicated API for sending one-time sensor beacons from an ESP32, please let me know.

Thank you.

[chegewara]

There is no point (and no option) to change advertised data every 1ms. Why:
- usually applications that scan/search for beacons do it with rate 100ms+, why? thats the whole point of BLE, to not drain battery with scan and/or advertising,
- i dont remember now from top of my head, but minimum scan/advertising rate as about 7.5ms (bluetooth specs).

[dizcza]

There is no point (and no option) to change advertised data every 1ms. Why:
- usually applications that scan/search for beacons do it with rate 100ms+, why? thats the whole point of BLE, to not drain battery with scan and/or advertising,

Draining the battery is not a problem for me.
There are several advantages of sending the data as Bluetooth beacons compared to requiring the clients to connect to the device:

• The number of subscribers is unlimited. Everyone can listen.
• Each new subscriber does not drain ESP32 CPU and RAM resources.
• Most important: no need to re-establish the Bluetooth connection with the ESP32 each time the client leaves the ranging area as well as in case of other Bluetooth errors. Imagine the case where your ESP32 board is lying in a field in the middle of nowhere, and occasionally you come to check if the board is functioning and see some sensor data plots on your phone. But you cannot come too close, and therefore the connection is unstable. It's OK if some packets get lost but the user experience is unaffected because we are not forcing the user to connect to the device each time the error occurs neither set up an automatic connection, which the user might not want to have.
• No need to lose the ongoing Bluetooth connection with another device. Listen to your favourite music via Bluetooth headset and pick beacons meanwhile... although I've not tried this and don't know if it's possible. It is possible. I've checked it.

- i dont remember now from top of my head, but minimum scan/advertising rate as about 7.5ms (bluetooth specs).

I didn't know that. Indeed, that would be the limit.

[chegewara]

Draining the battery is not a problem for me.

Maybe not for you, but for mobile devices that will do the scan. Like i said, the whole point of BLE vs classic BT is to not drain battery, thus the name (LE stands for low energy).

Imagine the case where your ESP32 board is lying in a field in the middle of nowhere, and occasionally you come to check if the board is functioning and see some sensor data plots on your phone. But you cannot come too close, and therefore the connection is unstable. It's OK if some packets get lost but the user experience is unaffected because we are not forcing the user to connect to the device each time the error occurs neither set up an automatic connection, which the user might not want to have.

Try to read about BLE 5. It is better version with long range functionality. For example this is something hard to imagine, but may be true:
viewtopic.php?f=19&t=21011#p77404


BTW, min scan duration is 10ms
viewtopic.php?t=2291