detect hundreds of BLE broadcasters

Hello Daniel,

Yes, only three channels can be used for broadcast (channel 37, 38 and 39).

It is not very likely to detect more than 300 BLE broadcasters in one second. The minimum allowed advertisement interval for any BLE broadcaster is 100 ms which means that all the 300+ devices only has about 9 chances to be heard within 1 second and the observer will have limited time in RX due to startup times, code execution time, etc.

Hi Daniel,

You could have 100% duty cycle although it would be split up in three channels as you indicate. To guarantee discovery, a typical rule is to make sure sure the Scan Window > broadcast Interval + 10. Then you will need to add the amount of broadcasters to this and also assume they do not collide. I do not have a mathematical solution for this but feel free to share your thoughts if you go down that path.

To add to Eiriks comment, if the broadcasts are connectable, minimum interval is 20ms.

Best Regards

Joakim

Hi Joakim;

     Yes,  higher duty cycle of advertising event gives more chance for broadcasters  to be discovered. But it also means more RF conflicts becasue so many devices broadcast with a high fenquency on only three channels, right?

     If i tune the adv_interval to be 1000ms, there will be 33*3  time slots without any RF conflicts because an advertising event (RF transmit)will finish in 30ms(ch37 to ch39) according to BT Spec(P2224 of Core_V4.0 ).

     Then, if there are three scanner,each listens on fix channel (37,38,39), then maximum 99 broadcasters will be detected in one second  if no packet lost. correct me if anything wrong.

Hi Daniel,

The parameters you are referring to are the maximum values. In our implementation, the three channels will be burst within 3ms. I recommend you have much smaller broadcast interval to overcome potential collision in the air.

Best Regards

Joakim

Hi Joakim,

    Sorry, i am confused. I think smaller broadcast interval means higher duty cycle on RF TX and more collision in the air. Another reason  we can not select a smaller interval is that the device is coin cell powered which sustains 3 years.

   Another question, we  have done an experiment on CC2540 without external DC-DC for current consumption measurement in broadcast mode. The software project is SimpleBLEBroadcaster on sdk1.4 with 1s adv_interval and 10Bytes payload. The average current is ~38uA on 0dbm Tx. Is this right according to the datasheet?

daniel su said:

   Another question, we  have done an experiment on CC2540 without external DC-DC for current consumption measurement in broadcast mode. The software project is SimpleBLEBroadcaster on sdk1.4 with 1s adv_interval and 10Bytes payload. The average current is ~38uA on 0dbm Tx. Is this right according to the datasheet?

That sounds reasonable, you can reduce the current further by using non-connectable advertisements instead: 

// Use non-connectable advertisements

uint8 advType = GAP_ADTYPE_ADV_NONCONN_IND; 

GAPRole_SetParameter( GAPROLE_ADV_EVENT_TYPE, sizeof( uint8 ), &advType );

Hi Joakim,

    Yes, i use the Non-connectable Undirected Event type without Rx activities on RF to save power.