BLE is designed essentially for asymmetric situations, where a peripheral advertises that it has some services to offer to a master who listens out, and decides if it wants to becomes a client. Master and peripheral have different functions. Master = client ; Peripheral = server
In the case of TS05, all devices were equivalent, and simply engaged in P2P exchanges where nobody was in charge. In the case of TS06, when leaning on BLE, it might seem like a good idea to make only the anchors masters. The power budget for a BLE master device is usually higher than a client, because it is required to listen out for advertisements from mobile devices. If the mobile devices do not have a well-known schedule for communication attempts, then the anchors have to listen out all of the time. (This isn’t quite true, but for this argument it serves.) We have determined that there is a solid possibility that anchors, which can be larger than tags, can run entirely on harvested energy.
A wearable device needs to be as small as possible. As such it has much less opportunity to harvest power, or the space to store it. So a mobile device by contrast would prefer to stay powered off until it chose to communicate. Then it could briefly communicate, and immediately shut down to save power.
This approach is sufficient if we can be sure that all encounters will involve at least one anchor. Plausibly we can arrange for two tags to discover each other, and communicate if they are within range, of an anchor which can act as some sort of go-between for two tags. In summary, every interaction between tags would have to happen in an anchor field. If we are unable to make energy-harvesting tags then this may be the only solution for now.
Sadly, the whole world is unlikely to be covered with anchors. There will be occasions where one tag needs to detect the presence or absence of another tag, and there is no anchor around to take care of introductions.
A real world example
You wear a device, and another is attached to your purse, wallet, medications, backpack, running shoes, car. This allows your system to detect patterns involving use of, or activities nearby some a proxy for some activity. Equally it’s useful to be able to detect encounters with other people. Any of these events may occur outside the coverage of an anchor field.
Solutions and strategy
There is an argument that says that anchors of some flavor will become more an more common, and it will become unlikely to be outside an anchor field. For example a BLE anchors can be embedded in a phone, or a nearby wifi node, or even a LoRa node. At long as it has a reliable constant power source this can be wrangled to work. The only requirement is that a tag can get a list of the other nearby tags from a third party anchor. This requires some clever thinking that I have not done yet.
The other approach is to have ultra-low power listening devices, aka Wake-up Radios (WURs). These listen at very low power (ideally nA, or pA) and simply raise an interrupt line on some more powerful radio if they receive a wake-up call. That’s how low power devices can know when an ULP master can find out when it is time to listen.
For the moment let’s asume that we have to listen all the time, and that listening is expensive. How do we minimize the time we have to listen, and minimize the number of advertising packets that get lost?
Beacon Theory
Choosing the right time, and duration to listen out for tags takes a bit to get your head around.
Advertising (aka Beacon) packets contain a fairly standard number of bits, and are essentially fixed size. So the there are three decisions to be made:
- How often odes the server/peripheral beacon?
- How often does the client/master listen?
- For what duration does it listen?
There are two things that we want to avoid: Sending advertising packets when nobody is listening for them – those are wasted; Sending more packets thanare needed to get the message across (Duplicates). More packets improves the probability that at least one is heard. More packets in the ether means more packet collisions, and lower reliability. It’s a probability thing.
Making the scan period too small means that we will never hear the whole packet.
So what’s the goldilocks size? After all this analysis, my answer is still “dunno”. To be sure that the listen period is long enough, it clearly has to be at least as long as the advertisement. But if it is the same length there is actually zero probability that they will line up. So the minimum listen size is 2 x beacon time. If beacons are transmitted continuously, then 2x assures that at least one packet will overlap.
Of course the there is always some probability that the packet gets lost en-route. Let’s call the probability that it gets through OK p. So the probability that it doesn’t get through is (1-p), and the probability that no packet in a sequence of n gets through is (1-p)^n. The challenge is to figure out that probability p in practice!
——————
I know I can make something that will consume ~6mA or less constantly, and as radios get better, the lifetimes get better. But we know that BLE devices can be made to run for a long time on uA budgets if the architecture allows it. For us, that means a big religious compromise, and adopting an asymetric solution.
The strategic decision is how devices discover each other. Out choice is whether to have all devices running the same strategy (true peers, that scan and beacon), or an asymmetric strategy where we have tags running a low-budget (beacon-when-needed) strategy, and anchors running a higher budget (scan and beacon) strategy that compensates for the tag never scanning, by offering some check-in service that allows (non listening) tags some service to discover each other when they check in with a beacon.
I really dislike having a more complicated asymmetric solution, but I can see that it offers the tags hugely better battery life – perhaps tens of uA spent mainly on the IMU, as opposed to several mA spent listening all the time. After all, a FitBit will run for a week!
After scratching my head for a while I realized that having GMT available doesn’t help with the “beacon-scan sync” problem, unless every device has the same easy access to sync, which, of course blows the power budget.
So if we have a radio that can listen at 1.9mA (MicroSemi), or one that can listen at 6mA(BLE) the difference in battery life is only x3 – assuming that we can theoretically implement the same scheme under both radios.
The reason I say that is that whatever the radio is, clocks still drift. You either have to listen all the time, or adopt a listen-occasionally, and beacon more often – a scheme that blows the budget again.
The really sad thing is that all this would have been obvious with enough prior book work, but it’s so hard for bears-of-little-brain to see the problem until their nose is stuck in the honey-jar.
So time for a forage along the lines of an asymmetric solution.
