• State Verified Answer
  • Replies 6 replies
  • Subscribers 75 subscribers
  • Views 1758 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 319379
Options

BLE PAWR limitiations

Aleksa

Hello all,

I've been playing around with PAwR for a while now, and I have some doubts that I just didn't get a chance yet to clear up.

0. First and foremost, I'd like to understand struct bt_le_ext_adv_cb a bit better. It seems to me like pawr_data_request is sent to the upper code layers as soon as a subevent is transmitted, and it's always asking for a single subevent worth of data? What I'd like is to receive it after all the response slots are through. So that my broadcaster has the time to receive all the answers, and based on them, decide what the next subevent should send!

Some other things I was not able to figure out:

1. What is the biggest payload that a PAwR scanner can transmit during a response slot? What is the maximum payload that the scanner can send in a subevent?
2. What is the maximum number of response slots (255?)?
3. Did the max ble advertising interval recently increase to 20+ seconds or am I tripping?
4. Why does a sync get lost, is it due to clock inaccuracy? Can this be mitigated? In my setup, the broadcaster has a 10+ seconds advertising interval, and sync gets lost quite often on the scanner.

Cheers,
Aleksa!

Parents
  • +1

    Hi Aleksa

    Yes, sorry about the late reply, but I have been out of office over the holidays.

    The timing of the data request callback is not really deterministic because of the delays in the system. So this is not something we can guarantee. The specification only states that the request shall be generated when there are buffers available, and there are no restrictions for timing.

    The number of subevents it requests data for can be configured with the BT_CTLR_SDC_PERIODIC_ADV_RSP_TX_BUFFER_COUNT config, and if you want to know if/when no response is received, you can enable the BT_CTLR_SDC_PERIODIC_ADV_RSP_RX_FAILURE_REPORTING to generate a response report event with Data_status = 0xFF according to "7.7.65.37 LE Periodic Advertising Response Report event" from the Bluetooth spec. That way the application can know when the time has passed all response slots. Meaning the application can count response reports before sending the data for the next subevent. 

    Even though ESL restricts payload to 48 bytes, it does not count EAD data for example. So it is a bit bigger than 48 for the ESL use case.

    PAwR supports 249 bytes payloads which can be configured with this config: https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/bluetooth/controller/Kconfig#L433

    Best regards,

    Simon

Reply
  • +1

    Hi Aleksa

    Yes, sorry about the late reply, but I have been out of office over the holidays.

    The timing of the data request callback is not really deterministic because of the delays in the system. So this is not something we can guarantee. The specification only states that the request shall be generated when there are buffers available, and there are no restrictions for timing.

    The number of subevents it requests data for can be configured with the BT_CTLR_SDC_PERIODIC_ADV_RSP_TX_BUFFER_COUNT config, and if you want to know if/when no response is received, you can enable the BT_CTLR_SDC_PERIODIC_ADV_RSP_RX_FAILURE_REPORTING to generate a response report event with Data_status = 0xFF according to "7.7.65.37 LE Periodic Advertising Response Report event" from the Bluetooth spec. That way the application can know when the time has passed all response slots. Meaning the application can count response reports before sending the data for the next subevent. 

    Even though ESL restricts payload to 48 bytes, it does not count EAD data for example. So it is a bit bigger than 48 for the ESL use case.

    PAwR supports 249 bytes payloads which can be configured with this config: https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/bluetooth/controller/Kconfig#L433

    Best regards,

    Simon

Children
No Data
Related
Terms of service