Question about avoding collision

RE: Question about avoding collision

kunaal — Wed, 08 Apr 2020 14:03:12 GMT

Dear Jan,

I'm working on a solution and facing a few difficulties. well, I have more than 100 smartphones (android and iOS) devices in closed proximity were all the devices are logging each other with say duty cycle of 1. so constant scanning is happening.I read somewhere that when the number of devices increases then the probability of scanning the advertisement falls drastically so will that mean that there would be the possibility of more collision. will all the devices will be able to log each other ? will it also depend on how much time these devices are there together in that crowded space? I also read about the Backoff scheme but as you know android and other OS don't expose that level of control. so what's the way out to ensure maximum logging? can you please help as the solution is related to the current Covid crisis and a quick reply would be highly appreciated.

RE: Question about avoding collision

endnode — Mon, 24 Jul 2017 09:52:13 GMT

Glad to help. Marking correct answer and closing the question is good practice, helping other people when they search on the forum for similar topics;)

RE: Question about avoding collision

Allen — Mon, 24 Jul 2017 09:37:04 GMT

Dear Jan,

Thank you for your quick reply.

Your advice was very helpful to understand about "collision of BLE"

Thank you, Allen.

RE: Question about avoding collision

endnode — Mon, 24 Jul 2017 09:25:49 GMT

Hi Allen,

Not all is true. Yes, collisions during Broadcasting/Observing phase is limited by adding mandatory jitter to Adv. interval (so even if two advertisers have temporary collision on one packet and they have the same adv. frequency they should go out of sync very soon). However if you want to do active scanning (SCAN_REQ) or connection (CONNECT_REQ) then you can easily get collisions and DoS situations when too many observers/central devices targets one Broadcaster/Peripheral at the same time. And unfortunately this is real example, just buy 10 Samsung phones and let them scan with maximum duty cycle (Android BLE API) and your one broadcaster will have basically all Rx slots (mandatory to start exactly 150us after end of Tx) occupied by SCAN_REQ packets, there will be collisions and hardly any CONNECT_REQ will get through. But that's limit case.

Now to second part (connection link) which you have wrong understanding: frequency hopping is basically fixed. In CONNECT_REQ packet masters says what is initial channel map, where the two devices will meet for the first time (channel number and delta from CONNECT_REQ) and then sequence of hopping is fixed. The only way how to change it is to change channel map or connection request (both can be changed during connection but this procedure is very rare).

Finally there is no algorithm in Nordic BLE stacks (Soft Devices) or special HW magic on nRF5x chips to detect channel occupancy or collisions. You either do this yourself on higher layer (but hard to say how you could get to low level data and analyze them) or you design and implement your own stack or you use some other HW to solve this. However there is a reason why no one is doing this in nRF5x or similar low power chips today: collisions during connection link are so rare that it's negligible in real world applications. If you have very noisy environment (in 2.4GHz ISM band;) or application requiring extreme reliability then you have problem BUT then BLE and nRF5x chips are not for you!

Cheers Jan