updating periodic advertising data after each advert

RE: updating periodic advertising data after each advert

ovrebekk — Wed, 07 Dec 2022 14:39:37 GMT

You welcome Jason. The best of luck with your project 🙂

RE: updating periodic advertising data after each advert

Jason — Wed, 07 Dec 2022 08:34:08 GMT

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

RE: updating periodic advertising data after each advert

ovrebekk — Wed, 07 Dec 2022 08:21:55 GMT

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

RE: updating periodic advertising data after each advert

Jason — Mon, 05 Dec 2022 12:13:52 GMT

I see, thanks for the explanation.

[quote userid="2116" url="~/f/nordic-q-a/94507/updating-periodic-advertising-data-after-each-advert/398953"]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?[/quote]

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!

RE: updating periodic advertising data after each advert

ovrebekk — Mon, 05 Dec 2022 11:52:33 GMT

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.

[quote user="JasonR"]I assume this is only for extended adverts, not periodic adverts. [/quote]

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

RE: updating periodic advertising data after each advert

Jason — Sun, 04 Dec 2022 16:05:00 GMT

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.