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

Max of BLE devices simultaneously detected by a Smartphone in Central mode

I  would like to know how to compute or optimize the maximum number of BLE device (in advertisement mode) that can be detected by a Scanner (Smartphone app).

I can not find any answer of the maximum number of devices detected in the "same time" ? is it 10, 30, 100 or more ?

- Which parameters can be customized on the peripheral side to detect maximum number of devices ?

- Is it possible on the peripheral side to know if the device has been detected and stop the advertising during a period ?

Stoping the advertising will liberate some bandwidth for other devices ...

Parents
  • In the BLE specification there is no maximum number for advertising peripherals. However, obviously there are some practical limitations. The first is the available air-time; normally an advertising peripheral will transmit consecutively on the 3 advertising channels and occupy a single channel for approximately 0.5 ms (max. payload and connectable advertising packet). If all the peripherals in the area would be perfectly synchronized (which they are obviously not in most cases), have the same advertising interval of 10 seconds (BLE spec. maximum) and the scanner would be configured to scan that whole second on that specific channel, then there would be ‘room’ for 10000/0.5 = 20000 peripherals.
    However, in practice there are all kinds of other factors:

    • The peripherals are not synchronised. To overcome this, there is a randomized 10 ms delay after each advertising interval to create a higher probability of detection.
    • The scanner in most mobile devices scans on all channels consecutively to be more robust against interference.
    • Peripherals can have different, shorter advertising intervals.
    • Processing of received IDs of peripherals in the mobile device can be a bottleneck.

    As such, it is more a matter of probability than of a limited number of peripherals: event if the number is really high, in the long run, all advertising peripherals will be detected, but it can take a while. So the practical limitation is how long your system is allowed to wait for the peripherals to be detected. But lowering the advertising interval at the peripheral side will certainly help to reduce the probability of collision.

    As for letting the peripheral know that it has been detected: that is only possible when the scanner would connect and have the peripheral disconnect again. In BLE this can be done really quickly (probably well within 100 ms), so that would be the way to go.

Reply
  • In the BLE specification there is no maximum number for advertising peripherals. However, obviously there are some practical limitations. The first is the available air-time; normally an advertising peripheral will transmit consecutively on the 3 advertising channels and occupy a single channel for approximately 0.5 ms (max. payload and connectable advertising packet). If all the peripherals in the area would be perfectly synchronized (which they are obviously not in most cases), have the same advertising interval of 10 seconds (BLE spec. maximum) and the scanner would be configured to scan that whole second on that specific channel, then there would be ‘room’ for 10000/0.5 = 20000 peripherals.
    However, in practice there are all kinds of other factors:

    • The peripherals are not synchronised. To overcome this, there is a randomized 10 ms delay after each advertising interval to create a higher probability of detection.
    • The scanner in most mobile devices scans on all channels consecutively to be more robust against interference.
    • Peripherals can have different, shorter advertising intervals.
    • Processing of received IDs of peripherals in the mobile device can be a bottleneck.

    As such, it is more a matter of probability than of a limited number of peripherals: event if the number is really high, in the long run, all advertising peripherals will be detected, but it can take a while. So the practical limitation is how long your system is allowed to wait for the peripherals to be detected. But lowering the advertising interval at the peripheral side will certainly help to reduce the probability of collision.

    As for letting the peripheral know that it has been detected: that is only possible when the scanner would connect and have the peripheral disconnect again. In BLE this can be done really quickly (probably well within 100 ms), so that would be the way to go.

Children
  • Tx for this quick reply.

    If I understand:

    - If I set an advertising interval of 100ms, devices will be detected faster BUT available "Air time" will be reduce

    - If i set an advertising interval of 500ms, devices will be detected slowly BUT more "Air time" for other devices

    In addition and to allow more "Air time" and more "possible" detection by the smartphone:

    - Is it better to be in "Broadcast mode" on the device size ?

    - Is it better to be in "Non connectable mode" on the device size ?

    - Is it better to reduce the advertising message ?

    Is it exact ? Can you please advice ?

  • Increasing the advertising interval indeed gives more 'room' for devices. Theoretically the devices will be detected more slowly because a peripheral only sends 3 advertising packets (one on each advertisng channel) shortly after eachother and will keep quiet the rest of the advertising interval but also will switch-off its radio. But in practice it might just as well give better results because the probability of packets colliding is reduced.

    For a device to be 'connectable' it listens right after sending a advertising packet to allow for a scanner to respond. This is a very short period (Nordic's online power profiler gives a nice insight into the associated timing).

    Since a 'connectable' device is only listening (and thus takes no 'air time' during this period), it has no effect on its abbility to be detected.

    Shortening the advertising packet (i.e. the payload) is of course better because it shortens the advertising packet itsel and thereby the air-time. Playing around with the mentioned online profiler gives a good idea I think.

Related