nRF52810 S112 background reconnect issue

[dr9]

Hi,

I'm working through a number of the PCA10040e examples (SDK16 | S112 | nRF52810 - mouse and keyboard to be specific) and have noticed some irregular behavior when waking the peripheral from sleep.  After bonding, if you put the peripheral to sleep, and let the central go to sleep as well (screen locked/off, no audio playing, etc.) and then wake the peripheral, the connection is not reestablished.  To restore the connection, you have to restart the peripheral with the central awake (i.e. being moved, screen on, audio playing, etc.)  However, if the central is "awake" when the peripheral is woken up, the connection is restored as expected.

I tried this with a nRF52832 (same examples in PCA10040 with S132) and the issue does not present itself.  The connection is able to be reestablished with the central sleeping.  Is this something to do with the Soft Device?  I plan on running a set of sniffer traces this afternoon and will post the results.

Thanks

p.s. central is an iOS device at this time.

[dr9]

Not sure if it helps, but I did find that if I make a call to advertising_start() sometime after the peripheral is running, with the central still sleeping, it does connect. 

[Kenneth]

You can find in chapter 35 in the Apple Bluetooth guidelines some recommendations to parameters that should be used: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

For instance I believe the advertising_start() may start by doing directed advertisement, this is not recommended by apple, see chapter 35.3. So you may need to init advertisement module without directed advertisement enabled.

Apple also have some suggestions for advertisement intervals.

[Kenneth]

The way I see this is that the phone in this case have a bug of some sort (could be an internal race condition of some sort). It may be triggered by the content of the LL_FEATURE_RSP, since that is slightly different between S112 and S132.

It can also be that the actual issue is triggered from the very first time the two devices bonded (e.g. some data not stored as it should be), so doing a full clear cache on the phone side (e.g. remove device from the BT listing and turn off/on BT) and re-bond could be worth a try. Just make sure that re-bonding is done without the pm_handler_secure_on_connection()/pm_handler_on_pm_evt() on the peripheral device. 

Let me know if you have any new findings (e.g. if other phones also show the same, or if it affect normal usage when phone is not in sleep).

[dr9]

Kenneth said:

so doing a full clear cache on the phone side

Unfortunately this made no difference.

I'm looking for a newer iPhone to see if the behavior is any different there.  If its not, I may be stuck going to a nRF52832 chip or completely rebuilding my application in SDK14.2.

Kenneth said:

or if it affect normal usage when phone is not in sleep

If the phone is not asleep, there is no issue at all.

[dr9]

Is there any chance that I can use SDK16 and S132 and the nRF52810?

[Kenneth]

Yes, you may find these two links useful:
https://infocenter.nordicsemi.com/topic/struct_nrf52/struct/nrf52810_dev_kit.html
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52810/COMP/nrf52810/nrf52810_ble_qdid_qual_matrix.html 

[dr9]

HI Kenneth,

Kenneth said:

(e.g. if other phones also show the same, or if it affect normal usage when phone is not in sleep).

Tested with an iPhone 11 - same result.  Will have results on a couple of androids over the weekend. 

I also began to rebuild in SDK14.2 so that I could use S132, but due to memory size constraints, it looks like I'll be unable to achieve the desired outcome going that route.  I'm not expecting any real action from Apple.  Is there any way to detect the failed reconnect on the peripheral end and re-initiate?  If not, it looks like I'll be forced to step up to the nRF52832...

[Kenneth]

dr9 said:

Is there any way to detect the failed reconnect on the peripheral end and re-initiate?

Your latest screenshot show that the peripheral do establish connection, link is encrypted, and it looks like it also can send battery notifications.

Maybe you can check if the sd_ble_gatts_hvx() that is sent for button presses are successfully executed? E.g. no error code when calling sd_ble_gatts_hvx(), and that you experience BLE_GATTS_EVT_HVN_TX_COMPLETE?

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_t_t_s___h_v_n___m_s_c.html

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_t_t_s___f_u_n_c_t_i_o_n_s.html?cp=4_7_4_1_2_4_2_4#ga313fe43c2e93267da668572e885945db 

If you are not BLE_GATTS_EVT_HVN_TX_COMPLETE you could potentially use that as a indicator that the packet is not received, and thereby disconnect, start advertisement and re-connect.

Best regards,
Kenneth