Disconnected peripheral reconnects direct in iOS.

[Martin]

Hi, Got stuck on an issue that has come and gone and then working fine, and are now back again.

I use a nrf51 module with the led-button-service example (sdk 5.2). It's not using bondmgr, just scan for known or recently connected peripherals. I modified the example to have 4 characteristics and to wakeup each 60 seconds to sample ADC values. In the timer event I call start advertise, which is set to 6 seconds. After update-notify two of the characteristics value I disconnect from iOS (stop notifyValue on chars and cancel connection). I am using the iOS connect functions to restore state and connectPeripheral so it get started even i background mode.

Is there anything obvious I am missing?, I can see that the peripheral reconnects direct after I cancelConnection in iOS, and the only clue I got is that it does that for the same amount of time I have set the Advertising inteval to, in this case 6s.

Does the softdevice still advertise for connection attempt after it has passed the connected state? I have tried to stop advertise sd_ble_gap_stop(), but then it will not connect next time.

Thanks in advance!

[Hung Bui]

@Martin:

I'm not sure I understand the issue you are having now. If your device starts advertising after it gets disconnected, and if you try to reconnect in the app (as you mentioned run in background) then it will be connected again after you start advertising.

I suggest you try to record a sniffer trace to see what happens over the air. (Wireshark version 1.10 is recommended)

[Martin]

Maybee iOS issue, cause the peripheral is still around for ca 6sec in my case (adv timout not affecting this 6s). Turned of notifying to just read, same prob. The cancelPeripheralConnection is non blocking, followed by issuing connectPeripheral on the current peripheral object, to the App, the connection is gone, but to iOS it could be active for other App etc. A workaround could be to wait and disconnect, but the background execution time windows might be gone for proper reconnect block call. I also tried to write to a characteristic to disconnect from the peripheral side, WithResponse that caused the valid parameters for on_write, but had weird connection and value update issues if disconnect in TX_READY event etc. I guess the best way would be to find some event when stack is ready to be closed. Tested some other posted solutions, but not quite got it working smothly. Any suggestions?

[Martin]

Just a follow up, Thinik it's odd, but resonable that iOS does what it does, not sure if disconnect and connect in a quick manner is possible only from cancelPeripheral. Reconnect to same peripheral object might just work properly when lost (peripheral disconn) connection since then iOS then is "aware" before fire didDisconnect, CoreBluetooth guide state that you should disconnect as soon as all advertise is disabled and connection not needed etc.

Anyway I found a some minor bugs and learn some, now using a writeWithResonse where I set a single-shot timer and there do the exit after 200mS, seems to work fine for now, not using notify, only read characteristics direct after connecting.

Run the sniffer, but that is really a detailed analysis tool, thanks to Nordic devkit usbdongle, thought I never gona use that..

[Hung Bui]

@Martin: What you described is correct, iOS won't terminate the connection immediatelly when requested by app on the phone because it will wait and check if other app is using the same connection. I'm not sure what was the issue when you try to disconnect from the peripheral side ? It should be the proper way to terminate the connection without the delay on iOS.