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.

BLE with a lot of advertiser

Other Parts Discussed in Thread: CC2540

I would like to have a lot of BLE-devices in one room. But befor building 100 devices for a test, I would like to estimate how many BLE-devices are possible in the 3 advertising channels. The BLE-devices are sending all e.g. 10s advertising-packets on the 3 advertising channels. To estiminate the count of collisions I need the time which an advertiser blocks the channel. Where can I find this time?

_______¦Advertise-time¦____________________¦Advertise-time¦__________

_____________________¦Advertise-time¦________________________¦Advertise-time¦_________

  • In the Bluetooth v4.0 specs.

    https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

     

    It is a big document.

     

  • Hello,

    It would be something like 39bytes at 1Mbs  =  319uS.  I'd round up to 400us.   

    -Greg

  • This will also depend on the number of bytes in the advertising packet. The minimum duration of an advertising packet is 128 us and the maximum is 376 us. In addition, a scanner receiving advertising packets will need a gap between them in order to receive two subsequent packets correctly, so some extra microseconds should be added. 400 us sounds like a good approximation for maximum length packets, but if you know that the data transmitted is significantly less than maximum, you may reduce the number.

    If scanning or connection establishment takes place, you also need to take into account the 150 us inter-frame space (IFS) between the packets in that sequence. Such a sequence is:

    ADV_IND (128-376 us) -> IFS (150 us) -> SCAN_REQ (176 us) -> IFS (150 us) -> SCAN_RSP (128-376 us)

    and

    ADV_IND (128-376 us) -> IFS (150 us) -> CONNECT_REQ (352 us)

    In practice, a packet sent by another advertiser during IFS will also lead to a collision.

     

  • Thanks.

    I could comprehend the 376us (47Byte=376Bit==>376us), that is good.

     

    But I got also an other question. Could the turning on and the turning off of the radio also make some collision?

     

    Or is it really possible to have all 400us an advertising-packet in the air?

  • I am not sure if I understood your question correctly, but if you are asking whether a device may send some power on the air while the radio is being powered up, this will happen, but in most cases only right in front of the packet. There is no requirement in BLE on what to send (or not to send) in front of the preamble, and some manufacturers may for instance have a continuous wave there. It may last some tens of microseconds, but in order to save power, it is unlikely that you will see more than that. In the CC2540, there is just a few microseconds extra before the preamble and after the last bit.

    All in all, you may see that an advertising packet has 400 us of energy on the channel, but I doubt that you will see much more than that.

  • Thanks.

     

    It makes really sense to switch of the radio as much as possible to sove energy. I was just confused as I measured the current consumption of the CC2540. The Current consumption didn't change when I changed the lenght of data. I mine the length of the TX-current-peak was always about 250us!?

    I think I have to measure the antenna once with a frequency analyser to look whats there...

  • Thanks for info...I have some basic question regarding IFS

    Why BLE Protocol recommends to set T_IFS as 150us? Why we use T_IFS, I mean what will happen if we have no time gap between two packets? How can we set the value of T_IFS from host?

    Thanks

  • Akhil Kumar said:
    Why BLE Protocol recommends to set T_IFS as 150us?

    It does not recommend it; it mandates it (with a 2 us margin).

    Akhil Kumar said:
    Why we use T_IFS, I mean what will happen if we have no time gap between two packets?

    This would make it impossible to make the hardware work, as the Tx chain being powered down would interfere with the Rx chain being powered up. It would have been possible to reduce T_IFS, but this would have put harder requirements on the hardware manufacturers. A system with modified T_IFS would not be able to communicate with Bluetooth compliant systems having T_IFS of 150 us.

    Akhil Kumar said:
    How can we set the value of T_IFS from host?

    You can't. It's a fixed constant.

  • Thanks for information. Can you please elaborate the usage of T_IFS a bit more? What do you mean by powered up and powered down? And please also explain on which parameters SIG has calculated T_IFS and mandated it as 150us?

  • I suggest you read the Bluetooth Core Spec (Vol. 6 Part B) to learn more. You can download the spec from https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737. In Section 4.1, you will find the following text:

    The time interval between two consecutive packets on the same channel index is called the Inter Frame Space. It is defined as the time from the end of the last bit of the previous packet to the start of the first bit of the subsequent packet. The Inter Frame Space is designated “T_IFS” and shall be 150 µs.

    I don't know how this parameter was chosen. It was decided early on in the specification work, and as far as I can recall, there has been little discussion about it. I assume that it was chosen because this is a typical Rx-Tx turnaround time in low-cost radio implementations.

  • Akhil Kumar said:
    What do you mean by powered up and powered down?

    I forgot to answer this part. A radio chip contains various analog blocks. Some of these are only used while receiving, others are only used while transmitting, and some are used in both cases. For instance, there is a power amplifier (PA) to amplify the transmitted signal before it goes on the air, and another amplifier, the LNA (low-noise amplifier) used to amplify the weak signal coming from the antenna before further processing. These modules must be powered on and off, and that can take some microseconds. If the PA is still on while the receiver is running, for instance, this would cause excessive noise on the LNA input, blocking the receiver from seeing the signal from the antenna.

  • Thank you very much for this valuable information...

  • I think the parameter "T_IFS" restricted by  RX -to-TX turnaround time . when RX switch to TX,or TX switch to RX, Analog Device PLL(Phase locked  loop) need to lock again,it will need spend 100us at least. I have a question, if PLL lock time exceed "T_IFS"= 150us,maybe need 200us at least .So slave will be 200us later send Package after receive package from master,connection will lost or not?

    Thanks you!!

  • I have some basic question regarding IFS too.

    In Connection state,slave must send  package just 152us(T_IFS+2us) after it receive package from master,can time gap be Lengthened to 200us or 300us or more time?

  • The switch from Rx to Tx is done without any recalibration of the PLL and is always done in 150 us. The transmitted packet is always within the BLE requirements of 150 us +- 2 us.

  • Thank you very much for this valuable information...

  • Hello

    I have a question.

    The switch from Rx to Tx is done without any recalibration of the PLL ,i have different opinion.

    There is different frequency for LO Between  TX mode and RX mode . In Tx mode LO Frequency is equal to Tx Frequency. But in Rx mode  LO Frequency is equal to 8/7*TX frequency. So PLL must  recalibration . And it will spend more time,and 150us maybe not enough.

     

  • What is your source of this information? This is not true for CC2540/41; on these chips, the LO is the same for Rx and Tx. Other chips may have an implementation where the frequencies are as you state, but that is not relevant for CC2540/41.