Service discovery timed out using BLE on GNU/Linux

[mjstahlberg]

When the badge displays the bluetooth animation, I get the following error trying to configure it via BLE:

% badgemagic --transport ble smiley.toml
Error: bluetooth device connect

Caused by:
    Service discovery timed out

This is using e7989e7 from source (via cargo install --git https://github.com/fossasia/badgemagic-rs --features cli) on Arch. I confirmed that the device can be configured via BLE using the Android App.

[mgjm]

I've just added a new debug option --list-devices. Please update (run the cargo install command again) and try running the following command to list all BLE devices:

badgemagic --transport ble --list-devices

We filter by name (LSLED) and service (0000fee0-0000-1000-8000-00805f9b34fb). If your badge has other values it currently gets ignored. (You can omit other BLE devices if you post the output of the command)

[mjstahlberg]

Thanks for the quick update!

% badgemagic --transport ble --list-devices|grep LSLED
- […]: name=Some("LSLED") services=[0000fee0-0000-1000-8000-00805f9b34fb]

Note that when the badge is not in BLE download mode, I would get a different error message than reported (just Error: no device found). I can also update the badge using --transport usb. It still runs the OEM firmware. Board says B1144C_240525.

[hlxid]

I've tried reproducing this issue but sadly was unable to do so successfully.

The strange thing is that this error happens when connecting to the found device which includes scanning all available services. But we do that before that when scanning for devices which also includes service enumeration.
I'm unsure what could prevent service discovery from working in connect when it works in scan.

[mgjm]

I just realised that I didn't read the error properly. It is generated when we already found the device and try to connect to the peripheral: lines 155-158 in ble.rs.

Maybe we are already connected at this point (by calling properties or some other component on the system already established a connection). The examples in the btleplug crate wrap the connect call in an is_connected check (see lines 44-50). And the documentation of connect states: "Note that peripherals allow only one connection at a time."

However, I would expect a different error message in that case.

[mjstahlberg]

I've tried reproducing this issue but sadly was unable to do so successfully.

Have you tried with a more recent badge, labeled B1144C? Mine looks a bit different from the one shown here, in particular it has four reset contacts in addition to TCK/TIO/TX/RX. I also noticed that configuring 25% brightness via https://github.com/fossasia/led-name-badge-ls32 results in visual artifacts even though I can select all four brightness levels on the badge itself, so maybe there have been recent protocol changes.

[hlxid]

I don't own a B1144C badge, only a non C from 2024/01 with stock firmware. Are the ones sold at 38c3 B1144C?
Could be very likely that the issue is because of different badge revisions.

[mjstahlberg]

Are the ones sold at 38c3 B1144C?

Yes.

[weberval]

I experienced the same issues while I was at 39c3. It always occurred when I was in a very crowded environment.
Whenever I got out of the most crowded areas, everything worked as expected again.
I suspect the error to be related to a "full" radio band.

@mjstahlberg: How was your environment when the error occurred?