This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

maximum number of broadcasters scanned from a central device on Bluetooth 4.0 Low Energy

Hi,

the specs of the new bluetooth 4.0 explains two important details about roles and connections.

- A device that acts as a broadcaster and/or peripheral role, supports advertising. Ads are sent over only 3 channels, one packet per channel. Advertising packets can send information like TX power level, discoverability or hardware address, as three examples.

- The device that has the role of a central unit, can scan devices (advertisings) through passive or active scan, to obtain information like the ones given before.

My question is the following. How many devices sending advertising messages (PDUs) can be detected at a time by a central unit? the specs gives information about BLE topology (star), or maximum number of active devices connected to a master (limitless, when on previous versions of BT, the maximum where 7), but they dont give information about the maximum number of devices that a master can scan at a time.

In BT 2.1 for instance, and as it is explain on this post,

http://stackoverflow.com/questions/837644/how-long-does-it-take-to-scan-for-bluetooth-devices-in-range-of-an-iphone/840059#840059

the number of devices after 12.8 seconds of Inquiry scan is more or less 29 unique hardware devices. Normally Android or iPhone dont support more than 12 seconds for scanning procedures. But in BLE, it is support more than 255 active members connected to a master. Are there some real numbers that can give a clue about how many ads can be scanned or processed after 12 sec of scanning from a master? A tipical example could be the case of having 255 devices (slaves) sending temperature signals every 10 seconds, but lots of them get out/in range from the master (central role), so normally, you will encounter lots of "peripherals" sending ads when they want to reconnect again. How can be managed this situation?

thank you very much in advance

  • In theory, there is no limit for BLE more than the memory space.

    In practice, the TI BLE stack has nowadays a max. of simultaneous connections = 3 devices, which probably is going to be increased in the next 1.2 version, which do not ask when is going to appear because it is unknown, but not far.

    Regarding advertisements, theoretically there is no limit in BLE. What happens in practice is that, since you have only 3 advertising channels, a lot of BLE devices advertising themselves at same time will result in collisions. So I think the max advertisers being differentiated in a single ADV / SCAN interval was something between 5 or 6, as far as I have read from other posts.

    I do not know if silentiating an advertiser somehow could result in more probabilities of detecting a new one like is done in some steps of RFID anticollision protocols. Please note the first Bluetooth versions differentiated the Inquiry and the Naming procedures, so it is not true you can distinguish so many devices in a row if not using the Extended Inquiry Procedure, which, in turn, was not supported by all the devices. BLE has taken this approach directly by including so many info into the ADV frame.

    I hope I've answered your question but in turn, I would like a TI folk indicating if there is some kind of silenciate-an-advertiser procedure :) Any hint?

  • Hi kazola,

    first at all, thank you very much for your answer.

    To me is a little bit disappointed the actual specs of BLE. It sounds ridiculous that it only lets 3 devices as active connections with a master.

    By the way, i thought about the posibility of colissions when there are only 3 channels for advertisement. Its really disappointing again that BLE havent worked on the possibility that, if it can manage, in theory, more than 255 active devices (as we are reading in all articles about it on internet), there are going to be only 3 channels for ads, so again, we are having the same issues that with BT 2.x or 3.x, in terms of slaves discoverability. How can you discover 255 broadcasters in a row? with only 3 channel ads its impossible.

    I would like to know if some folk coud give us information not only about collision avoidance protocol, but also about test lab real numbers about discoverability in situations of high number of broadcasters. I really dont have budget for test lab with 100 BLE modules :-)

  • The BLE specs are not limited to 3 connections. The current TI 1.1 stack is, but this will be improved in next versions of the stack. Don't change my words.

    Perhaps by establishing a connection to a device, this stops advertising, which can make room for other advertisers probability of non-collision :) but I do not know. That is what I wanted a TI folk to answer. Bye.

  • kazola said:
    The BLE specs are not limited to 3 connections. The current TI 1.1 stack is, but this will be improved in next versions of the stack. Don't change my words.

    "[..] To me is a little bit disappointed the actual specs of BLE. It sounds ridiculous that it only lets 3 devices as active connections with a master.[..]"

    I don't know to what you refer about changing words, when i was refering to actual specs, that as you pointed out, only lets 3 active connections :-).

    Refering to stablishing a connection, you are right. After an "ADV_IND" PDU (advertising PDU), if you are using active scanning, the master answers with a "CONNECT_REQ", so the connection procedure starts between 'master' and 'slave', and the broadcasters stops advertising.

    Once you connect all devices, and there is an active connection with every 'slave', your reasoning is right, but in the cases that the 'slaves' out of range that start to broadcast ads, are not so many amount that create ads collisions.

    So we are again at the beggining of the question. How many devices can be scanned at a time in BLE (how many different ADV_IND PDUs). Hope some folk can help also.

    Thanks again Kazola.