The "LE" is more about behavior, rather than some power-saving tech. It affords low-energy-use behavior. Short bursts, ad hoc connections, small amounts of data, etc. If we make it behave like Classic, it will suck energy like Classic.
I like using BLE, more than Classic (BR/EDR). It's a bit pedantic, getting things set up, but that can be abstracted, fairly easily[0].
If we program for iOS/WatchOS/TVOS/iPadOS, we'll generally be using LE, as Core Bluetooth is designed around LE. Classic is there, but IOBluetooth is only meant for MacOS, and is a private API, on the other platforms.
LE is basically meant for short busts of control information, or small bits of data. Its encryption is pretty good. You can actually have a meaningful dialogue, just using the advertising information, so a connection is not always required (beacons use this).
I have heard that they will be adding some high data-rate stuff to LE, so we may be seeing true LE headphones, in the future.
This is exactly right from my experience in having worked on a few different BLE devices, one of which you've almost certainly used.
If you use it like classic bluetooth, you're going to have a bad time like classic bluetooth. Information in advertising packets (which can be as infrequent as a few seconds) is also used extensively in sensor applications which can last a few years on a coin cell battery.
If you live in the middle ground where you want to maintain connectivity, but sporadically send chunks of data on the order of a few to 100s of k, that's where it gets a bit tricky. BLE is still much better for power than classic in those scenarios, but the protocol isn't really intended for that type of bandwidth, and you might end up with a lot of custom stuff on top.
> so we may be seeing true LE headphones, in the future
LE Audio has been worked on for a long time, the last missing pieces have been finalized just about a month ago and the marketing push appears to be beginning around this time. From what I recall they expect the first LE Audio peripherals by the end of the year (but pessimistic me would say it's more likely the middle of next year). High-end phones with Bluetooth 5.2 and Android 13 should already support it.
BLE was designed as a super low bitrate intermittent protocol, and named with that application in mind. It was designed to spend 99% of its time "asleep".
Not too surprising it's similar power to Classic when doing similar things.
I think the main improvement in BLE was about security.
What does that have to do with energy usage? Well, after some initial setup BLE allows devices to wake up and send data without a lengthy and expensive cryptographic handshake.
Obviously this may not work as well if data is constantly being transmitted. This report tries to figure out approximately where that threshold is.
The institution credited, Jönköping University, is notable in Sweden for /not/ being a university and skirting the name issue by being named “Jönköping University” in Swedish as well. Make of that what you will but to me it seems like a con.
diva-portal.org is not a journal, it is simply a repository of all academic texts from Swedish institutions.
"Jönköping University (JU), formerly Högskolan i Jönköping, is a non-governmental Swedish university college located in the city Jönköping in Småland, Sweden."
This has changed apparently. I think SAAB Avionics does a lot of in that general area so there is probably quite a lot of high tech research that goes on there.
The difference between a university and a högskola in Sweden for anyone wondering is that they do research at a högskola, i.e. you can get a doctors degree there.
I think the difference between university and college in the US is very clear, it is just not widely known. A college can get you a bachelors degree, a university can confer a doctorate (I always assume masters degrees come along with university, but that is an assumption).
They mention the Power Profiler Kit 2 (PPK2) to measure power usage. I've been using it for a few months with microcontrollers and have found it very useful. The amount of precision it's capable of with high-frequency measurements is extraordinary, I was able to spot when the MCU was running various functions just from the power draw. It goes down to 200nA and can produce 100,000 samples/sec.
Alternatives like USB power meters[2] are still useful and can be cheap, but you don't get raw data from them and just have to read the value from the display. For comparison DigiKey has the PPK2 listed for $92.50.
The small packet size is what is constraining BLE in the energy consumption comparison. It really wasn't meant for continuously streaming music.
When advertising every few seconds, like an Apple AirTag does, the energy usage averages about 5uA. That certainly beats the heck out of Bluetooth Classic.
They just have different use cases. Eventually BLE will add a long packet size feature and win out. Between music and firmware uploading, there are lots of use cases nowadays. Nobody wants Bluetooth Classic, it's 20+ years old and uses a whole different stack.
It wasn't meant to stream audio, but it will. The LE Audio standard is already released, dev HW available and the upcoming Android 13 has support integrated.
The marketing push is going strong right now, especially for the broadcast variant that's branded Auracast
7.1 Conclusions
The purpose of this study was to research and investigate the potential existence of a breaking point where BLE becomes less efficient than BR/EDR in terms of energy consumption. The results from the conducted experiments show that BLE has overall worse energy consumption efficiency than BR/EDR and that there is no breaking point since BLE is shown to be worse.
On this topic: I'm very interested in streaming accelerometer data in real time from a wrist worn device to a body mounted LED controller. My goal is to modify the LEDs animations based on the hand position. Given the sensor bitrate and low latency required for this data, it would appears that BT Classic may be better solution than BLE. Beyond the power consumption needs, BLE connectionless broadcasting of the data seems easier to handle with than having to manage pairing two device. You could simply pick the strongest signal and be reasonable assured that it's your personally worn wrist device.
Where are you planning to use this, is it for a stage or concert? A lot of folks have found in those environments 2.4 ghz wireless (like bluetooth) is flakey and unreliable from all the interference of the audience's devices. I've read folks prefer stuff like 900mhz where almost no one has stuff using it in the area. Akiba and Freaklabs has done some great write-ups about his stage show work that are worth exploring: https://hackaday.com/2013/12/10/get-tangled-up-in-el-wire-wi...
Off stage, within the 2.4 ghz ocean: the audience. Your point is well taken that spectrum saturation will be an issue. Low range/power consumption, not centralization are the driving factors in the design. Thanks for the share!
Why use Bluetooth at all? Depending on the details, hiding a wire inside a sleeve should be doable. If you really want wireless, I’d suggest considering something like RFM69 / RFM95 type radios. You can easily find a wide variety of form factors, optionally with integrated Arduino compatible MCU, from Adafruit.
It's a really good point, a wire based sensor eliminates a dead battery and interference as failure points. The Wireless accelerometer feature should come after the basic animation concepts have been ironed out and tested. I really appreciate the reference to RMF* type radios - I had not come across them in my reading.
> I really appreciate the reference to RFM* type radios
My pleasure. It’s surprising to me how many makers / hobbyists who need wireless don’t know about them so I make it a point to bring it up any time I can. I’ve built dozens of fun projects using them and find them to work really well for my needs. There’s trade offs between the 69s and 95s, so be sure to read up on adafruit’s site to decide which works better for your needs.
> You could simply pick the strongest signal and be reasonable assured that it's your personally worn wrist device.
> Am I missing something?
Phone is in your pocket, wrist worn device is on other side of your body. Another device with unobstructed line of sight across the room may have a stronger signal strength.
I'm actively trying to avoid a phone, rather a dedicated LED controller likely containing an AVR or ESP32. A simple button based paring process to associate the wrist band with its personal controller is likely necessary to solve the RSSI issue you point out.
When I was a PhD student, we did similar measurements for LTE and WiFi for multipath TCP. These are non-trivial measurements due to lots of overlaying effects and I honestly speaking do not trust a BSc student to get this right.
Besides that I think the measurement scenario is unfair, as BTLE was designed for a different use case, i.e., always on and always able to overhear beacons. Comparing BT and BTLE for data transmission only is like measuring a race between a horse and a fish in the open sea.
This is about the newer LE 2M PHY, which was added for "replacing Classic" (which is 2-3M) use cases. It's not surprising that it's not as efficient as the more widely used 1M PHY.
> The experiments showed that when using BR/EDR’s 2 Mb/s, the practical throughput were on average 0.786 Mb/s. [...] Meanwhile, when using BLE’s 1M PHY, the average throughput were around 0.522 Mb/s and 0.938 Mb/s when using 2M PHY. The bit rate speed for the BR/EDR 1Mb/s mode were at an average of 0.104 Mb/s. Using these results, it shows that on average, the BR/EDR throughput speeds are faster than the BLE throughput speeds.
I'm probably misunderstanding what the author intended here, but this just seems wrong. 0.104Mb/s (BR/EDR 1 Mb/s mode) is not faster than 0.522Mb/s (BLE 1M mode), nor is 0.786Mb/s (BR/EDR 2 Mb/s mode) faster than 0.938Mb/s (BLE 2M mode). I can't see how you would reach the conclusion that BR/EDR is faster "on average" than BLE with those results unless you're also factoring in BR/EDR's 3 Mb/s mode in some way, even though there is no BLE equivalent to compare it to.
What's going to matter for audio streaming in an automotive (the case they are concerned about) is the energy consumption in the receiver, not the transmitter. They are measuring the second.
Who cares about power usage of the receiver in a car? It's got access to the 12v alternator/battery and as long as it turns off properly hen the car is off, radio power is going to be negligible compared to moving the vehicle, nevermind things like air conditioning, power steering, headlights, etc.
Otoh, the transmitter in your pocket might not be plugged in, so that's important.
Believe it or not I don't have a smartphone and find my life is perfectly meaningful w/o it (e.g. there is nothing convenient about using cellular streaming in my car if I have to drive a few miles from home for it to work.) so I was thinking about streaming from the car audio system to headphones and not the other way around.
But generally it is the smaller, more mobile device which is going to have battery problems, which is going to be the phone if you are streaming from a phone to your car.
This is killing my in my newest stereo, the bluetooth will sleep if the phone is silent for more than 1 second, like a breathy pause during a audiobook. Then it takes a half second to kick back in. I haven't found anyone with a solution yet.
For iPhones, there is a background noise generator built into the phone (in Accessibility settings, controllable from the Control Center). On Android, a similar solution likely exists (one that continues to play even if other apps are playing audio).
You would just need to set one of those up, quiet enough not to be too annoying, but loud enough so that the stereo doesn't think its silent.
Also, there are audiobook players (for Android, at least) that skip over silent sections of the audio track.
My LG OLED TV is connected via an AUX cable to a speaker, but still mutes its audio output after long-ish periods of silence. Cabled audio doesn’t help if the software sucks.
Classic isn't better at everything. This was just looking at the raw efficiency of sending as much data as fast as possible from device to device, something both classic and LE bluetooth can do. However classic cannot do quite a bit of what LE supports, for instance things like wireless multicast (i.e. air tag type scenarios) where one device broadcasts data for any other device around it. Classic is much more like a wireless serial port and requires devices to find and connect to it one at a time whereas LE doesn't have that strict requirement.
As other comments note, this appears to only examine power use under load and LE is meant to idle at extremely low power. So it's worth knowing but not super meaningful that LE isn't more power efficient when in use, because that wasn't the point. (Also this assumes that the conclusion is true in the general case, which is unknown since they didn't test many implementations and BT has painfully wide variation in implementations)
For the most part, Classic was designed by committee with many concessions to every corporate partner, retaining compatibility with their IrDA stacks, etc...
...while LE was designed by a few smart guys working together
The "LE" is more about behavior, rather than some power-saving tech. It affords low-energy-use behavior. Short bursts, ad hoc connections, small amounts of data, etc. If we make it behave like Classic, it will suck energy like Classic.
I like using BLE, more than Classic (BR/EDR). It's a bit pedantic, getting things set up, but that can be abstracted, fairly easily[0].
If we program for iOS/WatchOS/TVOS/iPadOS, we'll generally be using LE, as Core Bluetooth is designed around LE. Classic is there, but IOBluetooth is only meant for MacOS, and is a private API, on the other platforms.
LE is basically meant for short busts of control information, or small bits of data. Its encryption is pretty good. You can actually have a meaningful dialogue, just using the advertising information, so a connection is not always required (beacons use this).
I have heard that they will be adding some high data-rate stuff to LE, so we may be seeing true LE headphones, in the future.
[0] https://github.com/RiftValleySoftware/RVS_BlueThoth
This is exactly right from my experience in having worked on a few different BLE devices, one of which you've almost certainly used.
If you use it like classic bluetooth, you're going to have a bad time like classic bluetooth. Information in advertising packets (which can be as infrequent as a few seconds) is also used extensively in sensor applications which can last a few years on a coin cell battery.
If you live in the middle ground where you want to maintain connectivity, but sporadically send chunks of data on the order of a few to 100s of k, that's where it gets a bit tricky. BLE is still much better for power than classic in those scenarios, but the protocol isn't really intended for that type of bandwidth, and you might end up with a lot of custom stuff on top.
The extended advertising support in BLE 5 helps there, does it not?
If you're sending data via advertisements, yeah. Otherwise, you want Data Length Extension.
> so we may be seeing true LE headphones, in the future
LE Audio has been worked on for a long time, the last missing pieces have been finalized just about a month ago and the marketing push appears to be beginning around this time. From what I recall they expect the first LE Audio peripherals by the end of the year (but pessimistic me would say it's more likely the middle of next year). High-end phones with Bluetooth 5.2 and Android 13 should already support it.
BLE was designed as a super low bitrate intermittent protocol, and named with that application in mind. It was designed to spend 99% of its time "asleep".
Not too surprising it's similar power to Classic when doing similar things.
But also, a good study to actually measure it!
I think the main improvement in BLE was about security.
What does that have to do with energy usage? Well, after some initial setup BLE allows devices to wake up and send data without a lengthy and expensive cryptographic handshake.
Obviously this may not work as well if data is constantly being transmitted. This report tries to figure out approximately where that threshold is.
The institution credited, Jönköping University, is notable in Sweden for /not/ being a university and skirting the name issue by being named “Jönköping University” in Swedish as well. Make of that what you will but to me it seems like a con.
diva-portal.org is not a journal, it is simply a repository of all academic texts from Swedish institutions.
"Jönköping University (JU), formerly Högskolan i Jönköping, is a non-governmental Swedish university college located in the city Jönköping in Småland, Sweden."
https://en.wikipedia.org/wiki/J%C3%B6nk%C3%B6ping_University
This has changed apparently. I think SAAB Avionics does a lot of in that general area so there is probably quite a lot of high tech research that goes on there.
The difference between a university and a högskola in Sweden for anyone wondering is that they do research at a högskola, i.e. you can get a doctors degree there.
Right, it's marketing to attract foreign students I believe and bad taste IMHO.
But the difference in practice between a college and a university in the US is not clear cut even there.
In Sweden the distinction between "högskola" (college, basically) and university is not super clear either.
One needs to look at the specific faculty in question to know if it's any good. This goes for all schools.
I think the difference between university and college in the US is very clear, it is just not widely known. A college can get you a bachelors degree, a university can confer a doctorate (I always assume masters degrees come along with university, but that is an assumption).
That is not the difference between a college and a university as colleges absolutely confer doctorates. So I guess it’s not so well known, is it?
https://www.wm.edu/as/computerscience/graduate/phd-programs/...
https://www.brynmawr.edu/gsas/phd-programs
I’d love to read more about this. Could you recommend a summary/article?
They mention the Power Profiler Kit 2 (PPK2) to measure power usage. I've been using it for a few months with microcontrollers and have found it very useful. The amount of precision it's capable of with high-frequency measurements is extraordinary, I was able to spot when the MCU was running various functions just from the power draw. It goes down to 200nA and can produce 100,000 samples/sec.
Alternatives like USB power meters[2] are still useful and can be cheap, but you don't get raw data from them and just have to read the value from the display. For comparison DigiKey has the PPK2 listed for $92.50.
[1] https://www.nordicsemi.com/Products/Development-hardware/Pow...
[2] https://amazon.com/s?k=usb+power+meter
The small packet size is what is constraining BLE in the energy consumption comparison. It really wasn't meant for continuously streaming music.
When advertising every few seconds, like an Apple AirTag does, the energy usage averages about 5uA. That certainly beats the heck out of Bluetooth Classic.
They just have different use cases. Eventually BLE will add a long packet size feature and win out. Between music and firmware uploading, there are lots of use cases nowadays. Nobody wants Bluetooth Classic, it's 20+ years old and uses a whole different stack.
It wasn't meant to stream audio, but it will. The LE Audio standard is already released, dev HW available and the upcoming Android 13 has support integrated.
The marketing push is going strong right now, especially for the broadcast variant that's branded Auracast
They found usecases when classic is better.
BLE is very good for operating a sensor or a beacon for years on a coin cell. That’s why it’s so popular.
Also because of the easier api/interface to exchange data compared to the classic bluetooth.
Note that this is a bachelor thesis based on testing of a single product (Jody-W263). Probably shouldn't be quoted now as 'universal truth'.
Fair use:
7.1 Conclusions The purpose of this study was to research and investigate the potential existence of a breaking point where BLE becomes less efficient than BR/EDR in terms of energy consumption. The results from the conducted experiments show that BLE has overall worse energy consumption efficiency than BR/EDR and that there is no breaking point since BLE is shown to be worse.
In the scenario they tested, which is full throughput and low and behold, basic physics hasn't changed
On this topic: I'm very interested in streaming accelerometer data in real time from a wrist worn device to a body mounted LED controller. My goal is to modify the LEDs animations based on the hand position. Given the sensor bitrate and low latency required for this data, it would appears that BT Classic may be better solution than BLE. Beyond the power consumption needs, BLE connectionless broadcasting of the data seems easier to handle with than having to manage pairing two device. You could simply pick the strongest signal and be reasonable assured that it's your personally worn wrist device.
Am I missing something?
Where are you planning to use this, is it for a stage or concert? A lot of folks have found in those environments 2.4 ghz wireless (like bluetooth) is flakey and unreliable from all the interference of the audience's devices. I've read folks prefer stuff like 900mhz where almost no one has stuff using it in the area. Akiba and Freaklabs has done some great write-ups about his stage show work that are worth exploring: https://hackaday.com/2013/12/10/get-tangled-up-in-el-wire-wi...
Off stage, within the 2.4 ghz ocean: the audience. Your point is well taken that spectrum saturation will be an issue. Low range/power consumption, not centralization are the driving factors in the design. Thanks for the share!
Why use Bluetooth at all? Depending on the details, hiding a wire inside a sleeve should be doable. If you really want wireless, I’d suggest considering something like RFM69 / RFM95 type radios. You can easily find a wide variety of form factors, optionally with integrated Arduino compatible MCU, from Adafruit.
It's a really good point, a wire based sensor eliminates a dead battery and interference as failure points. The Wireless accelerometer feature should come after the basic animation concepts have been ironed out and tested. I really appreciate the reference to RMF* type radios - I had not come across them in my reading.
> I really appreciate the reference to RFM* type radios
My pleasure. It’s surprising to me how many makers / hobbyists who need wireless don’t know about them so I make it a point to bring it up any time I can. I’ve built dozens of fun projects using them and find them to work really well for my needs. There’s trade offs between the 69s and 95s, so be sure to read up on adafruit’s site to decide which works better for your needs.
> You could simply pick the strongest signal and be reasonable assured that it's your personally worn wrist device.
> Am I missing something?
Phone is in your pocket, wrist worn device is on other side of your body. Another device with unobstructed line of sight across the room may have a stronger signal strength.
I'm actively trying to avoid a phone, rather a dedicated LED controller likely containing an AVR or ESP32. A simple button based paring process to associate the wrist band with its personal controller is likely necessary to solve the RSSI issue you point out.
Just use a wire?
When I was a PhD student, we did similar measurements for LTE and WiFi for multipath TCP. These are non-trivial measurements due to lots of overlaying effects and I honestly speaking do not trust a BSc student to get this right.
Besides that I think the measurement scenario is unfair, as BTLE was designed for a different use case, i.e., always on and always able to overhear beacons. Comparing BT and BTLE for data transmission only is like measuring a race between a horse and a fish in the open sea.
This is about the newer LE 2M PHY, which was added for "replacing Classic" (which is 2-3M) use cases. It's not surprising that it's not as efficient as the more widely used 1M PHY.
Its important to note that this study has only tested one Bluetooth stack.
> The experiments showed that when using BR/EDR’s 2 Mb/s, the practical throughput were on average 0.786 Mb/s. [...] Meanwhile, when using BLE’s 1M PHY, the average throughput were around 0.522 Mb/s and 0.938 Mb/s when using 2M PHY. The bit rate speed for the BR/EDR 1Mb/s mode were at an average of 0.104 Mb/s. Using these results, it shows that on average, the BR/EDR throughput speeds are faster than the BLE throughput speeds.
I'm probably misunderstanding what the author intended here, but this just seems wrong. 0.104Mb/s (BR/EDR 1 Mb/s mode) is not faster than 0.522Mb/s (BLE 1M mode), nor is 0.786Mb/s (BR/EDR 2 Mb/s mode) faster than 0.938Mb/s (BLE 2M mode). I can't see how you would reach the conclusion that BR/EDR is faster "on average" than BLE with those results unless you're also factoring in BR/EDR's 3 Mb/s mode in some way, even though there is no BLE equivalent to compare it to.
What's going to matter for audio streaming in an automotive (the case they are concerned about) is the energy consumption in the receiver, not the transmitter. They are measuring the second.
Who cares about power usage of the receiver in a car? It's got access to the 12v alternator/battery and as long as it turns off properly hen the car is off, radio power is going to be negligible compared to moving the vehicle, nevermind things like air conditioning, power steering, headlights, etc.
Otoh, the transmitter in your pocket might not be plugged in, so that's important.
Actually I got it backwards.
Believe it or not I don't have a smartphone and find my life is perfectly meaningful w/o it (e.g. there is nothing convenient about using cellular streaming in my car if I have to drive a few miles from home for it to work.) so I was thinking about streaming from the car audio system to headphones and not the other way around.
But generally it is the smaller, more mobile device which is going to have battery problems, which is going to be the phone if you are streaming from a phone to your car.
This is killing my in my newest stereo, the bluetooth will sleep if the phone is silent for more than 1 second, like a breathy pause during a audiobook. Then it takes a half second to kick back in. I haven't found anyone with a solution yet.
For iPhones, there is a background noise generator built into the phone (in Accessibility settings, controllable from the Control Center). On Android, a similar solution likely exists (one that continues to play even if other apps are playing audio).
You would just need to set one of those up, quiet enough not to be too annoying, but loud enough so that the stereo doesn't think its silent.
Also, there are audiobook players (for Android, at least) that skip over silent sections of the audio track.
The solution is an aux cable.
My LG OLED TV is connected via an AUX cable to a speaker, but still mutes its audio output after long-ish periods of silence. Cabled audio doesn’t help if the software sucks.
my TV now flashes "mute" every like 10 seconds in an animation... and also asks me to setup the TV every time with its cloud services...
Thanks for sharing!
That’s… odd? I would’ve assumed that LE was designed with both theory and practical testing - how could classic be better at everything?
Classic isn't better at everything. This was just looking at the raw efficiency of sending as much data as fast as possible from device to device, something both classic and LE bluetooth can do. However classic cannot do quite a bit of what LE supports, for instance things like wireless multicast (i.e. air tag type scenarios) where one device broadcasts data for any other device around it. Classic is much more like a wireless serial port and requires devices to find and connect to it one at a time whereas LE doesn't have that strict requirement.
As other comments note, this appears to only examine power use under load and LE is meant to idle at extremely low power. So it's worth knowing but not super meaningful that LE isn't more power efficient when in use, because that wasn't the point. (Also this assumes that the conclusion is true in the general case, which is unknown since they didn't test many implementations and BT has painfully wide variation in implementations)
Maybe classic is engineer's creature while LE is manager's one?
For the most part, Classic was designed by committee with many concessions to every corporate partner, retaining compatibility with their IrDA stacks, etc...
...while LE was designed by a few smart guys working together
tldr?