Extend number of devices for PAwR (Coded PHY)

[Yannch]

Hi all !

I'm writing this message because I'm having problems trying to increase the number of devices in PAwR (I use Coded PHY).

I based my development on the SDK 2.8.0 example (Periodic_adv_conn / Periodic_sync_conn). I also tried Periodic_adv_rsp / Periodic_sync_rsp examples without success.

I've modified it so that I don't have to connect every time via on the TX side:

bt_conn_le_create_synced function()

On the RX side, I have a fixed subevent and slot numbers to answer to TX.

Based on SDK example, I can exchange data with 25 devices (5 subevents / 5 slots)

I used the following configuration:

#define NUM_RSP_SLOTS 5
#define NUM_SUBEVENTS 5
#define SUBEVENT_INTERVAL 0x30

static const struct bt_le_per_adv_param per_adv_params = {
	.interval_min = 0xFF,
	.interval_max = 0xFF,
	.options = 0,
	.num_subevents = NUM_SUBEVENTS,
	.subevent_interval = SUBEVENT_INTERVAL,
	.response_slot_delay = 0x5,
	.response_slot_spacing = 0x50,
	.num_response_slots = NUM_RSP_SLOTS,
};

When I try to increase the number of devices (8 subevents / 20 slots per subevent), I don't get the same behavior.

Below are the timings I use depending on the number of subevents and slots.

#define NUM_RSP_SLOTS 20
#define NUM_SUBEVENTS 8

static const struct bt_le_per_adv_param per_adv_params = {
	.interval_min = 0x960,
	.interval_max = 0x960,
	.options = 0,
	.num_subevents = NUM_SUBEVENTS,
	.subevent_interval = 0xF0,
	.response_slot_delay = 0x10,
	.response_slot_spacing = 0x50,
	.num_response_slots = NUM_RSP_SLOTS,
};

I saw that the PAwR feature is still experimental in the las version of the SDK, could this be related or is there something I'm doing wrong?

Thank you in advance for your answers or feedbacks.

Yann

[Hieu]

Hi Yann,

Your configurations seem feasible. Could you please provide more details on what kind of failure you are facing?

Are there any logs? What are the symptoms?

Hieu

[rbmarcus]

Not sure if this will work for your case, but I found that setting the response slot delay and spacing to fit exactly within a subevent interval results in advertising errors on the access point. It may be the same for subevent intervals fitting into the min/max periodic advertising intervals. You could try reducing the subevent interval to 298.75ms (0xEF) to see if that solves the issue.

[Yannch]

Hi Hieu,

Thanks for you answer.

Yes sure, what I can see is that with the initial parameters (5 subevents / 5 slots per subevent) I can synchronize and exchange data between transmitter and receiver.

Transmitter:

[00:00:00.011,535] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.011,566] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.011,596] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 254.63788 Build 573996906
[00:00:00.012,786] <inf> bt_hci_core: Identity: C8:22:35:1D:70:9F (random)
[00:00:00.012,817] <inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x104e, manufacturer 0x0059
[00:00:00.012,847] <inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x104e
Start Periodic Advertising
PAwR RSP : Subevent : 0 Slot : 2
PAwR RSP : Subevent : 0 Slot : 2
PAwR RSP : Subevent : 0 Slot : 2
PAwR RSP : Subevent : 0 Slot : 2
PAwR RSP : Subevent : 0 Slot : 2
PAwR RSP : Subevent : 0 Slot : 2

Receiver:

Synced to 69:D7:06:00:1C:75 (random) with 5 subevents
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0

Now if I update parameters (Subevents 8 / Slots per subevent 20)

With these settings, the device receiving the PAwR signals can't synchronize.

Transmitter:

[00:00:00.011,352] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.011,383] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.011,413] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 254.63788 Build 573996906
[00:00:00.012,573] <inf> bt_hci_core: Identity: C8:22:35:1D:70:9F (random)
[00:00:00.012,634] <inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x104e, manufacturer 0x0059
[00:00:00.012,664] <inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x104e
Start Periodic Advertising

Receiver:

Synced to 71:31:A2:CE:53:E5 (random) with 8 subevents
Failed to set subevents to sync to (err -5)
DEBUG - CMD RESP 0x0 0x1 0x0 0x0 0x0
Failed to send response (err -5)
Receive Terminated Callback

 

[Yannch]

Hi,

Thanks for your reply, I tried your suggestion without success.

If I explain a little bit my timings:

response_slot_spacing = 0x50 --> 80(decimal) * 0.125 = 10ms
response_slot_delay   = 0x10 --> 20(decimal) * 1.25  = 20ms
subevent_interval     = 0xF0 --> 240(decimal)* 1.25  = 300ms

NB subevents = 8
NB slots per subevent = 20

subevent_interval = NB_SLOTS * response_slot_spacing + response_slot_delay
20 * 10ms + 20ms = 220ms

We have some space with the value of 300ms for subevent_interval

interval_min = 0x960 --> 2400(decimal) * 1.25  = 3000ms

With a subevent_interval=300ms and 8 subevents --> 8 * 300ms = 2400ms

We have some space with the value of 3000ms for interval_min / max

I should have some margin in the timings at different levels.

[Hieu]

Hi Yann,

Unfortunately, I am working remotely and do not have enough device to reproduce the issue.

What do you think about starting from the working baseline, and slowly change the configurations, and do incremental tests to see at which point the issue occurs?

I recommend this order:

1. Periodic Advertising Interval
2. Subevent Interval
3. Number of Subevents
4. Response Slot Delay
5. Response Slot Spacing
6. Number of Response Slots

If you are able to detect which one fail, try switching up the order, but of course keep it feasible (e.g., don't increase Number of Subevents before you have widened the Advertising Interval)

It would give us some clues on what is wrong.