• State Verified Answer
  • Replies 6 replies
  • Subscribers 75 subscribers
  • Views 1742 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!

  • 0

    Hi

    Most of these questions are answered in the Bluetooth 5.4 technical overview, or the Bluetooth 5.4 specification, but I think its features are best summarized in this video posted by the Bluetooth SIG here. Additionally my colleague Hung made a blog post that describes a practical guide to PAwR here.

    I'll try to add the answers in brief here.

    1. The maximum ESL payload you can have is of 48 octets per subevent, and a maximum of 128 subevents can be added per PAwR event.

    2. There can be up to 256 response slots.

    3. Yes, the periodic advertising interval is in the range of 7.5ms to 81.91875 seconds.

    4. There are multiple reasons a sync can be lost, clock inaccuracy can be one of them. Other reasons could be interference, range between the devices is too large, badly tuned antenna on either side, the receiver not being on/scanning often enough to pick up devices that rarely advertise.

    Best regards,

    Simon

  • 0 in reply to Simonr

    Hi Simon,

    Thank you very much for your answers. I was not aware of that blog spot and video. I've gone through the official docs and some other nordic blog post wrt. pawr, but I couldn't find the answers that I was looking for.

    However, you haven't answered my question number 0. Below is a sketch that explains it. I want to be able to set subevent data after rsp_slots, for the next subevent. But it seems that as soon as the subevent is sent, the data for the next subevent is requested. Is there a way to work around this?

    I'd also like to know what's the maximum number of octets that a broadcaster can transmit for a single subevent. I was able to transmit around 70-80 octets.

    Best Regards,
    Aleksa

  • 0

    Sorry,

    I missed question 0 here it seems. For that I will need to ask our developers I think, as I'm not able to see from the spec or code if what you're describing is possible in PaWR. Unfortunately we're close to the Holiday season here in Norway so I can't guarantee I hear back from them until early January.

    Thank you for your patience!

    Best regards,

    Simon

  • 0 in reply to Simonr

    Hi Simon,

    Happy holidays! Any update on this?

    Best regards,
    Aleksa

  • +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

Related
Terms of service