This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Absolute minimum discovery

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

Parents
  • 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).

Reply
  • 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).

Children
No Data
Related