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!

[Simonr]

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

[Aleksa]

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

[Lorenzo Amicucci]

Aleksa said:

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?

you need to feed buffers properly to achieve maximum speed and work around this. You can also check how we implemented the access point here: https://github.com/NordicPlayground/nrf-esl-bluetooth/tree/main/samples