0
\$\begingroup\$

In a BTLE master/slave connection, the master and slave devices synchronize their frequency hopping. Along with the connection parameters (like interval, slave latency, supervision timeout) this allows the master and slave to sleep between connection/transfer events.

With Beacons that advertise (and a phone that scans) it appears that no timing coordination can be accomplished. Basically the beacon advertises at some configurable rate and duration, while the phone listens for an independently configurable duty cycle and duration.

Certainly without establishing a connection the advertiser and scanner can not closely synchronize, but it would seem possible. For an advertiser to broadcast its payload as well as its advertisement settings, and then for the scanner to roughly synchronize its sleep/listen timing to those settings.

Obviously if the phone wants to discover other BTLE devices it would have to scan in the standard manner. But for catching subsequent advertisements of these type of previously heard beacons, the receive window seems like it could be much smaller (even with the wide PPM clock tolerances).

Can this already be achieved some way that I am not aware of? What am I missing?

\$\endgroup\$
3
  • \$\begingroup\$ We just had a question on this. Key point is there are only 3 channels for advertising, so it's a lot easier to catch the other end in the act of sending. \$\endgroup\$
    – Chris Stratton
    Jul 27, 2017 at 2:40
  • \$\begingroup\$ It's still very indeterminate process for catching the advertiser unless you are listening all the time. Scanning on 3 channels certainly is better than what BT classic was, but even with just 3 I cannot see how you could build a lower power and low latency advertisement -> scanning system. By low latency I mean that the scanner is able to see the advertiser in one second or less. To do that, you either need to advertise a ton, scan a lot, or some combination of both. \$\endgroup\$
    – Funkyeah
    Jul 28, 2017 at 15:42
  • \$\begingroup\$ You do need to advertise fairly frequently probably 3 times per second absolute minimum, probably more like 10 times if you want fast detection, or possible even more. There's also a difference between a phone that is asleep scanning for a second or two at large intervals, vs. a phone that has a foreground app wanting to see what is out there and so scanning consistently. Scanning BTLE probably doesn't cost that much power compared to having a phone's processor running and screen on in the active case. In the passive, it could be done with little of the system running or running slowly. \$\endgroup\$
    – Chris Stratton
    Jul 28, 2017 at 16:41

2 Answers 2

Reset to default
1
\$\begingroup\$

BLE advertising happens on only 3 of the 40 channels, so the search and sequential send are much more likely to meet.

Although the three advertising channels are sequentially numbered, their frequencies span the band, and are chosen with some regard to WiFi frequencies, with the hope that interference to all of them will be less common.

\$\endgroup\$
1
  • \$\begingroup\$ I agree that this is true. \$\endgroup\$
    – Funkyeah
    Jul 28, 2017 at 15:50
1
\$\begingroup\$

Seems i need more rep to just add this as a comment, so please don't take this as a full answer. I've had a very similar issue recently when i was designing a ULP BTLE monitor. For love nor money i couldn't find any sure-fire way of waking both the master + slave up for the sensor to advertise it's new value and for the master to receive it before they both went back to sleep within the same second even (transmitting once a minute). Because i needed this thing up and running fast i resigned myself to just having the master always listening and having the slave merely waking up to read it's analog input and to broadcast that within it's advertisement packet to save time on connecting etc. Without an external crystal, timing seems to be a big issue. I've been logging the timestamps of every transmission from the slave for the last week now and have seen it vary from 58 seconds to 64 seconds. There's a couple of things i can suggest, which i'm going to be trying myself for my own design;

Investigate how much power it takes to have external crystals for much more accurate timing (not sure how hopeful this is, even clocking at 32khz or something). To ensure we don't have compound timing differences, reset an internal timer in the master every time the slave transmits, and sleep for the set interval. If this method seems close, i'll be adding 2 AAAs rather than a coin-cell for the master and wake it up for 6 seconds every minute to ensure i catch each transmission from the slave.

\$\endgroup\$
1
  • \$\begingroup\$ The addition power consumption from the crystal should not be too bad. I know I've seen plenty of datasheets for Bluetooth and Zigbee type modules that describe the power differences between sleep with primary crystal on, vs sleep with 32KHz, vs deep sleep with pin interrupt. I am very surprised you had the first issue. Isn't that a big part of the value of establishing a master slave connection? They are supposed to coordinate their sleep wake cycles for periodic data transfer in minute scale timeframes. \$\endgroup\$
    – Funkyeah
    Jul 28, 2017 at 15:49

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.