Periodic Advertising Sync Transfer (PAST) Peripheral issue

[CHATAR]

Hi, 

My configuration is as follow : 

NCS : 2.2.0

DK : nrf52833DK (pca10100)

Dev environnement :Ubuntu 20.04

IDE : visual studio code with NCS plugin

I'm trying to develop some behaviors based on PAST (Periodic Advertising Sync Transfer) procedure and to start I used peripheral_past example in zephyr samples.

But when I tried to compile it, there was this undefended reference error to 'bt_le_per_adv_sync_transfer_subscribe' as shown below.

I didn't change anything in the example !

Do you have any idea for this issue ?

Thank you.

[Vidar Berg]

Hi,

NCS v2.2.0 did not include BT_CTLR_SYNC_TRANSFER_RECEIVER_SUPPORT in the Bluetooth controller (Zephyr or Softdevice). This is why the sample will only builds for simulation targets. I recommend you upgrade to v2.3.0 for now until v2.4.0 gets released. 

Softdevice controller features supported in NCS 2.3.0 - https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrfxlib/softdevice_controller/README.html 

Best regards,

Vidar

[CHATAR]

Hi Vidar Berg 

Thank you for your reply.

Indeed with NCS 2.3.0, the example compiles, it works well but I have some remarks/questions :

1- In the central PAST example, it at first connect to the peripheral and then sync to periodic_adv then transfer the periodic sync info to peripheral PAST, but when I try to sync with periodic_adv first then connect to peripheral PAST and transfer the sync info, it gives me error -5

a) Central -> connect peripheral_past ->sync to periodic adv (synced) -> central transfer sync info to periphral -> works well

b) Central -> sync to periodic adv (synced) -->  connect peripheral_past -> central transfer sync info to periphral -> error -5 

Why do I have an error in scenario b)  whereas I have a valid sync info ?

2- In the peripheral PAST side, when I retrieve the periodic sync from the central, I send disconnect command and I try to restart LE advertising with bt_le_adv_start in disconnect event, I have no error (err_code = 0) but the advertising doesn't restart (I don't see any advertising with Android nRF Connect) !

If i do not retrieve the periodic sync and i send disconnect then restart LE advertising in disconnect event, in this case it works !

Do you have an explanation to these behaviors ? 

Thank you for your replies

[Vidar Berg]

Hi,

nRF Connect SDK v.2.4.0 is released now, and it includes several bug fixes related to PAST: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/nrfxlib/softdevice_controller/CHANGELOG.html#nrf-connect-sdk-v2-4-0. Can you please give the new version a try and see if it works better?

Thanks,

Vidar 

[CHATAR]

Hi Vidar Berg ,

Indeed the new version of NCS 2.4.0 fixes a lot of stuff for periodic advertising Sync Transfer including my issue (2) of my previous message. But the issue (1) with the scenario (1-b) isn't fixed yet, I got the error -5 with opcode : 0x205a (HCI_LE_Periodic_- Advertising_Sync_Transfer) and status :0x1A (<wrn> bt_hci_core: opcode 0x205a status 0x1a)

The status 0x1a (UNSUPPORTED REMOTE FEATURE) indicates that remote doesn't support the PAST feature which is  very surprising because int the (scenario 1-a) it works well, it seems that the order of operations (connection and periodic sync) is very important. I checked in the core specification 5.4 about the order of connection and periodic sync and it is not mentionned, it just said that a valid connection should be in progress when transfering the periodic advertising !

The scenario 1-b is very important in our case, do you have any idea why it doesn't work in scenario 1-b ?

Thank you

[Vidar Berg]

Hi,

I checked with our Bluetooth controller team, and they said the HCI UNSUPPORTED REMOTE FEATURE error is raised if you try to send a PAST from the connected callback before the feature exchange has been completed. So, the solution should be to wait for the feature exchange to be completed. You can register the remote_info_available callback to get notified of this.

[CHATAR]

Hi Vidar Berg ,

Right, when I add  remote_info_available callback and wait for the feature exchage, the PAST works well with scenario 1-b, that  is a good news.

I have one last question,  can the central PAST receive callback when using bt_le_per_adv_sync_transfer() method to indicate that the peripheral PAST has synced with the periodic adv ? I want to transfer more than one periodic adv, and I need to know when the peripheral synced with the first before transferring the second one.

Thank you

[Vidar Berg]

Hi,

Unfortunately, the PAST procedure doesn't provide any feedback to the sender about a sync being successful. A workaround could be waiting for more than 6 PA intervals on the sender to be sure the receiver has synced (or timed out trying).

Best regards,

Vidar