Linux bluetooth development
 help / color / mirror / Atom feed
* [RFC PATCH BlueZ 0/4] Bearer.LE1: Add ReadRSSI
@ 2026-11-12  3:22 Kevin Dewald
  2026-11-12  3:22 ` [RFC PATCH BlueZ 1/4] org.bluez.Bearer: Add ReadRSSI method Kevin Dewald
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Kevin Dewald @ 2026-11-12  3:22 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Luiz Augusto von Dentz, Kevin Dewald

Device1.RSSI only covers inquiry and advertising, so once a device is
connected and no longer advertising, there is no way to follow its
signal strength over D-Bus. Applications want it to warn about a link
that is getting weak before it drops. Android (readRemoteRssi) and iOS
and macOS (readRSSI) offer it, and the kernel has Get Connection
Information for it, which only btmgmt uses today.

This adds ReadRSSI to Bearer.LE1. It is a method rather than a property,
so bluetoothd does not poll: each call sends Get Connection Information,
which the kernel answers from the controller or with the value it read
in the last 1 to 3 seconds.

This was proposed in 2014 as ConnectionRSSI with Start and
StopConnectionMonitor on Device1 [1], and you found raw RSSI too low
level and suggested a normalized link quality instead. I went with the
raw value because it is what the other platforms expose, and what
applications compare with the advertising RSSI that Device1.RSSI already
gives in dBm. A normalized value depends on the controller and antenna,
and it can be derived from dBm but not the other way round. If you would
rather have a quality value, or the TX power from Get Connection
Information as well, I can rework it.

The kernel reports a connection as soon as it is established, but
refuses Get Connection Information until it has read the remote
features. A ReadRSSI made right after Connect returns therefore fails
with NotReady for a few tens of milliseconds. Letting get_conn_info()
accept BT_CONFIG would avoid that, and I can send that to the kernel
separately if you agree.

I tested it with the functional test in patch 4 on bluetooth-next
3f425f95ba39, and on real hardware: an RTL8761BU connected to an
nRF52840 with a random static address. ReadRSSI returned -50 to -52 dBm
while the advertising RSSI was -50 dBm, and the kernel sent HCI Read
RSSI about every 2 seconds however often ReadRSSI was called.

I left out a bluetoothctl command and can add one if you want it.

[1] https://lore.kernel.org/linux-bluetooth/1401177171-19994-2-git-send-email-andrzej.kaczmarek@tieto.com/

Kevin Dewald (4):
  org.bluez.Bearer: Add ReadRSSI method
  adapter: Add btd_adapter_get_conn_info
  bearer: Add ReadRSSI method
  test: functional: add bearer ReadRSSI test

 doc/org.bluez.Bearer.LE.rst    |  17 +++++
 src/adapter.c                  |  22 +++++++
 src/adapter.h                  |   7 +++
 src/bearer.c                   | 110 ++++++++++++++++++++++++++++++++-
 test/functional/test_bearer.py |  23 +++++++
 5 files changed, 177 insertions(+), 2 deletions(-)


base-commit: 9659adb6819d7e0284d0d2ba226a3894423d8db4
-- 
2.54.0 (Apple Git-157)


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-11-12  9:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-12  3:22 [RFC PATCH BlueZ 0/4] Bearer.LE1: Add ReadRSSI Kevin Dewald
2026-11-12  3:22 ` [RFC PATCH BlueZ 1/4] org.bluez.Bearer: Add ReadRSSI method Kevin Dewald
2026-11-12  9:03   ` Bearer.LE1: Add ReadRSSI bluez.test.bot
2026-11-12  3:22 ` [RFC PATCH BlueZ 2/4] adapter: Add btd_adapter_get_conn_info Kevin Dewald
2026-11-12  3:22 ` [RFC PATCH BlueZ 3/4] bearer: Add ReadRSSI method Kevin Dewald
2026-11-12  3:22 ` [RFC PATCH BlueZ 4/4] test: functional: add bearer ReadRSSI test Kevin Dewald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox