How does implement advDelay in nRF52832? (repost)

[Gaku Ueno]

I posted this theme, but the post is locked before fixed. I don't know the reason so repost. I'm sorry about this case.

-------------------------

Question:

I consider the radio collision of advertising packet, in the case there are several 10 BLE devices and the devices are powered on at same time.  How does implement advDelay in nRF52832?

-------------------------

About the previous post, Thank you for reply, Karl Ylvisaker!

I fear if the nRF52832 devices are powered on same time, the SoftDevices generates same pseudo random delay. And I’m considering methods to avoid the collision. So I want to know the implemented advDelay algorithm, and calculate collision probability.

[Karl Ylvisaker]

Hello again, gaku-ueno

I posted this theme, but the post is locked before fixed. I don't know the reason so repost. I'm sorry about this case.

No worries - the tickets get locked if an answer is verified, since this is used to indicate that the issue raised in the ticket is resolved.
No need to apologize, it happens sometime. For completeness, this was the other ticket.

Thank you for reply, Karl Ylvisaker!

No problem at all, I am happy to help!

I fear if the nRF52832 devices are powered on same time, the SoftDevices generates same pseudo random delay. And I’m considering methods to avoid the collision. So I want to know the implemented advDelay algorithm, and calculate collision probability.

It makes no difference if the devices are powered on at the same time, since the delay between 0 and 10 ms is added to each and every advertisement. The 0 - 10 ms delay changes with each advertising packet sent, so there should be no issue at all with packet collision between advertising BLE devices. Since advertisements happens so seldom already, and since their duration is so short, the chance of colliding BLE advertisements is neglectable. If an advertisement actually does collide the advDelay will ensure that the collision is not repeated.

A much larger concern is the potential other devices in the Radio Frequency environment the BLE devices are operating in - for example if there exists some devices that constantly broadcasts, like a WiFi modem or similar. This will have a much bigger impact on the BLE advertisements than any other BLE advertisements will have.
This is also why the three primary advertising channels are spaced out on the 2.4 GHz spectrum - so that if one or two of the channels are partly or completely overlapped by a WiFi (or similar) network the BLE device can still be found on the third advertising channel.

If you want to read more in-depth about this you could take a look at the BLE Specification. Please take a look at the answer by my colleague in this ticket for further information about the advDelay.

Best regards,
Karl

[Gaku Ueno]

Thank you!

I think it is important the affection of the Radio Frequency environment, too. So install place condition should be concerned.

And then, I should design the BLE communication timing. I read the advDelay algorithm is not defined in the BLE Specification 5.0, Vol 6 Low Energy Controller volume. I think if the advertising packet collide, the BLE module cannot detect the collision, so the collision is repeated. It would be great if you could teach me the concrete reason about "If an advertisement actually does collide the advDelay will ensure that the collision is not repeated.". 

And I think the advDelay random value is made from same seed at start-up, so the value is same among the devices that start at the same time. I would be appreciate if you could tell about it. 

[Karl Ylvisaker]

Gaku Ueno said:

I think it is important the affection of the Radio Frequency environment, too. So install place condition should be concerned.

Yes, if you are able to influence this it could greatly decrease the chance of packet corruption.

Gaku Ueno said:

the BLE module cannot detect the collision, so the collision is repeated. It would be great if you could teach me the concrete reason about "If an advertisement actually does collide the advDelay will ensure that the collision is not repeated.". 

Gaku Ueno said:

And I think the advDelay random value is made from same seed at start-up, so the value is same among the devices that start at the same time. I would be appreciate if you could tell about it. 

The BLE module could indeed not detect such a collision, but since the advDelay is based on a number from the random number generator they will not be synchronized even though they start advertising at the same time. You can read more about the Random Number Generator here.
You could visualize this as well with the Sniffer tool - have two devices start advertising at the same time, and observe that their added 0 - 10 ms delay will differ at every advertisement.

Best regards,
Karl

[Gaku Ueno]

Thank you, Karl Ylvisake!

I got the information and the reason that the advDlay will not be synchronized.

I appreciate your help. And I'll concern the environmental influence.

[Karl Ylvisaker]

No problem at all, gaku-ueno - I am happy to help!

Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl