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

[Karl Ylvisaker]

Hello,

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.

 If you are using the advertising module then you may use the _advdata_update function to update your advertising data without having to start and stop the advertising. However, be advised that the _advdata_update function has a known issue, which requires that you have two adv_data instances that you alternate between passing to update and updating.
That is to say: you may not pass a single advdata instance to advertising start, update the same advdata instance and then provide it as the argument to _advdata_update.
Instead, you will have to have two advdata instances, where you pass one as the argument to the _advdata_update function, and then you may update the other advdata instance, before calling _advdata_update again with the most recently updated(not currently in use) advdata instance.

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?

Are you familiar with using the nRF Sniffer tool? It is a powerful tool when developing with BLE that lets you capture and monitor the ongoing nearby BLE traffic. This way, if you have selected your device in the Wireshark device menu, you may see every advertisement that the sniffer is receiving. You may also see the contents of the advertisement, to verify that no packets are lost, and much more.

Best regards,
Karl

[mtfurlan_t]

We know how to update the advertisement data, that's working fine, but the unknown part is *when* to update.

We could just set the advertising interval and run a second timer and just hope that we update the data at the correct times, but because the advertising has the slight random time added to prevent collisions it would gradually drift out of sync.

I was asking for ways to get notified of what the radio is doing so on the transmitting nordic board we could use the radio notification event callback to know when to update the data.

Also, as of a few months ago, the nRF Sniffer doesn't support coded phy or extended advertisements: devzone.nordicsemi.com/.../nrf-sniffer-coded-phy-support

[Karl Ylvisaker]

mtfurlan_t said:

I didn't explain the connections we're doing very well, sorry about that.

The advertising we are doing is separate to the BLE connection, in this case our advertising device will be the central.

Advertisements will continue during the connection.

With the radio notification event, it just tells us that that the radio turned on or off, not if it was due to advertisement or connection so it doesn't help us know when an advertisement is finished.

No problem at all, thank you for clarifying - this makes the issue easier to understand.
The fact that your device will be multirole has a lot to say for this, since the radio notification will trigger every time the radio is active - and there is therefore no way to be certain that it is indeed an advertisement that just finished.
So, I propose that you implement a timer that is equal to the advertising interval, and that you update the advertising data every time the timer expires.
This will by far be the easiest approach to your issue - the other options include not using the SoftDevice native multirole implementation, and rather implement a timeslot based advertising peripheral on your own, this will require significantly more work.

If I may ask, why are you going to update the advertising data every advertising interval? If you intend to use this as a connection-less way to transfer data to another device, please know that a single packet may be lost / corrupted here and there, which will lead to dataloss on this link - since there is no re-transmissions.
You could offset this by having each packet be sent more than 1 time, to increase the possibility that the recipient has seen at least one of the advertisements. 

Best regards,
Karl

[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