updating periodic advertising data after each advert

[Jason]

Hi, I use periodic advertising to send live data based on readings from an accelerometer. I want to change the advertising packet after every advert to the new values.

My advertising interval is currently set with 

    struct bt_le_per_adv_param per_adv_param =
        {
            .interval_min = 80, // 100ms		N * 1.25 milliseconds
            .interval_max = 100, // 125ms
            .options = BT_LE_PER_ADV_OPT_NONE,
        };

At the moment I just change the advertising data by calling bt_le_per_adv_set_data every 100ms. But this seems quite imprecise

Is there a way to get a callback when the advert goes out? Or to read a counter of advertisements sent? Or to stack up an array of adverts somehow?

I've looked in the docs and all I can find is radio notify event which isn't quite what I want. I don't think it differentiates between connection events and advertisements.

I've also looked through zephyr/include/zephyr/bluetooth/bluetooth.h but I couldn't find anything that looked useful

Is there an easy way to do this?

Thanks for your help.

-Jason

[Jason]

Is there a periodic advertisement equivalent of this?

bt_le_ext_adv_sent_info::num_sent

I assume this is only for extended adverts, not periodic adverts. 

[ovrebekk]

Hi Jason

There is no way to get a callback for every sent advertisement packet unfortunately. The radio notification feature is the closest you get, and as you say this one will not differentiate between the differents types of events. 

It's a bit odd that the timer approach would be imprecise though. You mean to say that you don't see the data change as expected?

Possibly it would work better if you send the periodic advertisements at a faster rate than the data gets updated. Then you have a higher chance of picking up each accelerometer update, since there is always a risk that you don't manage to receive 100% of the advertise packets on the receiving side. 

Jason said:

I assume this is only for extended adverts, not periodic adverts. 

This one should work for periodic advertising as well.

First off, periodic advertising is based on extended advertising, and uses a similar principle of having a small packet sent on the primary (legacy) advertising channels that points to more data being sent on the secondary channels. 

Secondly, the bt_le_ext API's are not limited to extended advertising only. They are a replacement of the older bt_le_adv API that can do both legacy and extended advertising. 

Best regards
Torbjørn

[Jason]

I see, thanks for the explanation. 

ovrebekk said:

It's a bit odd that the timer approach would be imprecise though. You mean to say that you don't see the data change as expected?

I thought the periodic adverts are sent with a random delay of a few ms which meant that a fixed timer wouldn't stay in sync. I sometimes see a jump in the receiver so I assumed it was because the thread updating the data had gone out of sync with the advertisements. Perhaps it's sometime packet loss and sometimes because the threads went out of sync.

I think the simplest solution is to just send more adverts. I get better signal at long range and it's not much power compared to the LEDs I have to run all the time.

THANKS for you help!

[ovrebekk]

Hi Jason

Standard advertise packets are sent with random 0-10ms delay, that is correct, to avoid repeated collisions on the primary advertising channels, but I believe periodic advertising is not. Periodic advertising is sent on the secondary advertising channels and don't need randomized timing since there are a lot more channels available. 

Good to hear you found a good solution

Best regards
Torbjørn

[Jason]

ah yes of course you're right. Otherwise the receiver couldn't stay in sync.Thank you!

[ovrebekk]

You welcome Jason. The best of luck with your project