4

We are developing a device which communicates with our iOS/watchOS apps via Bluetooth LE and has to stream a lot of sensor data for an extended time period (hours). Everything works fine under iOS 15.x, but we've found out that iOS 16 betas (and the RC) changed something in the negotiation process: previously we've used 15 ms Connection Interval, but iOS 16 (and watchOS 8) most of the time negotiates 24 ms, which is too wide for our bandwidth. The long connection interval causes packet loss (9-33%), and after 3 failed retries (3x30 sec) our hardware drops the connection.

I've checked all forums and documentation available but didn't found any indication that something changed. Is there any new parameters we can look into to fix this issue?

EDIT: Changed 30 ms to 24

gklka
  • 2,459
  • 1
  • 26
  • 53
  • What is the role of the iOS device, Central or Peripheral? The 30 ms connection interval looks short enough, iOS system shares the BT module across all apps and services, so it might be event longer. – onegray Sep 09 '22 at 13:21
  • The phone act as Central. – gklka Sep 10 '22 at 10:28

2 Answers2

5

You've probably set both Interval Min and Interval Max at 15ms. Apple explicitly says that this may caused devices to negotiate to 30ms (see section 41.6 Connection Parameters):

If an accessory requests both an Interval Min and Interval Max of 15 ms, some devices will scale the interval to 30 ms to balance power and performance constraints.

Basically, asking for "as fast as possible, no margin" translates into "yeah, everyone asks for that, how about moderately fast?"

However, you may ask for a faster CI if you include HID:

If Bluetooth Low Energy HID is one of the connected services of an accessory, a connection interval down to 11.25 ms may be accepted by the device.

Though I believe what iOS 16 is doing exactly matches Apple's spec (they always said that 15ms could be negotiated to 30ms), you should still open a Feedback+DTS to discuss the impact on your product and use case. Sometimes these things are by accident, and sometimes they're experiments that get rolled back.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Rob, I found the note in section 41.6 that mentions "scaling to 30ms". Are you certain this was always in the spec? I probably read this section a half dozen times but I just don't remember this part. But even if it was in the spec I never saw this behavior during countless hours of testing until iOS 16 and now multiple customers are reporting. I believe they changed something but did not mention it in the iOS 16 release notes. – ehmjaysee Sep 16 '22 at 03:32
2

We had the same issue with our product. We used a 7.5-15ms interval that was accepted by iOS15 & below, though it didn't meet the Apple Design Parameters (we thought we could get away with it since it was working). We had to change it to 15-30ms for the issue to be resolved, though now the amount of time it takes to transfer data for Androids has doubled.

As Rob mentions in this thread, it seems that for iOS16.0, Apple decided to strictly follow their guidelines and not allow anything outside those "set" requirements, even though they allowed it in the past. However, it seems that Apple has reverted back to how iOS15 was operating with iOS16.1. (There is no documentation that says this though - just know through testing)

If you need a quick fix right now, if you have users, have them update to iOS16.1. Your device should operate as it should when it used to run on iOS15. For a long term solution, I would follow Rob's suggestion.

Marie Millan
  • 31
  • 3