Extend number of devices for PAwR (Coded PHY)

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

Parents
  • 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.

Reply
  • 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.

Children
  • 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.

  • Sorry! My math was off on this, didn't mean to provide poor advice. My team is currently working on a similar PAwR interface with 25+ units. If we have extra time during field testing, I'll give your parameters a shot to see if there's an underlying problem with the Zephyr code or if it's related to your configuration. 

  • Hi,

    No problem, it's easy to get mixed up with the PAwR parameters.

    Thank you, don't hesitate to let me know if you have any information.

    Yann

Related