Updating bluetooth advertisement data after each advertisement

[mtfurlan_t]

We are using manufacturer specific data to broadcast data at 10Hz.

We're about to do some testing to evaluate different adverting and scanning parameters to find the best for our usecase.

We would like to update the advertisement data after each advertisement so each advertisement can have a unique message ID, allowing us to track how many advertisements are lost.

One of the things we are testing is how much connecting to a bluetooth sensor changes our advertisements.

The Radio Notification Event looked promising, but it doesn't have any way to filter the events for why the radio was used, so if we are connecting to a sensor we cannot use this to know when an advertisement has been transmitted.

We tried setting the advertising max_adv_evts module to 1, but the setup and teardown of the advertising stuff every cycle limited us to about 2Hz.

Are there any other ways to get notified when an advertisement has been transmitted, or are there ways to track what the radio is doing so we can use the radio notification module and filter out radio events not from advertisements?

Cheers

[mtfurlan_t]

We want to test a few combinations of parameters like advertising interval to see how it affects packet loss.

We may very well decide to transmit the same packet multiple times, but for now having a good understanding of exactly how many packets are lost is important so we can decide what parameters work best for our use case.

We will try using a timer to update the data.

I'm concerned that with the random delay added to the advertising interval (BLE core spec v5.2 section 4.4.2.2.1) the timer and advertising interval will fall out of sync.

The advDelay is 0-10ms, so assuming the average of 5 and an advertising interval of 100ms/10Hz: 100/5 = 20, so every 20 advertisements it will be off by 1 advertisement, and at 10Hz 20 advertisements is 2 seconds.

So every 2 seconds we will have lost an advertisement?

I guess we can try to account for this on the analysis side.

Thank you for all the help.

[Karl Ylvisaker]

Hello again,

Sorry for my terribly late reply - I have been out of office for some time now.

Do you still require support on this issue, or have you moved on from it in the meantime?

While your theoretical calculations on offset might be correct, you may loose packets due to environment noise / interference on the 2.4 GHz frequency band. If you insist on using advertisements to transfer data - and it is important to receive as many packets as possible - then I would again recommend that you send the advertisements multiple times.

If it is important to receive every packet, then I must recommend that you establish a BLE connection to do the transfer. This way, you can guarantee that no data is lost in the link.
Also, if there are long intervals between when new data is available, you may utilize the slave latency feature to reduce power consumption on your peripheral device.

Best regards,
Karl

[mtfurlan_t]

Ended up dropping other requirements for now so we could use the radio notification API for this part of the testing.

Just never got the timer to work properly.

We will have to re-visit this in a few months when the next part of the testing happens.

[Karl Ylvisaker]

mtfurlan_t said:

Just never got the timer to work properly.

If you need help getting the timer to work I recommend that you create another ticket ( since it diverges from the original ticket issue here ).
There, you will receive help on how to proceed with the timer.

mtfurlan_t said:

We will have to re-visit this in a few months when the next part of the testing happens.

All right, let me know if you should encounter any issues or questions in the meantime.

Good luck with your development!

Best regards,
Karl