This is a question which comes from a programmers perspective (so might be SO, please migrate then) but with an EE background.

I am trying to programmatically reduce the bluetooth power consumption between a cellphone (Blackberry Z10 featuring probably a Texas Instruments WL1273L Wireless Module) and a smartwatch (Pebble probably featuring Texas Instruments CC2564).

Apple provides some best practices where they suggest (see last chapter) to "Disconnect from a Device When You No Longer Need It". But still BT would be enabled and draw power.

Now on the other hand, the connection phase seems quite power intensive, so the question arises if keeping a connection (without sending data) is better than disconnecting and reconnecting if data is available. are the underlying layers similar to this TCP scenario?

Is there a sweet spot depending on the rate of new data?

I am using regular BT, but how would BLE compare, is it worth porting (if possible).

Unfortunately i dont have the equipment to measure the power consumption.

Also, there is no lowlevel hardware access to optimize or high level access on the BT device (cant turn BT on or off), so the options are:

  • connect to device and keep connection open
  • connect to device, deliver data, disconnect, repeat

The delay of having to reconnect is accepted.

I do minimize the amount of discoveries so on reconnect i try to connect directly to the device. What other considerations could be taken?

  • 1
    \$\begingroup\$ Good question, I would also want to hear the answer from knowledgeable person, and it relates both to electronics (how BT HW works) and programming (driver and protocol). Briefly reading documents you link to I see there's a notification term used. I guess it is a kind of keep-alive packet, which keeps pseudo-connection between applications/ports. These packets take time, (maybe) CPU and bluetooth power, and as article suggests, if you do not need connection any more just stop notifications (and thus disconnect). \$\endgroup\$
    – Anonymous
    Jul 10, 2017 at 8:01
  • \$\begingroup\$ We would need to know the specific hardware to figure this out, I would think that the answer is to connect, deliver data, disconnect, and then poll every x ms to see if you need to transfer more data (my fitbit odometer), and connect when needed, but depending on how often the connection needs to be there, there will come a point where it is more beneficial to leave it open. (Bluetooth headphones) \$\endgroup\$
    – Joe S
    Jul 25, 2017 at 13:05
  • \$\begingroup\$ added what i think is used as BT hardware, not sure how this helps for the general approach though \$\endgroup\$
    – x29a
    Jul 26, 2017 at 17:44

3 Answers 3


I do not believe there is a simple answer because it depends on the hardware.

Let's assume that you have an IC that removes the complexity of the communications, such as a BroadComm BCM43012. These ICs already have software internally that turn off/on the radio and this abstracts the concerns of quiescent current draw of the analog from the interface. When you "connect", you actually have a bit of delay as the VCOs come up with the rest of the support circuits.

The assumption is that the IC can handle the power management better than the programmer, and this is generally true when combined with the OS level. Often, the OS is handling the power management of the wireless ICs if the IC itself is not.

  • \$\begingroup\$ Can you clarify your conclusion? You would say "connect once, let OS and drivers handle the rest"? \$\endgroup\$
    – x29a
    Jul 26, 2017 at 17:45
  • \$\begingroup\$ @x29a I should say that if the driver level programming is correct, let the OS take care of it. I believe that if you wanted to minimize power consumption, you would disconnect because the driver should put the device in deep sleep. \$\endgroup\$
    – b degnan
    Jul 27, 2017 at 1:58

Quick and dirty answer: It's totally incorrect to use classic bluetooth in this way at all. The answers to your connection strategies are irrelevant because using BLE would result in between a 10-20 fold power reduction for both host and device. So stop worrying about classic bluetooth connections and use BLE. That is correct answer.

Long, in depth answer including general overview of Bluetooth varieties and Bluetooth 2.1 power "saving":

It is important to understand the somewhat confusing topology of the bluetooth standard itself.

Bluetooth 4.0 is an umbrella specification that contains 3 completely different technologies. It is not an extension of earlier bluetooth versions, but rather a way to force devices to support multiple but totally unrelated wireless technologies at the same time if they want to be able to say they comply with BT 4.0.

  • Bluetooth 4.0 is, at the minimum, just the low energy protocol. In this instance, it called BLE or Bluetooth Low Energy. It has zero compatibility with any bluetooth device except for other BLE devices. This is because BLE is completely unrelated to other incarnations of bluetooth, and doesn't even use the same radio. It's a totally different technology, stack, protocol, RF solution, everything. The only thing it shares with other versions of bluetooth is the name.

  • The second technology contained in the BT 4.0 specification is Classic Bluetooth. This is just, well, classic legacy bluetooth. BT 2.1+EDR. If a device additionally supports this, then it can label itself as Bluetooth 4.0, since this implies that it is backwards compatible with earlier bluetooth devices, which it is. But not so much 'backwards' compatible. These so-called dual mode bluetooth devices have two stacks, two radios, though usually integrated on a single chip, one BLE radio and one legacy Bluetooth 2.1 radio. So most BT 4.0 devices are no different than 2.1 devices. Essentially, bluetooth proved to be kind of a crappy way to do stuff if you wanted low power, so we started from scratch and developed BLE.

  • Finally, if a device is labeled Bluetooth 4.0+HS, then it also supports bluetooth highspeed, which is just Wifi. Yes, you heard me right. It means it has an 802.11 radio in it, the only difference is bluetooth is used for the negotiation/connecting phase, so it's effectively just ad-hoc Wifi with bluetooth acting as a convenient method of automating the connection process. In phones that support this, usually the already-present wifi radio will be used for this, and BT4.0 HS is designed with this in mind, it generally will not have a dedicated 802.11 radio just for it. It's not special enough.

With that cleared up, you state you are using 'regular bt', or more correctly, Classic Bluetooth.

The Apple document you linked is irrelevant to you, as that documentation is all specific to Bluetooth Low Energy. It's part of apple's Core Bluetooth API, which is a Bluetooth Low Energy abstraction layer. Nothing in that section, nor the entire Core Bluetooth developer documentation, has anything to do with Classic Bluetooth, and Classic Bluetooth doesn't even work the same way as BLE. If you've been reading any of that under the assumption it had anything to do with the unrelated technology you're using, which unfortunately also is named Bluetooth, then you'll have a very flawed and incorrect idea of what is going on. It's already given you a totally incorrect idea on how Classic Bluetooth connections work, which I think is the source of a lot of your confusion.

So to be clear, that linked document is talking about a completely different and unrelated technology than what you're using. So those best practices have nothing to do with what you're doing, because you're using Classic Bluetooth.

The second link, referring to a BT device still drawing power, is about Classic Bluetooth and is relevant to your situation. It is NOT true for BLE, but for definitely true for Classic Bluetooth.

Yes, the radio consumes power whether anything is connected or not, and yes, that is pretty crappy. That's why we ditched that technology and started over from scratch when making BLE.

You then again link to an article about having low level access, but this is for a BLE chip. This article is, again, completely irrelevant and there is no 'low level access' that you're not getting. You're using Classic Bluetooth, it does not have any of those features and could not because it doesn't work like that nordic chip.

It really sounds like you're hugely and haphazardly conflating Classic Bluetooth and BLE (to no fault of your own, I blame the naming decisions of these technologies entirely for the confusion it causes people begin working with things named bluetooth), so I am not quite sure how to even properly address your question.

But here is my best shot. Let's start by giving you a correct understanding how how Classic Bluetooth connections work.

There several different phases:

  • Inquiry is what more familiarly known as discovery. It's very costly for both the host and the devices, which is why it tends to be a special mode where you make devices 'discoverable' or 'pairable'. It's that annoying thing we always have to do when we get a new bluetooth keyboard or the first time we get our phone to talk to our car stereo. The bluetooth host shouts on all its channels as loud as it can to get a roll call, and receives and saves specifics about each device. These specifics are, ahem, specifically the information needed to actually connected to them. So the inquiry phase isn't even the actual connection part. This is the host asking a device out on a date, but not the date itself.

  • Paging This is what is generally meant by connecting. This is going on the date. This, for example, is what happens when you manually click connect on a list of already known bluetooth devices on your phone/laptop/whatever. In this case, the bluetooth host attempts to connect to a device that it already knows everything it needs to know to do so (previously gathered by inquiry). This is also very costly power-wise for both the host and device. Additionally, this is a one way thing. A host can initiate a connection to a slave, but a slave that isn't connected can't connect automatically unless it is been bonded. When bonded, the host will periodically see if the device will respond, and if it does, it connects. However, again, this is still the host initiating the connection. And why the radio continuously draws power - because its constantly saying, "hey guys, anyone there?".

Once connected, this is not as big a deal as one might think. There is an active mode, which is the highest power, sending-and-receiving data mode, and there is also something called sniff mode, where the slave will mostly power down it's radio and only wake up periodically and briefly to let the host it's still there and to check if the host wants to talk to it (in which case it will upgrade to an active connection). Otherwise, it goes back t sleep until the next interval. This is what an active connection will revert to once it goes idle (no data being transmitted). This is usually automatic, and the cause of the potential maximum 100ms latency of Classic Bluetooth.

There are also a couple of other specific low power modes, but these must be issued by the master to a slave. It can command the slave device to hold, which means to sleep/power down its radio for a set amount of time, then wake back up. This is a one shot event.

A master can also park a device, which is effectively disconnecting it. The device will power down it's radio to a minimum state where it will do nothing and transmit nothing and only listen, barely. What it listens for is a signal from the master to wake up again.

It's important to see that all of these are controlled by the master/host. And even more importantly, these effect the power of the device/slave, not the host/master.

In Classic Bluetooth, you're always going to be consuming power and connecting and disconnecting from something will require more data and consume more power especially if you're just periodically sending some data. If you don't have access to any of these modes in software, then its likely that they are done automatically for you, but definitely do not connect and disconnect over and over. Connect once. The main additional power cost is determined by how much data is actually exchanged, and the handshaking and what not that goes on doing a full, cold-start connection to something is going to take a very, very long time in sniff mode for it to make sense to disconnect it (and thus need to reconnect again) if you don't need to.

Finally, in closing, Classic Bluetooth is meant as a wire replacement. It's meant to connect then stay that way, and always be there to exchange information. Which is why it sucks for battery life.

So if your application doesn't need what is essentially a constant, wired connection (only without the physical wires), then you should not be using Classic Bluetooth. If your device only needs to send data sporadically, and more importantly, without being polled by a master or host (it should be able to speak up rather than wait to be asked) then you should be using BLE. Your idea of connecting, sending data, then disconnecting is how BLE is designed to work and it is probably a BLE document that gave you that idea. This is not how classic bluetooth is designed to work, and most certainly not how you should use it.

So I guess the short answer to your question is that Classic Bluetooth is the wrong technology and you should not be using it at all. And you will not improve battery life by fooling around with connecting and disconnecting. The only way you're going to gain a meaningful improvement is by using the correct technology for your application, which is BLE.

As for battery life improvement, it will be on the order of...well..a magnitude. 10. Or probably more if you do it right. BLE is pretty great. BLE is what you use, the only time you don't is because you have no choice (you need to stream audio for example).

  • \$\begingroup\$ although i kinda feel bad of having asked (despite you claiming that the naming is responsible) this is an quite extensive answer sheding some light into the complicated world of BT and you seem confident and competent so i will accept it. The effort of porting to BTLE is quite big so i was looking for an easy way. I am conducting a real world test currently to simply measure battery life. I will update my question with the results once finished. \$\endgroup\$
    – x29a
    Jul 31, 2017 at 6:39

So i performed the test in the following way, first charge both devices (Blackberry Z10 and Pebble Classic) to 100% then start the software which automatically generates a notification every 10 minutes (which should result in an average of 6 notifications per hour). While running the test, i in parallel used a similar combination in production and measured a notification rate of around 3/h so my artificial rate is double as high as my real world scenario.

The app automatically writes down some statitistics every 15min, with the timestamp, the phones battery level and the sent notifications.

Once the phones battery level reached 15%, id note the time and amount of notifications and put the phone on a charger to see how long the battery of the watch lasts.

I then first ran the program in the "dont stay connected" mode where it disconnects after 15 seconds after sending an update to the watch if no new notification was generated (e.g. a lively chat that is going on).

After recharging both devices fully, i ran the "keep connected" testcase where the phone keeps the bluetooth connection to the watch as much as possible. Since both were beside each other, the only time the connection collapsed was when i had to dismiss all notifications on the watch because the watch can only display 100 notifications. So at least every 16h i had to manually dismiss all notifications. Since the watch has a bug it would then reboot resulting in a short disruption of the connection. The software on the phone would reestablish the connection on the next generated notification.

Those are the results:

  • no bt keep alive
    • Phone at 15% battery: 115h - 670 notifications
    • Watch battery empty: 205h - 1212 notifications
  • bt keep alive
    • Phone at 15% battery: 79h - 433 notifications
    • Watch battery empty: 168h - 924 notifications

So for my specific hardware scenario with the estimated and equally distributed notification amount, it does seem to be beneficial to disconnect the bluetooth connection and only reconnect on demand. The difference in battery consumption is significant (37h for the watch and 36h for the phone), so the overall system lasts about 1.5 days longer on "no bt keep alive".

Since it can be configured by the user, one can still switch the behavior if desired, but ill make the default to be "no bt keep alive". Also, im considering of making the die-off timeout a bit longer, maybe 1 minute, to really catch ongoing conversations and profit from both advantages.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.