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:

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

I misunderstood this in your initial ticket, my bad.

mtfurlan_t said:

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.

 You could avoid this by having the update complete before the lowest possible advertising interval. I.e if you advertising interval is 20 ms then the update needs to finish before 20 ms has passed since the last advertising. If the timer is restarted every time an advertisement is finished, then you would not drift out of sync.

The only other option would be to use radio notification and update the data following every active radio period.
Please see the discussion in this ticket.

Are you going to connect to multiple centrals at the same time - will you keep advertising after a connection is made, is this the issue?

mtfurlan_t said:

Also, as of a few months ago, the nRF Sniffer doesn't support coded phy or extended advertisements:

I was unaware that you were using coded phy / extended advertisements, but yes, this is correct,

Best regards,
Karl

[mtfurlan_t]

You suggest restarting a timer every time an advertisement is finished, how do we figure out when an advertisement is finished?

This is the core of the question I'm trying to ask, how to get notified whenever an advertisement is finished.

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.

[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.