add FromRadioSync BLE characteristic#9675
add FromRadioSync BLE characteristic#9675jamesarich wants to merge 5 commits intomeshtastic:developfrom
Conversation
@jamesarich, Welcome to Meshtastic!Thanks for opening your first pull request. We really appreciate it. We discuss work as a team in discord, please join us in the #firmware channel. Welcome to the team 😄 |
There was a problem hiding this comment.
Pull request overview
Adds a new BLE characteristic (FROMRADIOSYNC) intended to let clients receive FromRadio payloads via indications (instead of the legacy notification-driven “fromNum + read FromRadio” flow), with support in both NimBLE (ESP32) and Bluefruit (nRF52).
Changes:
- Introduces
FROMRADIOSYNCUUID definitions (string + nRF52 byte-array form). - Registers a new
FROMRADIOSYNCcharacteristic in NimBLE and nRF52 GATT services withINDICATE(+READ) properties. - Updates BLE send logic to prefer sending
FromRadiovia indications when the new characteristic is subscribed.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/platform/nrf52/NRF52Bluetooth.cpp |
Adds fromRadioSync characteristic and indication-based drain/send behavior; updates CCCD handling. |
src/nimble/NimbleBluetooth.cpp |
Adds fromRadioSyncCharacteristic, registers it in the GATT service, and adds indication-based send path. |
src/BluetoothCommon.h |
Adds FROMRADIOSYNC_UUID and declares FROMRADIOSYNC_UUID_16. |
src/BluetoothCommon.cpp |
Defines FROMRADIOSYNC_UUID_16 byte array for nRF52. |
Co-authored-by: Copilot <[email protected]>
src/nimble/NimbleBluetooth.cpp
Outdated
| // Check if FromRadioSync is subscribed (indications enabled) | ||
| // If so, we push the data directly via indication and consume it from the queue | ||
| if (fromRadioSyncCharacteristic->getSubscribedCount() > 0) { | ||
| uint8_t fromRadioBytes[meshtastic_FromRadio_size]; | ||
| // Loop until queue is empty or we fail to send | ||
| while (true) { | ||
| // Peek at the request to see if we have data, but we need to dequeue to send. | ||
| // getFromRadio dequeues. | ||
| size_t numBytes = getFromRadio(fromRadioBytes); |
There was a problem hiding this comment.
onNowHasData() now calls getFromRadio() to send indications. However PhoneAPI::getFromRadio() can synchronously invoke onNowHasData() during certain state transitions, which makes this re-entrant and can recursively call back into this method. That can cause deep recursion and unpredictable state progression. Consider moving indication sending out of onNowHasData() (e.g., queue work for the BLE thread/run loop) or add a reentrancy guard and only emit a single indication per trigger.
|
Overall this is working with the Android counterpart meshtastic/Meshtastic-Android#4584 Some things to note during testing:
|
This pull request introduces a new Bluetooth characteristic,
FROMRADIOSYNC, to enable data transfer via BLE indications. This provides an alternative to the existing notification-based mechanism, allowing clients to choose between notifications and indications for receiving data. The changes ensure that data is sent through the appropriate characteristic based on client subscriptions, and update both NimBLE and nRF52 Bluetooth implementations to support the new characteristic.Bluetooth Characteristic Additions and Updates:
FROMRADIOSYNC_UUIDdefinition and corresponding 16-byte array for use as a BLE characteristic UUID in both header and source files. [1] [2]fromRadioSyncCharacteristic(NimBLE) andfromRadioSync(nRF52) BLE characteristic objects in their respective codebases. [1] [2]BLE Service Setup and Permissions:
FROMRADIOSYNCcharacteristic withINDICATEandREADproperties in both NimBLE and nRF52 BLE service setup routines, including appropriate permissions and maximum length. [1] [2] [3]Data Sending Logic:
onNowHasDatamethod in both NimBLE and nRF52 implementations to prioritize sending data via theFROMRADIOSYNCcharacteristic if indications are enabled, draining the queue and avoiding duplicate sends to the legacy notification characteristic. [1] [2]CCCD (Client Characteristic Configuration Descriptor) Handling:
FROMRADIOSYNCcharacteristic, alongside existing characteristics.