Comms: Add BluetoothLE Link #13340

HTRamsey · 2025-08-27T08:08:55Z

Add Bluetooth Low Energy Comm Link.

Closes #12884

TODO: Add RSSI?

HTRamsey · 2025-08-27T10:53:54Z

@Davidsastresas Should there be a toggle between Bluetooth and BLE or just scan whatever is available?

Copilot

Pull Request Overview

This PR adds Bluetooth Low Energy (BLE) support to the existing Bluetooth communication link functionality. The changes extend the current classic Bluetooth implementation to support both classic Bluetooth and BLE modes through a unified interface.

Key changes:

Added BLE mode selection to BluetoothConfiguration with enum for ModeClassic and ModeLowEnergy
Implemented BLE controller and service management in BluetoothWorker alongside existing classic socket handling
Enhanced device discovery to filter devices based on selected mode (classic vs BLE)

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/UI/AppSettings/BluetoothSettings.qml	Minor QML formatting fixes and brace corrections
src/Comms/LinkConfiguration.h	Added logging category declaration for LinkConfiguration
src/Comms/LinkConfiguration.cc	Implemented logging category and updated debug statements
src/Comms/CMakeLists.txt	Added formatting whitespace after Bluetooth source files
src/Comms/BluetoothLink.h	Major refactor to support both classic and BLE modes with new properties and methods
src/Comms/BluetoothLink.cc	Complete implementation of BLE functionality alongside existing classic Bluetooth support

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

src/Comms/BluetoothLink.cc

Davidsastresas · 2025-08-27T11:53:49Z

Thanks! To be honest I have very little experience with these devices, so I don't know if I am the best to answer that.

HTRamsey · 2025-08-27T18:55:44Z

@DonLakeFlyer if I just get something usable down would you make any changes/fixes to the QML?

DonLakeFlyer · 2025-08-31T17:43:34Z

Sure, no problem

Copilot

Pull Request Overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

src/UI/AppSettings/BluetoothSettings.qml

src/Comms/BluetoothLink.cc

github-actions · 2026-01-31T01:58:07Z

Build Results

Platform Status

Platform	Status	Details
Linux	Passed	View
Windows	Passed	View
MacOS	Passed	View
Android	Passed	View

All builds passed.

Test Results

linux_gcc_64: 550 passed, 0 skipped

Total: 550 passed, 0 skipped

Code Coverage

Coverage: 100.0%

No baseline available for comparison

Artifact Sizes

Artifact	Size
QGroundControl-aarch64.AppImage	187.24 MB
QGroundControl-installer-AMD64-ARM64.exe	74.65 MB
QGroundControl-installer-AMD64.exe	162.54 MB
QGroundControl-installer-ARM64.exe	75.45 MB
QGroundControl-mac.apk	128.10 MB
QGroundControl-windows.apk	128.10 MB
QGroundControl-x86_64.AppImage	175.05 MB
QGroundControl.apk	285.16 MB
QGroundControl.dmg	311.87 MB

No baseline available for comparison

_{Updated: 2026-01-31 09:21:15 UTC • Triggered by: Android}

Copilot

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 14 comments.

Copilot · 2026-01-31T05:58:23Z

src/UI/AppSettings/BluetoothSettings.qml

+
+            QGCLabel {
+                // paired property in binding forces re-evaluation when pairing status changes
+                text:               (subEditConfig && paired !== undefined) ? subEditConfig.getPairingStatus(currentAddress) : ""


The text binding references the paired property to force re-evaluation, but it's checking paired !== undefined which is unnecessary. In JavaScript/QML, the property will always be defined (initialized to false on line 22). The check can be simplified to just check subEditConfig.

Suggested change

text: (subEditConfig && paired !== undefined) ? subEditConfig.getPairingStatus(currentAddress) : ""

text: (paired, subEditConfig ? subEditConfig.getPairingStatus(currentAddress) : "")

Copilot · 2026-01-31T05:58:24Z

src/UI/AppSettings/BluetoothSettings.qml

+                    readonly property bool   isPaired: subEditConfig && paired !== undefined &&
+                                                         isClassicMode &&
+                                                         deviceAddress !== "" &&
+                                                         subEditConfig.getPairingStatus(deviceAddress) !== qsTr("Unpaired")


Same unnecessary check for paired !== undefined here. The paired property is always defined (initialized to false on line 22).

Suggested change

readonly property bool isPaired: subEditConfig && paired !== undefined &&

isClassicMode &&

deviceAddress !== "" &&

subEditConfig.getPairingStatus(deviceAddress) !== qsTr("Unpaired")

readonly property bool isPaired: (paired,

subEditConfig &&

isClassicMode &&

deviceAddress !== "" &&

subEditConfig.getPairingStatus(deviceAddress) !== qsTr("Unpaired"))

Copilot · 2026-01-31T05:58:24Z

src/Comms/BluetoothLink.cc

+void BluetoothConfiguration::setReadUuid(const QString &uuid)
+{
+    const QBluetoothUuid newUuid(uuid);
+    if (!uuid.isEmpty() && newUuid.isNull()) {
+        emit errorOccurred(tr("Invalid read characteristic UUID format: %1").arg(uuid));
+        return;
+    }
+    if (_readCharacteristicUuid != newUuid) {
+        _readCharacteristicUuid = newUuid;
+        emit readUuidChanged();
+    }


Same issue with read UUID validation - empty strings should be allowed for auto-detect but the code will emit an error for empty input.

Copilot · 2026-01-31T05:58:24Z

src/Comms/BluetoothLink.cc

+void BluetoothConfiguration::setWriteUuid(const QString &uuid)
+{
+    const QBluetoothUuid newUuid(uuid);
+    if (!uuid.isEmpty() && newUuid.isNull()) {
+        emit errorOccurred(tr("Invalid write characteristic UUID format: %1").arg(uuid));
+        return;
+    }
+    if (_writeCharacteristicUuid != newUuid) {
+        _writeCharacteristicUuid = newUuid;
+        emit writeUuidChanged();
+    }


Same issue with write UUID validation - empty strings should be allowed for auto-detect but the code will emit an error for empty input.

Copilot · 2026-01-31T05:58:25Z

src/Comms/BluetoothLink.cc

+#include <QtCore/QVariantMap>

 QGC_LOGGING_CATEGORY(BluetoothLinkLog, "Comms.BluetoothLink")
+QGC_LOGGING_CATEGORY(BluetoothLinkVerboseLog, "Comms.BluetoothLink:verbose")


The logging category BluetoothLinkVerboseLog is defined and used in the .cc file but is not declared in the header file. This means it's not accessible from other translation units that might want to use it. Add Q_DECLARE_LOGGING_CATEGORY(BluetoothLinkVerboseLog) to the header file after the BluetoothLinkLog declaration.

Copilot · 2026-01-31T05:58:26Z

src/Comms/BluetoothLink.cc

+    // Filter out entries with unknown/invalid RSSI. These often come from cached results
+    // and cause turned-off devices to appear with no signal.
+    if (info.rssi() == 0) {
+        return;
+    }


When checking RSSI validity, the code filters out devices with rssi() == 0 (lines 156, 490, 522). However, a legitimate RSSI value of 0 dBm is theoretically possible (though rare in practice). The comment on line 488-489 mentions "unknown/invalid RSSI" but 0 dBm is a valid signal strength. Consider using a different sentinel value or checking info.rssi() == std::numeric_limits<qint16>::min() or similar to distinguish between "no RSSI data" and "RSSI is actually 0 dBm".

Copilot · 2026-01-31T05:58:26Z

src/Comms/BluetoothLink.cc

+void BluetoothConfiguration::setServiceUuid(const QString &uuid)
+{
+    const QBluetoothUuid newUuid(uuid);
+    if (!uuid.isEmpty() && newUuid.isNull()) {
+        emit errorOccurred(tr("Invalid service UUID format: %1").arg(uuid));
+        return;
+    }
+    if (_serviceUuid != newUuid) {
+        _serviceUuid = newUuid;
+        emit serviceUuidChanged();
+    }


The service UUID validation allows empty strings to indicate "auto-detect" (line 321), but the code on line 320 creates a QBluetoothUuid from the empty string which results in a null UUID. The subsequent check newUuid.isNull() on line 321 will be true for empty strings, causing an error to be emitted. This contradicts the intention stated in the comment on line 16 of BluetoothSettings.qml. The logic should be: if empty, accept it; if not empty and invalid, reject it.

Copilot · 2026-01-31T05:58:26Z

src/Comms/BluetoothLink.cc

+    const int nextInterval = qMin(RECONNECT_BASE_INTERVAL_MS * (1 << (_reconnectAttempts - 1)), MAX_RECONNECT_INTERVAL_MS);
+    if (_reconnectTimer) {
+        _reconnectTimer->setInterval(nextInterval);
+    }


This code attempts to reconnect with exponential backoff using bit shifting (line 1832), but there's a subtle bug. If _reconnectAttempts grows large enough, the shift (1 << (_reconnectAttempts - 1)) can overflow. With _reconnectAttempts = 10 (the max), this becomes 1 << 9 = 512, giving a 2560 second (42.7 minute) interval, which is then clamped to 60 seconds. However, if MAX_RECONNECT_ATTEMPTS were increased in the future, this could overflow an int. Consider using std::min with explicit calculations or safer exponential calculations.

Copilot · 2026-01-31T05:58:27Z

src/Comms/BluetoothLink.cc

+    if (_workerThread) {
+        if (isConnected()) {
+            (void) QMetaObject::invokeMethod(_worker, "disconnectLink", Qt::QueuedConnection);
+        }

-    _workerThread->quit();
-    if (!_workerThread->wait()) {
-        qCWarning(BluetoothLinkLog) << "Failed to wait for Bluetooth Thread to close";
+        _workerThread->quit();
+        if (!_workerThread->wait(5000)) {
+            qCWarning(BluetoothLinkLog) << "Failed to wait for Bluetooth Thread to close";
+            _workerThread->terminate();
+            if (!_workerThread->wait(1000)) {
+                qCCritical(BluetoothLinkLog) << "Failed to terminate Bluetooth Thread";
+            }
+        }
    }


In the destructor, after calling disconnectLink() with Qt::QueuedConnection (line 1929), the code immediately calls _workerThread->quit() (line 1932). Since the disconnect is queued, it may not execute before the thread quits, potentially leaving resources in an inconsistent state. Consider using Qt::BlockingQueuedConnection for the disconnectLink call in the destructor to ensure cleanup completes before thread termination.

Copilot · 2026-01-31T05:58:27Z

src/Comms/BluetoothLink.cc

+            }
+        }
    }



The auto-detection loop (lines 1649-1661) could select the same characteristic for both read and write if it has both Read/Notify and Write/WriteNoResponse properties. This might not be the intended behavior for bidirectional communication. After auto-detection, consider adding a check to warn or handle the case where both characteristics point to the same UUID.

Suggested change

// Warn if read and write ended up using the same characteristic UUID

if (_readCharacteristic.isValid() &&

_writeCharacteristic.isValid() &&

_readCharacteristic.uuid() == _writeCharacteristic.uuid()) {

qCWarning(BluetoothLinkLog) << "Read and write characteristics resolved to the same UUID:"

<< _readCharacteristic.uuid().toString()

<< "- bidirectional Bluetooth communication may not work as intended";

}

HTRamsey force-pushed the dev-comms-ble branch from 201d480 to 26b515b Compare August 27, 2025 10:52

HTRamsey requested a review from Copilot August 27, 2025 10:54

Copilot AI reviewed Aug 27, 2025

View reviewed changes

src/Comms/BluetoothLink.cc Outdated Show resolved Hide resolved

HTRamsey force-pushed the dev-comms-ble branch from 26b515b to 8378bb9 Compare August 27, 2025 18:55

HTRamsey force-pushed the dev-comms-ble branch from 8378bb9 to eb6baa8 Compare September 24, 2025 10:05

HTRamsey force-pushed the dev-comms-ble branch 3 times, most recently from d3aff7d to 808399d Compare October 10, 2025 10:00

HTRamsey marked this pull request as ready for review October 10, 2025 11:14

HTRamsey requested a review from Copilot October 10, 2025 11:15

Copilot AI reviewed Oct 10, 2025

View reviewed changes

src/UI/AppSettings/BluetoothSettings.qml Outdated Show resolved Hide resolved

src/UI/AppSettings/BluetoothSettings.qml Outdated Show resolved Hide resolved

src/Comms/BluetoothLink.cc Outdated Show resolved Hide resolved

HTRamsey added the RN: MINOR FEATURE label Oct 21, 2025

HTRamsey force-pushed the dev-comms-ble branch from 808399d to b43f873 Compare October 22, 2025 06:01

HTRamsey force-pushed the dev-comms-ble branch from b43f873 to 6c5d390 Compare January 1, 2026 10:26

github-actions bot added QML CMake size/XL labels Jan 1, 2026

HTRamsey force-pushed the dev-comms-ble branch from 6c5d390 to 997fab0 Compare January 1, 2026 10:38

HTRamsey force-pushed the dev-comms-ble branch from 997fab0 to 059df88 Compare January 31, 2026 01:21

HTRamsey force-pushed the dev-comms-ble branch from 059df88 to b4a7c8e Compare January 31, 2026 02:08

HTRamsey requested a review from Copilot January 31, 2026 05:52

Copilot started reviewing on behalf of HTRamsey January 31, 2026 05:53 View session

Copilot AI reviewed Jan 31, 2026

View reviewed changes

Comms: Add BluetoothLE Link

9ca4670

HTRamsey force-pushed the dev-comms-ble branch from b4a7c8e to 9ca4670 Compare January 31, 2026 08:26

HTRamsey merged commit 7c497e3 into mavlink:master Jan 31, 2026
17 checks passed

HTRamsey deleted the dev-comms-ble branch January 31, 2026 09:31

	text: (subEditConfig && paired !== undefined) ? subEditConfig.getPairingStatus(currentAddress) : ""
	text: (paired, subEditConfig ? subEditConfig.getPairingStatus(currentAddress) : "")

+    // Warn if read and write ended up using the same characteristic UUID
+    if (_readCharacteristic.isValid() &&
+        _writeCharacteristic.isValid() &&
+        _readCharacteristic.uuid() == _writeCharacteristic.uuid()) {
+        qCWarning(BluetoothLinkLog) << "Read and write characteristics resolved to the same UUID:"
+                                    << _readCharacteristic.uuid().toString()
+                                    << "- bidirectional Bluetooth communication may not work as intended";
+    }

Uh oh!

Comms: Add BluetoothLE Link #13340

Comms: Add BluetoothLE Link #13340

Uh oh!

Conversation

HTRamsey commented Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HTRamsey commented Aug 27, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Davidsastresas commented Aug 27, 2025

Uh oh!

HTRamsey commented Aug 27, 2025

Uh oh!

DonLakeFlyer commented Aug 31, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Build Results

Platform Status

Test Results

Code Coverage

Artifact Sizes

No baseline available for comparison

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

HTRamsey commented Aug 27, 2025 •

edited

Loading

github-actions bot commented Jan 31, 2026 •

edited

Loading