PAwR interoperability issue: Nordic RX fails with opcode 0x2083 status 0x46 when syncing to third-party TX

[jjjjzh]

I am testing PAwR interoperability between:

• TX side: third-party chipset acting as PAwR Advertiser/Transmitter

• RX side: Nordic board running nRF Connect SDK (Zephyr) as PAwR Synchronizer/Receiver

The RX successfully discovers and syncs to the third-party TX periodic advertising. The log shows:

Found advertiser 14:EF:FB:0F:19:8C (public), SID 0x05, interval 0x0060 Creating Periodic Advertising Sync Synced to 14:EF:FB:0F:19:8C (public) with 1 subevents Periodic sync established.

However, when the RX tries to send PAwR responses, the HCI command fails:

<wrn> bt_hci_core: opcode 0x2083 status 0x46 Failed to send response (err -5)

This repeats for every response attempt.

---

What I already checked

• The third-party TX broadcasts PAwR Timing Info (AD Type 0x03) including:

  • Response AA

  • Number of SubEvents

  • SubEvent Interval

  • Response Slot Delay

  • Response Slot Spacing

• Sniffer capture confirms these fields are present. According to Core Spec 5.4, there is no explicit “num_response_slots” field in the timing info.

My understanding is:

• RX only knows interval/delay/spacing, but not the exact number of response slots.

• Nordic’s RX Controller seems to require valid slot information in the link context; otherwise it returns 0x46 Unsupported Feature when Host tries to send HCI_LE_Periodic_Adv_Subevent_Data_Response (0x2083).

---

My questions

1. Does Nordic’s RX implementation expect the Advertiser to explicitly include num_response_slots in ACAD (even though not defined in the spec)?

2. Is there any vendor-specific extension required in the Periodic Advertising Response Timing Info for RX to accept response data?

3. If the Advertiser only provides SubEvent Interval + Slot Delay + Slot Spacing (no slot count), should RX still allow Host to send responses (even if they may be dropped)?

4. Any advice on how to make Nordic RX accept responses from a non-Nordic PAwR TX implementation?

[Hung Bui]

Hi Junhao, 

Could you point me to where you find 0x46 is Unsupported Feature ? as far as I know it is: 

#define BT_HCI_ERR_TOO_LATE                     0x46

It seems that you get the same error I got here: RE: pawr_sync_conn doesn't work for nrf5340 audio dk 

Could you try to increase the response delay if possible ? 

Anything special on your application that can cause extra delay ? 

[jjjjzh]

Increasing the response delay to 11.25ms can solve the problem. But does this comply with the standards? The standard range starts at 1.25ms. The previous figure I provided was 2.5ms, which would cause problems. So, does the baseband fail to send packets because of this?

[Hung Bui]

Hi Junhao, 

If you are spending too much time in the application and didn't response to the BLE stack then it would be too late to send. See here: 

The error code happens for example if the HCI commands comes after the time where AUX_SYNC_SUBEVENT_RSP would have been sent, indicated by red "arrow".

Could you check how much time it takes in your  recv_cb from start until  bt_le_per_adv_set_response_data() is called ? 

 

[Hung Bui]

In addition to the application, there are other factor can affect the time it take for the response to be queued. For example the length of the advertising data, other layers/modules in Zephyr and BLE host. 
The controller is capable of sending the response with is 1.25ms response slot delay. But it may not be feasible to do with the Zephyr Host in a normal application.

[jjjjzh]

Hi Hung Bui,

Thanks a lot for the clarification. Now I understand that even though the controller can handle 1.25 ms delay, it’s not really practical with Zephyr Host because of the extra overhead.

After changing responseSlotDelay from 2.5 ms to 11.25 ms, the problem is gone, which matches your explanation. This makes sense now.

Appreciate your help!

Best,
Junhao