2
\$\begingroup\$

In BLE, 3 of the 40 channels are used for advertising. If two devices are in the midst of a connection, the continuing communication hops about the other 37 channels with no "wasted" power.

But, let me consider two paired-but-unconnected devices. If I jam just the 3 advertising channels (with overwhelming noise), is it possible for them to connect? If so, at least one device must be broadcasting its ID periodically and I suppose Bluetooth standards could allow that device to sit on any quiet channel it finds and have the other device scan all 37 channels one-by-one.

Anyway (with or without jamming), what is the detailed procedure whereby two paired-but-unconnected devices first find each other?

For some background, I have a low-power application where I want the radio for one device to turn on once per day for the shortest possible time (to send one message and receive one message). I'd like to understand how much time the radio will need to stay on for this if I use Bluetooth standards. It helps me build up to understanding this with the two questions above.

\$\endgroup\$

1 Answer 1

0
\$\begingroup\$

Under standard BLE protocol, if the 3 advertising channels are jammed (by someone other than you, since you would be violating FCC regulations if you were the culprit), it is not possible for the devices to establish, or re-establish, a connection. Your idea of hunting for open non-advertising channels could be implemented by gaining low-level access to the radios, but it wouldn't meet the BLE standard.

With BLE, the peripheral device advertises in quick bursts, sequentially on the 3 reserved advertising channels, and listens briefly after each advertisement for a request from a central device on that same channel. That might be a request for more information, or a request to connect.

Once connected, the devices negotiate a "connection interval" that determines when, and on which channel, they plan to exchange data again, using one of the 37 non-advertising channels. When it's time for their "date" the central will transmit to the peripheral, and the peripheral can respond.

Because the device clocks aren't perfect, the devices have to start listening early, and keep listening later, than the exact planned time. That's why the BLE protocol specifies a maximum connection interval. If it's too long, the devices might miss each other because of drifts in their clocks.

The peripheral, if it has no new information, can skip the planned connection a few times, determined by the "maximum slave latency". This can save energy for the peripheral. But again, you're not going to get to a once-a-day schedule using this technique.

It isn't impossible to do what you want, you will just have to devise your own protocol layered on top of BLE. Use low-power, crystal-controlled clocks that are as precise as you can reasonably get. Then wake both devices once a day; the peripheral should advertise and the central should scan. The duration of this will be determined by how accurate your device clocks are. Once the connection is made, the devices go back to sleep with their clocks running. You'll also have to decide when to give up if the connection is missed, and what to do about it (cache data for later, etc).

\$\endgroup\$
1
  • \$\begingroup\$ Let me stick with no special protocol, so central is always listening (which is fine because only peripheral needs low power). Is it fair to say peripheral, after waking, advertises its presense on one advertising channel for 0.5ms and then listens for about 20ms, then repeats this on the next channel, cycling through the 3 channels until it gets a response? If central's scans stay on each channel for a much longer time, average radio time would then be a little more than 20ms (with occasional extremes of a little more than 80ms due to central changing channels in the middle of this). \$\endgroup\$
    – bobuhito
    Oct 24, 2020 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.