iOS 8 disconnect while service discovery

[henris42]

Hi,

I'm seeing a lot of this issue with iPad mini (1 gen), iOS 8.1.3.

Many times I start the bluetooth app, the connection just drops while doing service discovery, like:

2015-02-17 20:35:35.655 myApp[276:17102] Did discover peripheral myPeriph 2015-02-17 20:35:35.728 myApp[276:17102] Did connect peripheral myPeriph 2015-02-17 20:35:35.730 myApp[276:17102] Did start service discovery. 2015-02-17 20:35:36.095 myApp[276:17102] Did disconnect peripheral myPeriph

.. the app is loosely based on the nRF UART example. On the nrf51822 side there are no error messages whatsoever, the peripheral just happily keeps advertising and eventually timeouts. I'm using S110 v5.2.1 softdevice.

Only thing that helps is restart of the app - and sometimes I even have to reboot the iPad for getting any bluetooth connections at all..

Does anyone have any idea why this happens?

[Locky]

I'm not sure exactly what your issue is, but do double check to make sure your peripheral's desired connection parameters meet the Apple guidelines. I also find it best for stability on iOS to not update connection parameters until after Service Discovery is complete.

That said, there is a laundry list of bugs on iOS 8.1.3. Even as far as the OS causes some phones (iPhone 6 & 6+) to transmit connection events outside the scheduled window, causing connections to drop. People have logged many Bugs with Apple over the current state of Bluetooth. Hopefully they address these issues soon.

[henris42]

Thanks, I changed it to:

#define APP_ADV_INTERVAL                     32  
#define MIN_CONN_INTERVAL                    (uint16_t)(MSEC_TO_UNITS(20, UNIT_1_25_MS))         
#define MAX_CONN_INTERVAL                    (uint16_t)(MSEC_TO_UNITS(40, UNIT_1_25_MS))  
#define SLAVE_LATENCY                        0 
#define CONN_SUP_TIMEOUT                     MSEC_TO_UNITS(6000, UNIT_10_MS)         

My earlier APP_ADV_INTERVAL was 80, MAX_CONN_INTERVAL 38 ms, which was a little down side. Throughput is of key importance in my application, so I have to keep these figures optimized.. Seems better now, lets see how it goes for a few days..

We still have other strange iOS issues, like disconnect does not always go through correctly. Fooling with DFU seems to make it worse.. However strangely on OSX, everything works smooth as butter..

Thanks,

[Locky]

Keep us posted how this goes. I'd spoken to someone at Apple. Apparently there are a ton of implementations into iOS that are intended to save Battery Power (a big concern for smartphone users). Unfortunately for us Bluetooth designers, this seems to mean the iOS kills idle connections on a whim. All these implementations have also affected overall stability of the Apple Stack. It makes sense that OSX would be more stable as power consumption isn't as big a priority for the system.

Hopefully they fix these bugs soon. My ultimate fear is that they are left on purpose so that only Apple specific peripherals can have true connection stability.

[henris42]

Will do. One strange thing with this is that my friends with gen2 mini and retina ipads haven't had these issues at this level, only some minor inconveniences with transitioning to DFU and back. Also iphone platforms seem robust so far.

I'd also be interested to hear for any experiences on this front between S110 v5.2.1 vs v7 stuff, as we're in the process of upgrading the stack.. DFU change will obviously be quite significant.

[Hung Bui]

@henris: You mentioned that "On the nrf51822 side there are no error messages whatsoever, the peripheral just happily keeps advertising and eventually timeouts. " This sounds like the connect request from the phone is never recevied by the nRF51. So the connection wasn't established at all.

A sniffer trace would be quite useful to confirm this.

Do you have the same issue when you use our nRF UART app or nRFToolbox with our stock examples ?