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.

if ble always advertising, will be problem?

after last question about disconnect/reconnect, I got to know that ble device is always on advertising when in disconnect state.

my question is, will it be problem? 

problem 1,  when other host or phone search/scan, they will get information? and this will make it easier attacked?

problem 2, when there are many similar ble device near, when you take out phone and do a search, you will get many device found. 

problem 3, when many device together, will collide.

  • dsp999 said:
    always on advertising when in disconnect state.

    Not necessarily, it could be in deep sleep and wake up on key press or sensor interrupt. But the common implementation is to have it advertise on low duty cycle.

    dsp999 said:
    make it easier attacked?

    Might be, depend on what kind of attack you are referring to.

    dsp999 said:
    when there are many similar ble device near, when you take out phone and do a search, you will get many device found. 

    Correct. Typically, iPhone/iPad can easily present 20+ devices simultaneously (and almost instantly). This has been proven on multiple trade shows.

    dsp999 said:
    when many device together, will collide.

    Yes. However, Bluetooth low energy has a build in 0-10ms delay to the advertising interval to be able to handle that easier (example when 2 devices start to advertise the same instant).

  • There's another potential problem with always advertising - if the device needs to be used (or even just stored)  on aircraft where radio tx isn't allowed. It would be useful to have a code sample where the device just listens for an advert from the master every few seconds, then if it finds a master (and only if) it would advertise itself.

  • Hi Chris,

    That's fully possible. You can have it running as a Central and scan with a low duty cycle.When an advertisement is received, it switches role to peripheral and starts to advertise.

    Best Regards

    Joakim

  • Thanks, Joakim, that's good to know.

    I think it needs some careful timing to ensure that the advertisements from each end don't clash. With the device running as a Central, and waking maybe every ten seconds to listen/scan for just a few milliseconds (to conserve battery power), the advertisements it sees (from the smartphone etc) would need to be very frequent in order to 'catch' one. The smartphone would need to continually advertise, then listen for a minimal time, then if no advertisements are found immediately advertise again. That's why I was hoping that there was some existing code for this scenario.

  • Hi Chris,

    To guarantee discovery, make sure the Scan Window > Adv Interval + 10. If this is not done, it’s possible that it will take a very long time to discover. Especially if the Scan Interval is a multiple of the Adv Interval and ScanWind << AdvInt.

    Best Regards

    Joakim