Absolute minimum discovery

[keith v]

Hi new to Bluetooth, but familiar with Radios and embedded devices

I have 2 devices that only connect to each other. in the interest of extreme battery conservation I need to reduce discovery to a minimum.

Device one is a remote, the central Device two is the peripheral that the remote controls. It will have attributes that the remote will set It will have attributes that the remote will read The attributes will never change except via a firmware upgrade, if they do it's OK if the remote doesn't work with the old versions

The first time pairing can be longer as it should only happen once.

BUT, once paired and Bonded, I need to be able to connect and send a attribute from the remote to the peripheral as fast as possible. I'd like to be able to do this in reaction to a button press on the remote.

1. The remote is sleeping and not connected ( but is bonded ?)
2. User presses a button
3. device wakes up, connects, sends message and returns to sleep

I'm hoping I can just use the UUID since I'm bonded? Can I just wait for an advertising packet and send the button press in the ack response?

TIA Keith

[RK]

Yes you can use the UUID if you are bonded and you've checked the service changed characteristic to ensure the service hasn't changed whilst you were disconnected. But you still have to connect, there's no 'ACK response' to an advertisement you can do anything with, you have to go through the connection procedure. If the characteristic you want to write requires security, you have to encrypt the link too (a signed write would be faster but I don't recall ever seeing one in the Nordic API anywhere).

I'm just working on something similar, a remote, I'm been messing about with the idea of putting a cheap(ish) accelerometer with low current and interrupt-on-motion into the remote so it starts pairing the moment you pick it up and by the time you press the button, it's ready.

[RK]

Security is up to you, that's a few more packets exchanged. If you determine that just whitelisting a resolvable private address is good enough, you can skip that bit. Connection is something like 6 packets, it can be quick. Your limiting factor is how quickly the central finds the peripheral, so if you are the central and want to connect quickly, you need to listen with the minimum time interval to your (also power constrained) peripheral which would be advertising as infrequently as possible.

Under a second is quite practical, I'm under a second from button press to working, you notice the lag. I do have the accelerometer option as my remote mostly sits on a table so I can get a head start on the whole thing. I'm just waiting for my mCube board to show up, it promises me 1uA in sniff mode which is insane low power.