0

I have an iOS app that can connect pretty reliably to my BLE devices that advertise at 1.285 seconds, a frequency defined by Apple as one of the freqs that will help to optimize connectivity. I also have some BLE devices that advertise much slower (an advertisement every 4 seconds, for example), and these can be connected using the iOS app, but a little less reliably. To get these to connect the app has to wait longer for the connection to complete, after issuing the command to connect to the device, and sometimes the app must invoke a retry.

Running a Java app on Raspbian on a Raspberry Pi 3 Model B, I find that connection attempts to the BLE devices advertising at the 1.285 rate succeed pretty reliably, but connection attempts to the slower-advertising BLE devices always fail. I'm looking for ways to affect BlueZ, and thus D-Bus, to improve the connectability of these slower-advertising devices. I've looked through the BlueZ source code and so far have found no hints.

Does anyone have suggestions or insights?

dfclark
  • 49
  • 5

1 Answers1

0

The BlueZ D-Bus API is quite restrictive what you can do. I'd suggest you try some other solution that communicates over HCI to the bluetooth chip directly. Maybe https://github.com/sandeepmistry/bleno.

Emil
  • 16,784
  • 2
  • 41
  • 52