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
  • @keith: Next time, when you want to give more information, please use the comment section, not answer, or you can edit your question to add more info.

    As your required bidirectional communication, a connection is needed. You still can do connectionless by switching between advertiser and scanner, but I think it will bring more trouble.

    It would take less than 3ms to establish a connection and send the first data packet. But as RK mentioned, it depends on how fast you advertise and how frequently you scan. Since you have interrupt on only one side (when you pick up the remote, and/or press the button on the remote), you can't do advertising all the time or scanning all the time on the other side. You would need to balance the latency and the power consumption.

    And, yes, if you bond to the device, the Attribute table and the service context will be stored, and it would take a couple of packets before the link is encrypted and you are ready to read/write or receive notification. No re- service discovery needed. I would say from the time you receive the advertising packet to the time you send data it could be as low as ~50ms. If you don't need encryption, it could be even faster, considering the ATT table can be pre-stored on the client.

Reply
  • @keith: Next time, when you want to give more information, please use the comment section, not answer, or you can edit your question to add more info.

    As your required bidirectional communication, a connection is needed. You still can do connectionless by switching between advertiser and scanner, but I think it will bring more trouble.

    It would take less than 3ms to establish a connection and send the first data packet. But as RK mentioned, it depends on how fast you advertise and how frequently you scan. Since you have interrupt on only one side (when you pick up the remote, and/or press the button on the remote), you can't do advertising all the time or scanning all the time on the other side. You would need to balance the latency and the power consumption.

    And, yes, if you bond to the device, the Attribute table and the service context will be stored, and it would take a couple of packets before the link is encrypted and you are ready to read/write or receive notification. No re- service discovery needed. I would say from the time you receive the advertising packet to the time you send data it could be as low as ~50ms. If you don't need encryption, it could be even faster, considering the ATT table can be pre-stored on the client.

Children
No Data
Related