Unusual Approach | Cypress Semiconductor
I have an idea for a PSOC BLE peripheral device connecting to a smartphone. The smartphone needs to know the Peripheral is available and working all the time. Some very infrequent (once per month) trigger event happens on the Peripheral and it needs to make the smartphone aware quickly (latency <2s). The app on the PSOC also needs to know when the smartphone has received the event (latency <2s).
I want maximum to squeeze every last drop of battery life on the peripheral so was considering that having a long term, open GATT connection running between the two devices might not be the best power saving strategy (this is just a hunch btw). Hence I have thought of several scenarios involving complex advertising strategies, something like:
1 Peripheral: Broadcast "I'm here" (Advertise Slow, undirected, non connectable).
2 Smartphone: observes "I'm here", performs some simple internal operation.
3 Peripheral: Some predetermined event happens to an external sensor and fires a GPIO isr.
4 Peripheral: StopAdvertising.
5 Peripheral: Change advertising data reflecting the "triggered" state.
6 Peripheral: Advertise Fast, connectable "triggered"
7 Smartphone: detects new advertisement "triggered"
8 Smartphone: connects to Peripheral
9 Smartphone: writes a characteristic
10 Peripheral: detects write operation
11 Peripheral: performs internal operation
12 Peripheral: disconnects smartphone
13 Peripheral: resets
This looks reasonable and I have already created a smartphone app which is continually scanning for advertisements from the peripheral. Surprisingly this constant filtered scanning has shown little impact on device battery (Nexus 5, Lollipop) so I am assuming it's been offloaded to the smartphone's BLE subsystem.
Areas of concern
Step 6 where I change from non-connectable to connectable advertising. Anyone got an example, seems it should be possible?
Step 8 I'm not too bothered about security but I suppose if I use a whitelist on the Peripheral then I wont have to implement a rogue client disconnect strategy. But the smartphone will no doubt use a random public address for privacy so I'll need some previous bonding stage to enable the resolving of client addresses for the whitelist. I seem to recall that IRK wont work with whitelist and that my PSOC app needs to do the address resolution itself, am I correct? The upside of this though is that the connection from the bonded smartphone could serve as a suitable "triggered" acknowledgement without the need to update a GATT characteristic.
Any comments welcome especially on areas of power consumption and my areas of concern.