[HN Gopher] Analysis of energy consumption of Bluetooth Low Ener...
___________________________________________________________________
Analysis of energy consumption of Bluetooth Low Energy versus
Bluetooth Classic
Author : Breadmaker
Score : 95 points
Date : 2022-08-05 18:13 UTC (4 hours ago)
(HTM) web link (hj.diva-portal.org)
(TXT) w3m dump (hj.diva-portal.org)
| keybuk wrote:
| 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.
| ChrisMarshallNY wrote:
| 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
| arcticbull wrote:
| 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.
| mafuyu wrote:
| 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.
| jononor wrote:
| The extended advertising support in BLE 5 helps there, does
| it not?
| ellisd wrote:
| 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?
| aaaaaaaaaaab wrote:
| Just use a wire?
| com2kid wrote:
| > 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.
| ellisd wrote:
| 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.
| jsjohnst wrote:
| 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.
| ellisd wrote:
| 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.
| jsjohnst wrote:
| > 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.
| qbasic_forever wrote:
| 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...
| ellisd wrote:
| 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!
| toxik wrote:
| The institution credited, Jonkoping University, is notable in
| Sweden for /not/ being a university and skirting the name issue
| by being named "Jonkoping 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.
| bhaney wrote:
| > 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.
| swamp40 wrote:
| 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._
| mika99 wrote:
| Thanks for sharing!
| kwyjibo123456 wrote:
| 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.
| [deleted]
| yunohn wrote:
| That's... odd? I would've assumed that LE was designed with both
| theory and practical testing - how could classic be better at
| everything?
| qbasic_forever wrote:
| 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.
| yjftsjthsd-h wrote:
| 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)
| eimrine wrote:
| Maybe classic is engineer's creature while LE is manager's one?
| keybuk wrote:
| 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
| randyrand wrote:
| 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!
| kramerger wrote:
| 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.
| szundi wrote:
| 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.
| swamp40 wrote:
| 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.
| Denvercoder9 wrote:
| Its important to note that this study has only tested one
| Bluetooth stack.
| rafaelturk wrote:
| tldr?
| PaulHoule wrote:
| 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.
| calvinmorrison wrote:
| 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.
| aaaaaaaaaaab wrote:
| The solution is an aux cable.
| fellerts wrote:
| 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.
| toast0 wrote:
| 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.
| PaulHoule wrote:
| 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.
| amq wrote:
| 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'.
___________________________________________________________________
(page generated 2022-08-05 23:00 UTC)