PAwR connexion and sync issues

[Yanis]

Hello,

I am testing the RF range of a BLE application based on PAwR (Periodic Advertsing with response) in coded PHY (S8) with SDK 2.9.0.

In order to test the robustness of the system and its ability to re-sync and reconnect in case of sync lost, the tests are performed in the link budget limit (RSSI of arround -80 or -90 dBm).

Fanstel chips are used based on nRF52840.

The code is based on the Nordic demo :

8562.PAwR_Demo.zip 

Periodic Advertising with Responses (PAwR): A practical guide - Software - nRF Connect SDK guides - Nordic DevZone

Many bugs are found during the tests and those bugs do not allow the scan to restart in the main while loop when the sync is lost : 

 1- the error "Connected (err 0x02)" in the connected_cb which stops scanning since the semaphore &sem_connected never releases, so I changed the call back connected_cb content in a way it always executes the semaphore even with err 0x02

2- HCI related errors as "<err> bt_hci_core: Invalid connection complete event"  and "bt_hci_core: Connection creation timeout triggered" when calling bt_conn_le_create() in device_found which seems to stop the connected and disconnected call backs, and so the scan too, it seems that this was addressed here but not so sure  (+) BT connection timeouts with PAWR enabled - Nordic Q&A - Nordic DevZone - Nordic DevZone

3- errors with bt_le_per_adv_set_info_transfer() as "failed to send past err = -5" and "bt_hci_core: opcode 0x205b status 0xla"

The errors shared here, do not occur systematicaly and not all together necessarly, but each time it makes the scan impossible to re-start, overall, it makes the PAwR not so robust in case of sync lost.

[Yanis]

Maybe the connection and the sync should be created only if the rssi is above a certain level, which means that a rssi condition should be added in the device found function to avoid random behavior trying to sync in case of low rssi. This might be a workaround but it will lower the sensitivity of the system and won't allow to fully exploit the range performance.

[tesc]

Hi,

I agree filtering on RSSI could improve the situation, although it will reduce the range.

It would also be good to fix or workaround the original issues, since they might still arise although not nearly as often.

 1- the error "Connected (err 0x02)" in the connected_cb which stops scanning since the semaphore &sem_connected never releases, so I changed the call back connected_cb content in a way it always executes the semaphore even with err 0x02

This is BT_HCI_ERR_UNKNOWN_CONN_ID, or "Unknown Connection Identifier". It can happen if the connection attempt times out, or if ble_conn_disconnect was called before the connection was established. In either case, it looks like the logic involving sem_connected and sem_disconnected might not take this outcome into account. Therefore, you should check for that return value, and give or take semaphores accordingly.

2- HCI related errors as "<err> bt_hci_core: Invalid connection complete event"  and "bt_hci_core: Connection creation timeout triggered" when calling bt_conn_le_create() in device_found which seems to stop the connected and disconnected call backs, and so the scan too, it seems that this was addressed here but not so sure

Yes, I agree that solution looks like a solution to the issue. At the very least it is confirmed to fix known issues, so it would be good to apply it until you get at an SDK version where it is applied.

3- errors with bt_le_per_adv_set_info_transfer() as "failed to send past err = -5"

From what I can tell, this may typically happen if the configuration is incorrect, on devices that use multiple cores. I have not been able to figure out why this error might appear on the nRF52840, but please check that you have enabled all of the relevant CONFIG_BT_PER_ADV_* kconfigs for the roles and protocols that you use. However I still fail to understand why this error should manifest only occasionally.

and "bt_hci_core: opcode 0x205b status 0xla"

This might be 0x1A Unsupported Remote Feature. Might make sense if previous errors leads to an execution path where procedures are started which are not available at the connected device.

Regards,
Terje