Our challenge, as ever is wakeup. Beaconing is something we don’t need to do all the time, but listening is. Sniffing the ether occasionally is fine, but it requires the transmitter to beacon for longer. I need a spreadsheet to get my head around this.
I am beginning to wonder if I have misunderstood the BLE documentation. It looks like scanning may be expensive, compared with maintaining a bonded connection.
I don’t have any idea how much power either process takes yet.
There is a limit to how many connections the system can simultaneously maintain, so that’s could be a difficult issue.
You can use BLE driver (the Master Emulator only support 1) that runs on S130, now you can have 3 but later you can have up to 8 peripherals simultaneously when BLE driver use S130 v2.0.
This is a very useful article describing all the little things you can do to minimize power
How to minimize current consumption for BLE application on nRF51822
Current measurement guide: Measuring current with nRF52832 Engineering B and S132 v2.0.0-7.alpha
I’m beginning to think that we need a lower-freqency radio to get the same range with a lower power budget.
The Friis equation demonstrates the superior propagation characteristics of a sub-GHz radio, showing that path loss at 2.4GHz is 8.5dB higher than at 900MHz. This translates into 2.67 time longer range for a 900MHz radio, since range approximately doubles with every 6dB increase in power. To match the range of a 900MHz radio, a 2.4GHz solution would need greater than 8.5dB additional power.
The MicroSemi ZL70250 looks more interesting.
To be an effective wake-up radio we need to write the MAC layer software so that it simply toggles a bit whenever it receives a packet containing it’s address. That could be a very simply bit of software indeed. If it could duty-cycle listening then it’s budget could be arbitrarily low, at the expense of a higher beacon budget.