BlueR does not report RSSI correctly

[MaxG87]

For a little toy project I need to obtain the strength of a signal from a Bluetooth device. I do not think this is relevant, but for the record, the devices are

• Google Pixel 4a with latest Android
• ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth (as reported by lsusb)

I am running Kernel 5.9.11, self compiled. I am using BlueR 0.13.3, because Debian's Cargo only provides Rust 1.54.

I am able to get the information I want using hcitool rssi <addr>. It seems as if my phone needs to be connected via Bluetooth, but once it is I get reliable connection strengths.

When I try to run the example discover_devices.rs, the connection strength is always reported as None. If I try to run discover_devices with --changes, sometimes I get a change RSSI event, but only once in a while, while I would need it regularly.

I even tried to write my own loop, but to no avail.

use bluer::Address;
use std::{collections::HashSet, env};

#[tokio::main(flavor = "current_thread")]
async fn main() -> bluer::Result<()> {
    // let with_changes = env::args().any(|arg| arg == "--changes");
    let filter_addr: HashSet<_> = env::args()
        .filter_map(|arg| arg.parse::<Address>().ok())
        .collect();

    env_logger::init();
    let session = bluer::Session::new().await?;
    let adapter = session.default_adapter().await?;
    loop {
        for cur_addr in &filter_addr {
            let device = adapter.device(*cur_addr)?;
            let rssi = device.rssi().await?;
            println!("{cur_addr}: {rssi:?}");
        }
    }
}

Is there something I do miss? How would I get the RSSI of a connection reliably, without relying on ChangeEvents?

[MaxG87]

I need to correct myself. Running discover_devices --changes <addr> does not show any RSSI change for my phone. If I leave off <addr> it shows RSSI changes for other devices, though.

Using hcitool rssi the connection strength changed from 0 to -21 and took some values in between.

[surban]

Hi,

I cannot reproduce that issues. Testing on Kernel 5.19 with BlueZ 5.64 I can see the RSSI each time a device is discovered and lot's of RSSI change events:

Device changed: 03:3B:98:CA:B2:6D
    Rssi(-87)
Device changed: C0:48:E6:F2:08:BA
    Rssi(-67)
Device changed: BC:14:85:B9:34:6B
    Rssi(-86)
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-75)
Device changed: 9C:8C:6E:E7:30:33
    ManufacturerData({117: [66, 4, 1, 32, 126, 23, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 29: [0, 1, 76]})
Device changed: 0D:AC:27:8F:85:1D
    Rssi(-84)
Device changed: 03:3B:98:CA:B2:6D
    Rssi(-86)
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-71)
Device changed: C0:48:E6:F2:08:BA
    Rssi(-67)
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-74)
Device changed: 9C:8C:6E:E7:30:33
    ManufacturerData({29: [0, 1, 76], 117: [66, 4, 1, 1, 126, 156, 140, 110, 231, 48, 51, 158, 140, 110, 231, 48, 50, 1, 0, 0, 0, 0, 0, 0]})
Device changed: 63:3E:F0:7A:7A:D1
    Rssi(-60)
Device changed: FC:F1:36:2A:66:3F
    Rssi(-78)
Device changed: 06:B5:84:21:53:05
    Rssi(-90)
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-80)
Device changed: 64:6F:E1:D4:7C:A9
    Rssi(-81)
Device changed: FC:F1:36:2A:66:3F
    Rssi(-79)
Device changed: 9C:8C:6E:E7:30:33
    ManufacturerData({117: [66, 4, 1, 32, 126, 23, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 29: [0, 1, 76]})
Device changed: 0D:AC:27:8F:85:1D
    Rssi(-89)
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-75)
Device changed: C0:48:E6:F2:08:BA
    Rssi(-67)
Device changed: FC:F1:36:2A:66:3F
    Rssi(-82)
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-72)
Device changed: 9C:8C:6E:E7:30:33
    ManufacturerData({29: [0, 1, 76], 117: [66, 4, 1, 1, 126, 156, 140, 110, 231, 48, 51, 158, 140, 110, 231, 48, 50, 1, 0, 0, 0, 0, 0, 0]})
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-72)
Device changed: 64:6F:E1:D4:7C:A9
    Rssi(-81)
Device changed: 03:3B:98:CA:B2:6D
    Rssi(-72)
Device changed: 0D:AC:27:8F:85:1D
    Rssi(-89)
Device changed: 9C:8C:6E:E7:30:33
    ManufacturerData({117: [66, 4, 1, 32, 126, 23, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 29: [0, 1, 76]})
Device changed: 9C:8C:6E:E7:30:33
    Rssi(-74)
Device changed: BC:14:85:B9:34:6B
    Rssi(-76)

Maybe try another Bluetooth adapter?

Also, hcitool is accessing the Bluetooth adapter directly and bypassing bluetoothd. Could you check what bluetoothctl is reporting for the RSSI?

[MaxG87]

Thank you for your reply.

I tested the situation very thoroughly on my Thinkpad T470p:

• its Bluetooth adapter, as reported by lsusb, is Intel Corp. Bluetooth wireless interface
• I use Kernel 5.19 and BlueZ 5.65, both from Debian Testing's package repository
• I also directly used BlueR 0.15.0 (rev. c935112)

On this setup I can reproduce the issue. RSSI changes are not detected for my Pixel 4a by discover_devices. At the same time, hcitool rssi shows plausible fluctuations. I tried to dig deeper by connecting a Fairphone 3. For the Fairphone 3 discover_devices picks up some RSSI fluctuations, but not as many as hcitool rssi does.

As requested I ran bluetoothctl | grep -Fe $RSSI_PIXEL -e "$RSSI_FairPhone and then started discover_devices again. For the Fairphone, all RSSI changes were reported by both tools, but no RSSI changes were reported for the Pixel 4a by neither of the two commands.

If this boils down to that I do not properly use bluetoothctl or need to change some configuration, I would be very glad if you could provide me a pointer. I'd open a new issue / question on SO if desired.

Thank you very much for your help.

[surban]

Could you try adding rssi: Some(1) to the DiscoveryFilter at https://github.com/bluez/bluer/blob/master/bluer/src/adapter.rs#L205 and retry?

However, if BlueR and bluetoothctl show the same behavior, then your problem is caused by bluetoothd which is used by both BlueR and bluetoothctl. You could try adjusting the scan filter (menu scan) in bluetoothctl or ask in the BlueZ slack if somebody has an idea.

[MaxG87]

The line did not change anything. I will reach out to the BlueZ community then. Thank you for your help!