3

I'm currently developing a react native app in combination with a device. The device and the app communicate via BLE. So far everything works as expected but I'm having issues with the connection stability of the iOS app and the device. What would happen is that the device would connect and I can update some characteristics but it would regularly either disconnect with a CBErrorDomain 7 or the response for a write would timeout. The implementation on the app or device side does not seem to be the problem as Android works stable and the device also disconnects when connecting with the LightBlue app.

I've already updated the BLE connection parameters as suggested here: https://developer.apple.com/library/archive/qa/qa1931/_index.html. This has increased the stability but did not resolve the problems completely. I've tried playing around with the values but so far no luck.

The current set of parameters we are using are:

conn_min_interval: 15
conn_max_interval: 15
conn_latency: 0
supervision_timeout: 2000
adv_min_interval: 1285
adv_max_interval: 1285

My question now would be if somebody has an idea what other things I could check or which parameter to tune?

Bruno
  • 894
  • 11
  • 32
  • On the remote device, what reason code do you see in the disconnect event? – Emil Dec 08 '22 at 14:50
  • So my python implementation does not realize that the disconnect happens and I'm unsure where to find the correct bluetooth driver logs that would indicate this? – Bruno Dec 08 '22 at 14:57
  • What platform do you run on? Python is just a language. – Emil Dec 08 '22 at 15:30
  • It's a version of Ubuntu 20.04 – Bruno Dec 08 '22 at 15:40
  • One thing I noticed (but not yet confirmed) is that the disconnect becomes more likely the more data I exchange between app and device. Not sure if there are some cache related problems or something with sending too much in a small time frame – Bruno Dec 08 '22 at 15:42
  • You can run "sudo btmon" in a terminal to see all packets from the controller, including Disconnect Complete event, which includes the reason code. – Emil Dec 09 '22 at 00:46
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/250283/discussion-between-bruno-and-emil). – Bruno Dec 09 '22 at 10:38
  • What version of iOS are you using? There is a bug in 16.0 and 16.0.2 which caused the device to continuously disconnect after the first GATT write. Have a look at this: https://stackoverflow.com/questions/73960000/core-bluetooth-reduced-ble-mtu-size-when-upgrading-from-ios-15-to-ios-16 – Youssif Saeed Dec 22 '22 at 07:17
  • Unfortunately, this didn't solve it. Tried it with 16.1 and 16.2 – Bruno Dec 22 '22 at 10:04

2 Answers2

0

Are you checking the maximumWriteValueLength and making sure your writes are smaller than this? A likely cause of your problems is overwhelming the device and it fails to keep up with sending ACKs. What version of Bluetooth does your device support, and does it implement DLE (Data Length Extension)?

Your conn_min_interval and conn_max_interval are suspicious. Asking for 15ms with no leeway is likely to negotiate to 30ms instead. (See 41.6 Connection Parameters) Is your device comfortable with being re-negotiated to something other than 15ms? Can your device actually keep up with 15ms and no connection latency if it does get that? I'm betting it can't. Try setting your connection interval to 30ms (or even a bit slower), and you might even try setting your connection latency to 1 to make the connection a bit more forgiving (though I'd focus more on slowing the CI than increasing latency; increasing latency would be more of a hack in this case).

All my suspicions are around your peripheral not keeping up with its side of the connection. If you have any synchronous activities in response to the data, you need to make sure that it's not blocking your BLE stack from sending the required responses.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • The board is a Khadas VIM 3 Pro with a AP6398S chip (https://www.texim-europe.com/product/AP6398S) that supports BT 5.0. From my understanding and research of DLE it should support it or? The phone is an iPhone 10 Pro Max which also supports BT 5.0. I will check if the maximumWriteValueLength though. I will also try the other parameters. Regarding your last point. I'm not entirely sure what you mean by that. Shouldn't the write just be acknowledged by BLE by default? – Bruno Dec 20 '22 at 19:58
  • I generally think you are right as it mostly fails if I write to a lot of characteristics at the same time. I'm just unsure what to change and check. – Bruno Dec 20 '22 at 20:01
  • Whether it's acknowledged by BLE "by default" depends on your stack. You suggested you're writing this in Python, though I don't know which library you're using. In many libraries, you will be called when there's a write, and you need to do something (perhaps just `return True`) to let the framework know it was successful. If you take longer than a CI to do that, you could stall the system and it'll timeout and disconnect. – Rob Napier Dec 20 '22 at 20:34
  • Thanks Rob. Makes total sense. I will check that as well. – Bruno Dec 21 '22 at 06:22
  • My question would be why it works so stable on Android though if the implementation acknowledges to slowly. I will still check though – Bruno Dec 21 '22 at 06:29
  • It depends on the Android device. For example, if it's not one that supports BLE 5, then it may be communicating much more slowly. Also, iOS tends to be more strict about the specs than Android. So I'm not overly surprised you'd see differences. – Rob Napier Dec 21 '22 at 13:56
  • So far I've tested bigger values for the conn_min and conn_max interval and it seems that bigger values lead to an actual worse connection. Any idea why? – Bruno Dec 21 '22 at 17:34
  • What bigger values did you use? – Rob Napier Dec 21 '22 at 18:12
  • 30, 60, 120 but they are either equally stable or worse – Bruno Dec 21 '22 at 18:24
0

Finally, I've found the answer to my problem. The problem was that the pairing procedure of the BLE server was faulty and thus iOS was unable to have a stable connection. Now that this is fixed the connection is very stable.

I'm still unsure why iOS was able to have any communication at all without the pairing but I hope that this helps some people in the future.

Bruno
  • 894
  • 11
  • 32