PAwR samples not working on NCS 2.7.0

My setup includes 2 nRF52840 DKs, one flashed with periodic_adv_rsp and the other with periodic_sync_rsp. I copied the samples and auto-generated a build configuration for each for an nRF52840 DK target but the outcome was very similar to a previous ticket a user posted here. After testing with 2.7.0, I flashed the samples on 2.7.99cs-2 and got the same outputs, seen below:

periodic_sync_rsp node

00> *** Booting nRF Connect SDK v2.7.99-cs2-d73b286ff6d9 ***
00> *** Using Zephyr OS v3.6.99-3d01dcc251bf ***
00> Starting Periodic Advertising with Responses Synchronization Demo
00> [00:00:00.000,701] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
00>                                             c3 da 9a 7f e9 e1 d3 21  cd 3f be 9a 94 f1 c9 d3 |.......! .?......
00>                                             10 dd fb fe                                      |....             
00> [00:00:00.003,448] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
00> [00:00:00.003,479] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
00> [00:00:00.003,509] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 195.39642 Build 3554797951
00> [00:00:00.004,425] <inf> bt_hci_core: Identity: F9:F7:79:E4:D5:E3 (random)
00> [00:00:00.004,455] <inf> bt_hci_core: HCI: version unknown (0x0e) revision 0x101c, manufacturer 0x0059
00> [00:00:00.004,486] <inf> bt_hci_core: LMP: version unknown (0x0e) subver 0x101c
00> Waiting for periodic sync...
00> Timed out while synchronizing
00> Waiting for periodic sync...
00> Timed out while synchronizing
00> [00:00:20.006,286] <wrn> bt_hci_core: opcode 0x2036 status 0x0c
00> Advertising failed to start (err -13)

periodic_adv_rsp

00> *** Booting nRF Connect SDK v2.7.99-cs2-d73b286ff6d9 ***
00> *** Using Zephyr OS v3.6.99-3d01dcc251bf ***
00> Starting Periodic Advertising Demo
00> [00:00:00.000,671] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
00>                                             c3 da 9a 7f e9 e1 d3 21  cd 3f be 9a 94 f1 c9 d3 |.......! .?......
00>                                             10 dd fb fe                                      |....             
00> [00:00:00.003,326] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
00> [00:00:00.003,356] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
00> [00:00:00.003,387] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 195.39642 Build 3554797951
00> [00:00:00.004,272] <inf> bt_hci_core: Identity: FE:79:2D:47:EC:F2 (random)
00> [00:00:00.004,302] <inf> bt_hci_core: HCI: version unknown (0x0e) revision 0x101c, manufacturer 0x0059
00> [00:00:00.004,333] <inf> bt_hci_core: LMP: version unknown (0x0e) subver 0x101c
00> Start Periodic Advertising
00> Scanning successfully started
00> Subevent data set 3
00> Subevent data set 5
00> Subevent data set 8
00> Subevent data set 10
00> Subevent data set 13
00> Subevent data set 15

I am able to see the PAwR sync sample on nRF Connect Mobile and I can connect to and disconnect from it:

Do these samples work as-is for anyone else or is there a configuration I need to update (or bug in 2.7.x) to get the devices synced properly?

Parents
  • Update: when I roll back to NCS 2.6.2 the program works and the HCI error on the advertiser/central is resolved by updating the min/max periodic advertising intervals to 0x50 * NUM_SUBEVENTS. This seems to be a new issue introduced in 2.7.0 and specifically affects the periodic_sync_rsp functionality. This commit from the main Zephyr repo introduces the bug, and this commit solves it. My guess is putting the name in the scan response data rather than the advertisement data prevents the central/advertiser from successfully identifying and connecting to the node. The issue is still present in 2.7.99-cs2.

Reply
  • Update: when I roll back to NCS 2.6.2 the program works and the HCI error on the advertiser/central is resolved by updating the min/max periodic advertising intervals to 0x50 * NUM_SUBEVENTS. This seems to be a new issue introduced in 2.7.0 and specifically affects the periodic_sync_rsp functionality. This commit from the main Zephyr repo introduces the bug, and this commit solves it. My guess is putting the name in the scan response data rather than the advertisement data prevents the central/advertiser from successfully identifying and connecting to the node. The issue is still present in 2.7.99-cs2.

Children
No Data
Related