BLE PAWR limitiations

RE: BLE PAWR limitiations

Lorenzo Amicucci — Mon, 15 Jan 2024 12:38:32 GMT

[quote userid="102708" url="~/f/nordic-q-a/106699/ble-pawr-limitiations/460970"] 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?[/quote]

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

RE: BLE PAWR limitiations

Simonr — Wed, 10 Jan 2024 09:13:02 GMT

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

RE: BLE PAWR limitiations

Aleksa — Tue, 09 Jan 2024 18:44:15 GMT

Hi Simon,

Happy holidays! Any update on this?

Best regards,
Aleksa

RE: BLE PAWR limitiations

Simonr — Thu, 21 Dec 2023 08:18:55 GMT

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

RE: BLE PAWR limitiations

Aleksa — Tue, 19 Dec 2023 08:09:27 GMT

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

RE: BLE PAWR limitiations

Simonr — Mon, 18 Dec 2023 11:55:51 GMT

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