6

I have a c++ application running on the Raspberry Pi that uses the bluez d-bus api. It supports multiple sensors from different vendors but for the most part adding new sensors has been fairly straight forward once I'd got the first one going. Once connected I'm not really using anything too exotic, just "StartNotify", "StopNotify", "ReadValue", and "WriteValue". Anyway, recently I've had problems adding a couple of new sensors. Both use larger packet sizes so using a packet sniffer I can see the sensors negotiating larger MTU. For whatever reason though after the negotiation I can read larger value characteristics but can't get notifications enabled (or received anyway). Trying different approaches with bluetoothctl I found that using "acquire-notify" seems to solve the problem. I also notice that the new "acquire" commands return the MTU so maybe that has something to do with it. Going back to the sensors I already support I've also found that replacing "StartNotify" with "AcquireNotify" seems to work with them as well. So my delimma is whether to use "AcquireNotify" for all sensors (keeping my code a lot cleaner) or just the new ones that give me an issue.

I haven't really found any in-depth documentation on the new "acquire" interfaces unfortunately. To someone without a lot of bluez history it's not at all clear what the ramifications of using them vs the original interfaces are. So my questions are twofold -

  1. Is there any reason not to use "AcquireNotify"/"ReleaseNotify" for all sensors (even older ones that use old/lower MTU)?
  2. When using "AcquireNotify" does it matter if you use "ReadValue"/"WriteValue" on other characteristics, or should I be using "AcquireRead"/"AcquireWrite"?

Any info greatly appreciated, Thanks!

Chrisby
  • 81
  • 1
  • 1
  • 7

2 Answers2

4

AcquireNotify returns a file descriptor that you can poll and read and notifications don't go through d-bus. with StartNotify you read the notification value from d-bus. you'll be able to achieve better performance with file descriptors (and without d-bus) if you're sending a lot of data in GATT notifications.

AcquireNotify/AcquireWrite are relatively new APIs and they have some stability issues (bluetoothd can terminate because of SIGPIPE). there are some patches to bluez 5.50 in their repositories that improve it.

Gal Ben-Haim
  • 17,433
  • 22
  • 78
  • 131
1

Figured I'd follow up for anyone else seeing similar behavior. Oddly, after trying all kinds of permutations sending commands using bluetoothctl I found a way to get it working without using the notify-acquire api's. Randomly I found that if I enabled notifications via "notify on", then did the sensor vendor's recommended write command sequence to get the sensor to start sending data nothing happened. But if I did all that and then simply used "select characteristic" to go back to the notify characteristic I'd enabled it would start sending data. Not sure why. At any rate once I'd fully integrated the sensors into my application they actually worked without requiring anything extra. Not sure why exactly since my code is based directly on the bluetoothctl source but regardless it seems to work (so far anyway)...

Chrisby
  • 81
  • 1
  • 1
  • 7
  • 1
    Very interesting scenario. If you don't mind could you share what you figured out during all BlueZ experiments regarding MTU? I have a similar requirement that I need to set the MTU before the notifications start to work. I just can't figure out how this can be done. – kaptan Mar 21 '20 at 01:36
  • I am also interested in how you solved this. Are you able to share some code? I am also attempting to subscribe to notifications from a ble device with either fd or through dbus – bem22 Feb 13 '21 at 01:52