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.

[Bill Siever]

Do both sides of the link have limited power budgets?

It might be worth doing some estimates on the energy usage if you were to flip the central/peripheral roles. You could use an initial connection event to exchange a signing key. The remote control could be a peripheral that only advertises briefly when a button is pressed. It could send a signed packet in the data portion of the advertising packet that includes the remote code and a sequence number to ensure it's not processed more than once. Of course, there wouldn't be any feedback path to ensure receipt (but in some applications the user closes the feedback loop anyway).

[RK]

This is increasingly a great idea and now the peripheral+central softdevice is becoming standard it's quite possible to make something which is both, a 'normal' peripheral for being connected to by smart centrals and a central to listen out for this kind of event from a simple device, like a remote.

You can get some kind of feedback, if you make the advertising scannable you'll get scanned and will receive the scan event report, when you get that, you at least know your advertisement was received and who received it.

I've been avoiding adding that complexity into my current design, and only just moved up to the S130/S132 anyway .. I think it's time for me to implement something like this, the current way I'm doing it does have noticeable lag sometimes.

[Bill Siever]

Ah --- excellent idea! I thought about trying to leverage the scan response somehow, but I hadn't thought about using it as an ACK. I tried to think of a good way to identify the optimal number of advertisement periods, but having an ACK makes eliminating unnecessary power consumption much easier. If you do some experiments please keep us posted on the energy utilization of this approach.

[Hung Bui]

@keith: I have the same question as Bill, do you have limited power budget on both sides ?

Also would the communication is only in one direction ( the remote sends command to the device) or it should be bidirectional (the remote reads data from the device ) ?