0x08 disconnection occurs when the ios mobile phone is connected to the device

[zero]

Based on sdk12.3, use 51-dk (51822) to run the ble_app_hrs routine.
Use ios mobile phone to connect the device, it will automatically disconnect after 30 minutes, the disconnection reason is 13 (0x80).
How can this be solved?

[Stian Røed Hafskjold]

If it times out after 30 second there is probably a LL procedure timeout. For instance that the nRF51 is not answering a DLE request, or a connection update request. If you are able to post the BLE sniffer log, we can identify the response timeout and figure out what needs to be implemented on the nRF51 side.

[zero]

Attached the BLE sniffer log, the timeout disconnection is at line 55797, please help analyze, thank you.51822_ios_Disconnected_reason_8.pcapng

51822 log output:

[Stian Røed Hafskjold]

Sorry, I miss read your post. I see now that you wrote 30 minutes not seconds.

Is it always 30 minutes, or does it vary?

Looking through the log it seems like the master (ios) is starting to miss the slave packets (nrf51), because of retransmissions. Then the slave stops responding to the master. It could be because the slave is missing the packets from the master.

Can you try with another phone? Just to rule out that there is something wrong with the phone

I'm thinking that there could be some issues with the clock synchronization. Are you using the LFRC or LFXO on the nrf51? And which clock configuration are you using, PPM, clock calibration interval, etc.

[zero]

Not every time is 30 minutes; it will be disconnected within 10-30 minutes.
This phenomenon occurs when the distance between the mobile phone and the device is greater than 3 meters, and the disconnection problem will not occur within 3 meters.

I have also tested Android phones. No matter what distance it is, it will not disconnect within the signal range.

LFRC is used, and the configuration is as follows:

And the internal clock calibration is added at the beginning of the program, this problem still occurs.

[Stian Røed Hafskjold]

The clock is automatically calibrated by the softdevice. Are you calling that function in intervals, or is it just at the beginning of main? In any case, it is not really necessary. Anyways, if it always works fine within 3 meters I think we can rule out any clock drifting problems.You can of course try to set the clock accuracy to 500ppm and see if the problem improves.

Since it is working on the Android phones I think we can maybe rule out that the problem lies with the nRF51. So it sounds to me like there are some issues with the receiver on the iPhone. Can you please let me know the model number of the iPhone you are testing with, and I can check if we have experienced similar issues before.

[zero]

Phone model: iPhone 5s
ios version: 10.2

[zero]

Changing to 500ppm still has this problem.