This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to have a couple hundreds of nrf51822 using S130 advertise at the same time

Hi all,

Short version: I want to make 200 devices using nrf51822 (and S130 v0.5.0-1alpha), all advertising/scanning at the same time, and process RSSI readings for proximity estimation. I'm only interested in short range proximity (<3m), but I'd like to have an estimation as responsive as possible (by advertising as fast as possible). I was successful with 20 devices, but now I wonder about scalability for 10x this number. Has anyone here had experience with this type of scenario and would have advice on the feasibility of it and the best settings I could use (for advertisement speed, tx power,...)?

Longer version: First sorry for how dry my introduction was, but I figured out other people might look for the same question (or not) and a short intro will help them decide if they want to read the rest :) I want to make interactive badges which (roughly) guess how many people are close to you by advertising/scanning and estimating proximity by using rssi readings. I was pretty successful with 25 of those, but I'm concerned about the scalability to 200 of them. My understanding is that there's 3 channels for advertising, the faster everyone want to advertise, the more likely collision will happen. So it's about finding the right balance between responsiveness for the proximity estimation and collision rate.

  1. Is there an easy way to measure collision rate (either by sniffing BLE communication from the pc, or on the chip for adaptive settings) and predict the evolution of collision rate when the number of device/packet increases ?
  2. As I'm only interested in short range proximity, I was thinking of decreasing the power on the antenna -- It's not a big deal if there are 200 badges, if they can only "see" on a 10m radius, and there are never more than 30 devices in that radius. So my second question is : what would happen if a collision happens but out of the two packets colliding, one as a stronger signal than the other. Would error correction be good enough to pick up the strong packet or would it just throw both of them away (I guess the answer is not black or white but more depending on how much one of the packet can be seen as noise)
  3. If anyone has graph or formulas for the two previous question, I'd love to see them :)

Thanks for those reading so far, I'll happily share as much of my findings as I can (as it seem quite a few people are interested in proximity sensing using multiple devices)

  • Phillippe,

    I needed to figure out the same thing. It's one of those nasty exponential effects. To first approximation it's ethernet math from Metcalfe and Boggs. Being a bear of little brain, my back-of-the-envelope estimates, based on an overly simplistic model (please correct me) were as follows:

    Assume a single adv. channel rather than 3. Assume an advertising packet fills the ether for 300uS every 10 seconds-ish. Assume that there is no collusion between nodes, and no other traffic.

    Then the probability of node A colliding with node B is 300/(10.24*1000) ~ 3%.

    The probability that A does not collide with B is (1 -(300/(10.24*1000))) ~ 97%

    If there are 20 nodes, then the probability that nobody collides with A is (1 -(300/(10.24*1000))) ^ 19 ~ 57% So you were probably experiencing no worse than a 50/50 chance of a collision, which seems like an engineers fighting chance.

    If there are 200 nodes then it gets a lot worse: ~ 0.3% (Snowball's chance in hell)

    The probability that all 200 nodes don't collide is some binomial theorem calculation which makes it all a lot worse still.

    And then of course, every collision results in a re-transmit and you get a packet storm, so everyone has to back off and wait.

    I'm sure that the BLE designers figured the model out, and have much better answers than these.

  • I am not an expert with the BLE specification, but I believe there are random back off times in the case of a collision.

    During our first product development we wanted to stress test our mobile app to make sure it could keep up with lots of our devices in a small space all advertising at the same time. We ran that up to 80-100 devices without seeing a problem with collisions preventing us from seeing the advertising packets and connecting to devices.

  • Thank Mik for your insight. I believe you have a factor 1/1000 off (as the advertisement duration is in us rather than ms). As a back of the napkin approximation it's a good start I guess, there are a few extra details to add for a more accurate model (the three channels for adv, the 3 messages per adv interval, the (uniformly?) random duration between two messages, etc.). Unfortunately probabilities have never been my forte !

  • Thanks John for sharing your experience, do you remember what advertisement interval you were using (as the more packet you send the more likely you'll get collision)?

  • Hi Philippe,

    For the first 30 seconds after the device powers up or comes out of reset we advertise every 20mS. After 30 seconds we slow the advertising rate to 1285mS.

Related