bt_le_per_adv_set_subevent_data

[joey]

Hi

I'm using the periodic_adv_conn example from SDK 3.0.0. In the request_cb function, the bt_le_per_adv_set_subevent_data function is used to load data for future subevents. However, I found there is a total length limitation that cannot exceed 255 bytes. My question is: isn't the maximum length for each Periodic Synchronization Broadcast packet 255 bytes? I now want to include 130 bytes of data in each subevent broadcast. Because of this total 255-byte limitation, I cannot load the data for several subevents

Thanks

[Einar Thorsrud]

Hi,

This is limited by HCI which has a length field of 8 bits, making 255 the maximum. So you will have to make separate calls for each of your 130 byte packets.

[joey]

How should I create a new separate call, and what should I pay attention to?

[Einar Thorsrud]

I do not think you need to pay attention to anything specific. Instead of calling with an array of two (or more) subevent parameters, use only one. So the second parameter is 1, and the thirs is the pointer to the single bt_le_per_adv_subevent_data_params instance (instead of an array). You probably allready call this from a pawr_data_request and this does not need to change.

[joey]

1、You mean that inside the request_cb, instead of loading multiple broadcast data packets at once  it should be changed to filling in only one data packet each time?

2、I now only fill in one piece of data each time I enter the request_cbfunction. Why does the starting event request->startsometimes begin at 1 or 4? My understanding was that when filling in data one by one, it should cycle through 1, 2, 3, 4, 5, and so on in sequence.

static void request_cb(struct bt_le_ext_adv *adv, const struct bt_le_per_adv_data_request *request)

{

    int err;

    uint8_t to_send;

    /* Continuously send the same dummy data and listen to all response slots */

    //printk("request->count: %d,ARRAY_SIZE(subevent_data_params): %d\n",request->count,ARRAY_SIZE(subevent_data_params));

    printk("request->start %d\n",request->start);

    //to_send = MIN(request->count, ARRAY_SIZE(subevent_data_params));

    //for (size_t i = 0; i < to_send; i++) {

        subevent_data_params[0].subevent = (request->start + 1) % per_adv_params.num_subevents;

        subevent_data_params[0].response_slot_start = 0;

        subevent_data_params[0].response_slot_count = NUM_RSP_SLOTS;

        subevent_data_params[0].data = bufs;

    //}

    err = bt_le_per_adv_set_subevent_data(adv, 1, subevent_data_params);

    if (err) {

        printk("Failed to set subevent data (err %d)\n", err);

    }

}

[Einar Thorsrud]

joey said:

1、You mean that inside the request_cb, instead of loading multiple broadcast data packets at once  it should be changed to filling in only one data packet each time?

Yes, as you have 130 byte packets, and there is a limit of 255, you cannot fit more than one.

joey said:

2、I now only fill in one piece of data each time I enter the request_cbfunction. Why does the starting event request->startsometimes begin at 1 or 4? My understanding was that when filling in data one by one, it should cycle through 1, 2, 3, 4, 5, and so on in sequence.

Yes, that is how it should be. Ref this figure frmo page 3049 in BT core spec 6.1:

However, if the controller does not get data in time it will send empty packet to that subevent. So i could be that some other processing or similar delayed this? As long as you stil get the data you need through, it should not be a problem.

[joey]

subevent_data_params[0].subevent = (request->start + 1) % per_adv_params.num_subevents;

According to my program here, it should normally be a cyclic filling of data in the order of 0, 1, 2, 3, 4 for sending, and each piece of data should not be empty. However, during actual testing, I found that only the 1 and 4 from request->start contain data. I wonder if this is related to the amount of data the controller requests each time. For example, at certain moments, the controller might need to fill in 3 pieces of data, but I only filled it once, resulting in the controller sending empty data for the subsequent two pieces. I saw this issue mentioned that the amount of data requested by the controller each time needs to be adjusted. Is it that I need to do this?

devzone.nordicsemi.com/.../526495

[Einar Thorsrud]

Hi,

Good point, I did not think of that. It should be OK to make multipe calls then within a callback (if the count in the request callback is 3 you could make 3 calls with one packet each). I have not tested this on my end, though.