PAwR response delayed by one periodic interval

RE: PAwR response delayed by one periodic interval

droid — Tue, 06 Jan 2026 21:14:41 GMT

Hello,

Together with a timer (to handle the case of no response_cb in periodic_adv_rsp sample), this works well.

Thank you for the recommendation.

Carl

RE: PAwR response delayed by one periodic interval

Kenneth — Tue, 06 Jan 2026 10:45:35 GMT

Hi Carl,

The nordic sniffer does not support PAwR so you will have to use something more powerful like an Ellisys or Frontline sniffer.

The application does not have to respond directly in the callback from the host (request_cb in the sample). You can call bt_le_per_adv_set_subevent_data later after receiving the response from the sync. If you are too late the controller will respond with an error code (0x46 TOO_LATE).

Kenneth

RE: PAwR response delayed by one periodic interval

droid — Sat, 03 Jan 2026 00:09:02 GMT

Hello,

Thank you for the information (and Happy New Year!).

We were not able to capture any LE Periodic Advertising packets for some reason (Windows 11, Wireshark 4.6.2, nRF52840 Dongle with sniffer_nrf52dongle_nrf52840_4.1.1.zip) so could not verify the sniffer trace above, but have extended the slot_delay (up to 200ms in another application) which should be sufficient to set a subevent response in the LE Periodic Sync (with subevents) device in the same LE Periodic Advertising interval as the subevent request.

We greatly appreciate the Nordic developer reproducing our results. And, the following would then explain the results:

The controller raises the data request event right after sending the AUX_SYNC_SUBEVENT_IND, before any responses have been received. So the timeline is:

Controller sends AUX_SYNC_SUBEVENT_IND with counter=N, requests data for next subevent

App responds to data request, sets data with counter=N+1

Sync responds with counter=N

App receives the response with counter=N

This means the LE Periodic Advertising (with subevents) device will not be able to send a request based on the previous subevent response from the LE Periodic Sync (with subevents) device in the next LE Periodic Advertising interval after the subevent response is received, but rather must wait for the following LE Periodic Advertising interval to do so.

Of course this guarantees sufficient time for SD scheduling the next LE Periodic Advertising interval transmission, but reduces the rate of such 'ping pong' transactions by 50%.

In the LE Periodic Advertising (with subevents) device, would it be at all possible to defer the request for data by the SD controller until after slot_delay time has passed? For sufficiently long LE Periodic Advertising intervals, that should supply sufficient time to process a request.

Thank you,

Carl

RE: PAwR response delayed by one periodic interval

Vidar Berg — Fri, 02 Jan 2026 13:25:02 GMT

Hello,

I have limited experience with PAwR so I forwarded this to our developers. Here is the response I got:

The sync is allowed to respond up to one periodic interval later. Which periodic interval it will respond in depends on the timing of the "LE Set Periodic Advertising Response Data" HCI command. If there is time to respond in the current subevent SDC will do that, if not the response will be one periodic interval delayed. In addition, SDC will enqueue the "LE Periodic Advertising Subevent Data Request" event when the AUX_SYNC_SUBEVENT_IND has been sent so it will be fetched by the host before the response events.
The way to make sure the sync can respond in the same subevent is to increase the response slot delay, like the customer tried. I dont know what values they tried. The data has to go through the zephyr host and HCI so there will be some delays here. They are using 53 so there are additional delays in IPC between app and net cores as well.

Best regards,

Vidar

Update: developer also tested the sample himself:

Ran the samples on 54L with modifications mentioned in the devzone post. With a sniffer I see the sync consistently responding in the same subevent (response slot delay is 10 ms in the sample, periodic interval is 318.75 ms):

However, I see the same logs as the customer on the advertiser side:

So ideally they would use a sniffer to see if the sync is responding in the same periodic interval or not

I think there are two things confusing here:

The controller raises the data request event right after sending the AUX_SYNC_SUBEVENT_IND, before any responses have been received. So the timeline is:
- Controller sends AUX_SYNC_SUBEVENT_IND with counter=N, requests data for next subevent
- App responds to data request, sets data with counter=N+1
- Sync responds with counter=N
- App receives the response with counter=N
The sample prints "Subevent data set N" after it set data with counter=N-1. It is the "request: counter N-1" print that tells which counter value was set.