Feature Request: BLE Support

[Witty-Wizard]

I am using DroneBridge for connection with betaflight and it works great but recently they shifted to PWA from native desktop application, that means that TCP does no longer work. So it would be great if DroneBridge supported BLE or maybe Websockets

[seeul8er]

I doubt it supports BLE. More like BL Classic. I recently took a look at it and they are completely different. There is no standard for BLE serial connections. BL Classic is only supported by the legacy ESP32 so not an option for this project.
I see no websocket option with the configurator.

[Witty-Wizard]

I doubt it supports BLE. More like BL Classic. I recently took a look at it and they are completely different. There is no standard for BLE serial connections. BL Classic is only supported by the legacy ESP32 so not an option for this project. I see no websocket option with the configurator.

You can check the BLE implementation in this file form the Betaflight Configurator:
https://github.com/betaflight/betaflight-configurator/blob/master/src/js/protocols/bluetooth.js

Regarding the Websocket, they recently switched to PWA from native, and now use Websockets instead of TCP
Reference: https://betaflight.com/docs/development/sitl#betaflight-web-app

Also mentioned in this Issue conversation: betaflight/betaflight-configurator#3432 (comment)

[Target0815]

BLE would be important to have GCS on iPhone / iPad, for example. SidePilot is a good GCS here.

An ESP32-C can Classic Bluetooth and also BLE.

Info:
Data sheet: https://www.espressif.com/sites/default/files/documentation/esp32-c3_datasheet_en.pdf
Programming: https://dronebotworkshop.com/esp32-bluetooth (you probably know Wolfgang ;))

A Radiomaster Nomad TX (ELRS and mLRS) has an ESP32-C3 installed as a backpack/bridge. Dronebrigde on it would be brilliant ... and would boost Dronebridge as well as ELRS and mLRS ;).

[Witty-Wizard]

I have tries this using the Arduino Framework, it works by advertising a GATT server. I am trying to get this to work with ESP-IDF.
ESP-IDF gives 2 Bluetooth Energy Libraries:

1. Bluedroid
2. nimBLE

nimBLE is not very well documented, or I am not able to find documentation for it, it also does not support Classic Bluetooth.
I am now going to try to use Bluedroid which is maintained by Espresiff.

[seeul8er]

As you said only the ESP32 classic supports Bluetooth Classic. All others only support BLE. I see no point in adding support for the ESP32 classic only, especially since all newer ESP32-based products feature the newer chips.

For BLE one would have to define a protocol standard that is valid at least for drone serial connections. This must then be implemented with all the GCS. I fear that at the end it will be the ELRS and mLRS PCB manufacturers who will profit most from that new feature without contributing anything. Just look at Speedybee. They have a BLE stack, but that one is closed source to promote their FCs and app. (Which is fine from a business point of view)

To solve @Witty-Wizard problem it would be far easier to bring back TCP/UDP support for the betaflight configurator. That really should be no big deal.

[Target0815]

I fear that at the end it will be the ELRS and mLRS PCB manufacturers who will profit most from that new feature without contributing anything.

You can see it that way, but users use such functionality. And if it weren't for the hardware manufacturers, at least ELRS would be dead ...

Instead of BLE, it would be easier not to activate an AP in the backpack (ELRS) or bridge (mLRS), but simply a wifi client. I have flashed Dronebridge to the bridge of mLRS as a test and set the pins accordingly. Unfortunately, mLRS resets the ESP32-C3 every few seconds because mLRS is probably trying to set something. To get further you would have to talk directly to OlliW, that would be easier.

Anyway, Dronebridge works great solo. It would just be nice if you could spread the word.

[Witty-Wizard]

drone

It is not possible to bring back TCP as web browsers don't support raw TCP for security reasons.
My Goal is to make a Speedybee like implementation.

The Betaflight Configurator uses GATT server to send over raw MSP bytes to the device, thats what Speedy bee receives.

I will push the changes soon to my fork, in any case.

[Witty-Wizard]

Update

While implementing BLE for this project I stumbled upon Serial Port Profile, explanation for which is given in this example code from Espresiff.

This is basically emulated Serial profile used to emulate Serial connection over Wireless Bluetooth Connection, @seeul8er.

[Witty-Wizard]

Update

I got BLE SPP to receive data from betaflight configurator, I need to integrate it with the DB control module then I can do some testing.

[Witty-Wizard]

Speculation

Putting this in for reference

In my code I have implemented SPP_DATA_RECEIVE and SPP_DATA_NOTIFY characteristics these are required to support betaflight, but does not support Speedybee for now. I have probed speedybee advertisement using nrfConnect app and it uses 2 additional characteristics, SPP_COMMAND_RECEIVE and SSP_COMMAND_NOTIFY, these are some how used to negotiate communication with the Speedybee app, this negotiation is not required as using only the SPP_DATA_RECEIVE and SPP_DATA_NOTIFY characteristics one can establish communication with Flight Controller, leading me to believe that this negotiation in required only for Speedybee app, so that no other device other than their own can connect to the mobile application.

/// SPP Service
static const uint16_t spp_service_uuid = 0xABF0;
/// Characteristic UUID
#define ESP_GATT_UUID_SPP_DATA_RECEIVE      0xABF1
#define ESP_GATT_UUID_SPP_DATA_NOTIFY       0xABF2
#define ESP_GATT_UUID_SPP_COMMAND_RECEIVE   0xABF3
#define ESP_GATT_UUID_SPP_COMMAND_NOTIFY    0xABF4

#ifdef SUPPORT_HEARTBEAT
#define ESP_GATT_UUID_SPP_HEARTBEAT         0xABF5
#endif

///SPP Service - data receive characteristic, read&write without response
static const uint16_t spp_data_receive_uuid = ESP_GATT_UUID_SPP_DATA_RECEIVE;
static const uint8_t  spp_data_receive_val[20] = {0x00};

///SPP Service - data notify characteristic, notify&read
static const uint16_t spp_data_notify_uuid = ESP_GATT_UUID_SPP_DATA_NOTIFY;
static const uint8_t  spp_data_notify_val[20] = {0x00};
static const uint8_t  spp_data_notify_ccc[2] = {0x00, 0x00};

///SPP Service - command characteristic, read&write without response
static const uint16_t spp_command_uuid = ESP_GATT_UUID_SPP_COMMAND_RECEIVE;
static const uint8_t  spp_command_val[10] = {0x00};

///SPP Service - status characteristic, notify&read
static const uint16_t spp_status_uuid = ESP_GATT_UUID_SPP_COMMAND_NOTIFY;
static const uint8_t  spp_status_val[10] = {0x00};
static const uint8_t  spp_status_ccc[2] = {0x00, 0x00};

#ifdef SUPPORT_HEARTBEAT
///SPP Server - Heart beat characteristic, notify&write&read
static const uint16_t spp_heart_beat_uuid = ESP_GATT_UUID_SPP_HEARTBEAT;
static const uint8_t  spp_heart_beat_val[2] = {0x00, 0x00};
static const uint8_t  spp_heart_beat_ccc[2] = {0x00, 0x00};
#endif