Bluetooth 5 Now Available
bluetooth.com
bluetooth.com
For instance getting on the BART being an enclosed space? I never have an issue. All of the headphones I've tested stay connected the entire time without issue. The SECOND I walk out of the station, even in the city, every pair of headphones I've tried work most of the time but typically cut out once every 30 seconds or so. But it's crazy inconsistent because I managed to walk to my office, once, the entire way without it disconnecting.
Seeing as bluetooth 5 helps with range I'm hope I can finally using it to keep my phone in my side pocket and actually listen to my headphones, uninterrupted.
When you're indoors, you don't need to get bluetooth through your body. You're getting reflections off of nearby walls and ceilings which allow your bluetooth devices to communicate across your body, but without going through your body.
When you're outdoors, you no longer enjoy the benefit of reflected RF, and the design of the phone and the headset antennas needs to be very good, so the RF can make it through your body.
It is a hard problem, but a lot of headset manufacturers do achieve it. I'm surprised you still haven't found one that's acceptable. Of course, it's body dependent. Petite women will have less issues then large men, as the RF just has less water to travel through with them.
Today's bluetooth is limited to 4dBm max transmit power for class 2. Bluetooth 5 will be 20dBm, which is a lot more power. This is, actually, the same power that class 1 bluetooth devices now have, so I'm unsure why they brag about the higher power of bluetooth 5, but to be sure, most bluetooth devices now are not class 1.
The higher power will make even bad antenna engineers be able to get bluetooth through your body, but more importantly, you'll enjoy larger range when you are at the gym or in your home. Also, if you worry about RF effects on the human body, your worry can increase now as well!
But thanks for the explanation. This is good to know. I'll plan my walk to and from work through alleys instead of open parks. Because thinking back, it always works in alleys.
This is one of those moments when I wonder if most of the things I have learned in HN are bullshit, I'm usually struck with awe at the sapience of the HN hivemind too, but in times like this...
[1]https://en.wikipedia.org/wiki/List_of_common_misconceptions#...
Engineers juggle multiple constraints, cost, size, power, and efficacy, and 2.4 GHZ choice was the result of the size of the magnetron that would be cost effective and physically fit into the oven. But it did, of course, have to be within the range of frequencies best absorbed by water, which 2.4GHz is, and which is why it's difficult to get bluetooth through your body.
https://en.wikipedia.org/wiki/Electromagnetic_absorption_by_...
The parent comment is exactly the kind of comment I expected and hoped for!
This is the most diplomatic way to say "lose some weight" I have ever heard.
I use them almost every day on my way to and from work (roughly an hour each way) and I can count the number of interference issues I've had on one hand, and definitely not every 30 seconds. This is with an iPhone 7 and iPad Pro 9.7".
They're not cheap, but I'd highly recommend them.
The only issue I have is when I'm near high voltage transfer lines. Like near train stops for example.
I bought some PlugPhones on KickStarter, and the connection issues drive me up the wall.
I suggest giving them a try. Phone in pocket has never been a problem for me, regardless of where I am at the time. The battery even survives a 4h+ marathon.
This has been my hypothesis, considering the disruption patterns I've noticed.
At home, well removed from other possible bluetooth sources, I rarely experience signal cut-out, or choppy reception.
When I move into high traffic areas, the amount of signal loss skyrockets. The worst areas are areas with lots of cars in motion.
My hunch, is that noise, destructive interference, and fortuitous signals result in dropped packets. And cars especially, tend to broadcast stronger signals that outshine an handset/headphone channel, cause both ends of the connection to drop packets.
This is just based on observation. In crowded train stations and near busy roadways my headphones act like shit. I get the feeling it's the old "poorly shielded blender appliance ruins the t.v. reception" business, except the interference drops out in the same way progressive scan HDMI monitors glitch up without shielding.
I have no proof that this is the case though.
https://news.ycombinator.com/item?id=13128401
hint: both are possible, simultaneously. one does not contradict the other. each one is a different concern, with its own merits.
Also, it doesn't help that everything in Bluetooth until BLE (Low Energy) arrived was pretty bad. BLE changed everything and turned Bluetooth around, but BLE doesn't do audio.
There is lots of confusion in the naming, Bluetooth 4.0 incorporated BLE, and later they decided to just call the whole thing Bluetooth, even though it's now a set of two entirely different protocols, not even radio-compatible.
Bluetooth 1.0 uses GFSK at 1 Msym/s, just like BLE / Bluetooth 4.0. So it's the same r/f modulation protocol (it's the higher layers that are incompatible.) Is it the actual GFSK parameters, eg. frequency shifts, that are different?
I know that Bluetooth 2.0 and 3.0 use different r/f modulation (π/4-QPSK and 8DPSK at 1 Msym/s), but why do people say Bluetooth 4.0 is so different when it seems to be the same as Bluetooth 1.0?
Now that I write it out, I see that frequency hopping would count as a "higher layer," but I think it's still managed in hardware, which could be why there are many BLE-only chips. It's possible the GFSK parameters are also different, and of course the layers above the link manager are vastly different (for some reason).
https://en.wikipedia.org/wiki/Bluetooth_low_energy#Technical...
Windows 10 also seems monumentally bad at Bluetooth, and I've tried with a few different Bluetooth dongles with different chipsets. I've had the best luck with the one from Pluggable, which IIRC uses a Cambridge Silicon radio / driver stack. I really wish we had wireless serial instead of wireless USB, as most of the time, that's basically what I want, and stuff like the ESP, nRF24*, or even RFM69 does this quite well. I honestly wish they'd do a 433/900mhz standard for wireless HID only, and another for audio only.
OTOH, I have a Logitech Megaboom which always works amazingly well. Whoever did the Bluetooth radio on that...A+ .
Haha. That reminds me of the classic, "Simply goto to http://example.com/drivers to download the network drivers for your new desktop".
Yeah, watch out with those, because a wireless wire is about accurate security wise too. Typically the proprietary dongles have very little security wise.
Me and a friend were at a regional lan party, and he had one of those keyboard. As we soon learned someone else in the locale also had one, because he would ever so often get random inputs on screen...
What I would like with the Logitech keyboards and mice is an option to plug in with micro USB or to go Bluetooth, i.e. wired but detachable if your Bluetooth happens to be reliable that day.
There already is a micro USB socket for power on the 810 keyboard, sadly they don't do a mouse that charges on microUSB and can also work on micro USB. Regardless, there is not a lot that really needs to be added on the hardware side to implement such a feature.
If such goodies existed then I would not need that normal keyboard/mouse that I have in my draw for the unpaired situation you describe. I could also do things such as BIOS UEFI settings without having to reach for the emergency input devices.
Despite deficiencies, I find the 810 to be the best keyboard going, I carry mine around instead of a laptop, it works great with work PC, my phone and my home PC.
If most bluetooth adapters had that, I could use it to navigate the BIOS, etc.
FCC certs of a custom radio used with a bluetooth chip with a binary blob for firmware is the most painful thing I've ever done in my career...I think.
Water is a big one, which I think is one reason that having my phone in my back pocket almost always results in a dropped connection to my headphones over the course of working outside for a few hours, compared to my side or front jacket pocket. Too much water in our tissues.
First, we're bad at naming things. Is it BLE? Bluetooth Smart? BTLE? Bluetooth 4.0, or Bluetooth 4 Low Energy? And what does this have to do with ANT+? This doesn't seem to be a big problem, but it's a sign of deeper problems with the spec. In the long run it makes it very difficult for developers to implement.
Bluetooth 2.0 is radically different from BTLE. In 2.0, you had one device which acts like a microphone, and another device which acts like a speaker. This was like getting two people to dance together, it takes a lot of practice to get the joined movements right. If one person stumbles, it all goes down like dominoes.
BTLE on the other hand, acts like a (more familiar) client server model. You come up to the bank teller, and have a limited set of operations you can preform (withdraw/deposit money, open/close account). Here's the catch though... the teller is only open for 10 seconds during a 24 hour day, and moves throughout the city. You have to arrive at just the right time, or you have to wait until tomorrow. (This was done for battery saving.) The throughput is also MUCH slower than 2.0, which makes applications like audio out of the question for now.
There's also a lot of bureaucratic hype surrounding it. If you look at the release from the BT SIG, it seems very much similar to Java's claim that it runs on a bajillion devices. All in all, BTLE seems to be a solution in search of an IoT related problem, much like Java.
So in short, the reason I think it sucks is because it's a very complicated protocol with poor and confusing naming conventions. It sure doesn't help that it keeps getting re-invented! (Although BT5 seems to just be add-ons, finally!) Implementers (both on the HW side and the mobile/desktop side) have a difficult time figuring out how to do things correctly, much less why they need to be done. Things are getting better, but until the next "killer BTLE" application comes out, it's just heart rate monitors and useless iBeacons.
Here is another discussion of Bluetooth vs. Ant as written by someone in my industry (fitness): http://keithhack.blogspot.fr/2016/11/why-hasnt-ant-been-crus...
A reason for the complexity was that the BT 1.0 profiles often leveraged existing technology, for example:
- RFCOMM was a way of sending arbitrary serial data, reusing RS232 comms which were very common.
- OBEX was a way of sending data which was previously sent over IrDA
- The "LAN access profile" basically said "use RFCOMM to do PPP over a serial link like you do with a modem"
If you tried to implement any of these from scratch then not only do you have to implement the BT part, you also have to implement the technologies that BT reused.
If you look at the initial SIG members, Nokia and Ericsson took care of the initial phone developments. Intel, IBM, Microsoft and Toshiba represented the PC side of things. I was working for 3Com at the time and we were interested in it as a short range network technology. 3Com developed a network device conforming to the "LAN access profile" but it was never released. 3Com also owned Palm and they were interested in incorporating BT with the hand held devices.
It is interesting to compare BT to Wireless Ethernet (IEEE 802.11) world. The IEEE Ethernet (802.3) specifications are pretty much only concerned with getting data packets from A to B at layers 0 through 2. At layer 3 and above they don't care if those packets are IPv4, IPv6 or some other protocol like IPX.
Bluetooth tried to define everything from the the RF communications all the way up to the application layer. The specification mentions how to the PIN code request should be presented to the user when authorizing a new connection. It also mentions which audio codecs should be supported for streaming audio. The BT profiles also tried to define how to transfer files, business cards or print documents.
These detailed application layer specifications simply don't exist in something like Ethernet. There might be an argument that BT tried to over specify things but it was attempting to give a level of interoperability which we still struggle to achieve over other networks.
Tends to be hard to implement a specification without any implementation to test it out together with it, but those who do work out, should be looked into why so we all can learn from it.
It is a gigantic pile of mess and it never worked well enough for the majority of users.
Talking about design by committees, even the Wifi 802.11 has much improved.
I really wish Apple could design new one and force market adoption with the spec opened.
tl;dr when someone decided to use a 4 dBm transceiver, they (should have) made a conscious choice about it and would have verified that it's enough.
Quite plainly, if the connection drops when it shouldn't, it's either bad software or bad design.
Bad software is either the Bluetooth stack (especially in legacy Bluetooth devices; newer stacks tend to fare better) or the firmware that talks to the Bluetooth stack (if it's BLE, this is the safer bet).
Bad design on the hardware level is less excusable than it would seem, because a Bluetooth device is not exactly a long-haul wireless link that has to work during the mother of all thunderstorms. There's a wealth of information and modeling tools that help you with this stuff, too. Bad antenna design, bad filtering, bad casing are all common culprits, but I've seen a lot of electronic engineers who wouldn't call themselves RF engineers get it right by just following common sense and doing the math.
Sometimes (but even less often), it's not a design problem, it's a manufacturing problem (e.g. PCB antennas that get damaged or don't get etched right. But this is pretty rare.
Certainly, the operating environment plays a role, but that's why you consider it while you're designing the whole gizmo. You don't (or shouldn't) get to shrug and say hey, it's not my fault we're basically walking cucumbers.
So if a pair of super high-end Bose speakers and a super trendy iPhone keep dropping connection while they're within range, not inside and, respectively, outside a Farady cage or whatever, the reason isn't the black magic that RF design is, it's Bose's and Apple's profit margin.
Edit: I do concur with the other fellow who posted here, Bluetooth really is complex and the band it operates in isn't exactly a charm to work with, but frankly, neither of these reasons account for the huge range of devices that are simply badly designed and/or run bad software. There are a lot of Bluetooth devices that work just fine, a lot of other protocols that operate in the 2.4 GHz band and work just fine, a lot of other protocols that operate in similarly noisy bands and work just fine and a lot of protocols that are more complex and work just fine.
When those where in use, it would basically block all other traffic for the duration.
I noticed this back in the day when i really pushed my bluetooth usage.
My setup was a SonyEricsson featurephone, a Nokia N800, some Jabra headphones, and a white box folding keyboard.
As long as i used the "LAN" connection between the N800 and the phone to get online, it all worked fine. But switch it to PPP and the music would stutter whenever there was network activity.
SPP (serial port) on the other hand has never worked reliably for me. I mean, I have seen it work. I just never take it as granted that it will work, and thus far have not been disappointed.
This because while i have had problem on urban streets with a device in my hand and one in my ear, i have observed rurally living relatives that can walk around their whole house with the phone sitting in some corner and not suffering a connection outage.
Bluetooth frequencies are absorbed by water (and your body is water)
4x the range.
8x the capacity "to send messages"
Not using the x.x versioning anymore. Just Bluetooth 5 and the next will be 6.
Also, apprently, there's 30.000 companies in the 'Bluetooth Special Interests Group' ?
[Thanks Krasin, gerardnll for correcting me]
But lag and dropouts is definitely my same concern with Bluetooth as well..
That said, it's still my preference if only because it's a standard - but it's getting damn hard to find decent Bluetooth mice now
Bluetooth can already do 100 ft... in very good conditions and with the rights devices and drivers.
Although, obstacle/wall penetration is probably still fairly poor.
The range is really the limiting factor in IoT uses IMO...
OTOH my Sony bluetooth speaker has stutters when I'm too far away in a 1-br apartment, so who knows.
Also, there will continue to be minor spec revisions (5.1, 5.2, etc). The "Bluetooth 5" terminology is for marketing and PR, to simplify the message. They don't want to confuse the general public with spec revisions.
I'd say its about 13 years too late to start worrying about that
You need to pay to join the SIG to put the logo on your device (and to advertise support). So the vast majority of those "members" are just people who paid for that.
Same applies to USB and HDMI.
2x Speed 4x Range 8x Data
https://www.bluetooth.com/specifications/bluetooth-core-spec...
edit: Here's what I'm referring to, bluetooth 4 LE mode is vulnerable to certain attacks: https://lacklustre.net/bluetooth/Ryan_Bluetooth_Low_Energy_U...
[1] The paper's conclusion summarizes very nicely, though they write it formally and a little confusingly: the thing is utterly broken. They can read contents, even if they key exchange was not observed/captured, and they can inject traffic. Basically it's obfuscated plain text.
I've always loved bluetooth, the concept of P2P file exchange got me through high school[1] to think about all the levels of tech involved in making your music shared with someone else's phone, but very let down by the documentation and implementation aspect.
As a curious hacker who would like to decentralize his life, I've always wanted to start programming stuff over Bluetooth for any task (remove dependency on internet for purely-local services). But when I tried actually doing so, I was met with an incredibly complex ecosystem I couldn't find RFCs for (or Russian equivalent), with only Bluez as partial reference [2].
I got the impression that if you're not some deep pocketed company or are doing something with phones (preferably with IoT as key buzzword), you're not welcome to the Bluetooth(®) club.
[1] My first bluetooth headset, a Jabra BT620s, bought for 30€ online, is still functional (if a little beaten) after 14 years, delivering about 6 hours of music streaming before recharge. I had to use earbuds recently for a project, and got myself really crossed with the wires thing. How pampered I have been !
[2] At the time I was interested in using BTLE with a linux laptop that clearly supported it, and a flagship Nexus 5. I gave up when I realised at the time, Bluez had only command line tools to access the Low Energy stuff, and some guy had to reverse-engineer the binaries to access some level of API. I really hope this changed/changes.
Reading the code here is a good second step. https://github.com/sandeepmistry/noble
After you've gone through those, the bluetooth spec is useful for specific questions.
My Sennheiser Momentum wireless headphones seem to be running into this issue. It doesn't happen all the time, but when it does I notice it happens when the traffic lights switch (e.g green to red). There must be some kind of signal interfering with bluetooth that's emitted at that point, though I can't understand why since all traffic lights should be wired, to my knowledge.
For reference this is in Berlin, Germany. Perhaps it's something to do with the traffic tech they use in Germany.
Plenty of traffic light systems in the UK are wireless - saves digging up bits of road, you just need power. I don't know about Germany.
Opus is low enough bitrate that it could even theoretically be used over BLE (ignoring latency problems), while still wiping the floor with SBC.
Regardless of whether BLE transport is possible, it depresses me that Opus support still hasn't been added to the A2DP.
I've been wanting an Opus powered headset too, for years. Maybe someone can make a non-A2DP opus receiver and some type of virtual audio device in PC and Android?
Bluetooth has also optionally supported device-side AAC and MP3 encoding (which Apple now supports, after 10+ years of being in this game, on exactly one chipset: theirs, the W1, via iTunes only, or AAC only).
I remember having rock-solid, fully-featured (volume control, display of song titles etc), well-sounding Sony Ericsson Bluetooth gear back in the featurephone era, but once the iPhone and Android came on the scene, it all regressed with the iPhone not even supporting A2DP for a long time, and when they first added it, the fidelity was atrocious. I can't believe they're still stuck on SBC!
What I guess is missing for Bluetooth IoT are standard profiles for IoT devices. Currently there are almost only products which speak their own protocol and need their own app. The only thing that comes a bit close to a standard is HomeKit by Apple that also works over Bluetooth, but it's closed and only Elgato managed to imlement it: http://www.forbes.com/sites/aarontilley/2015/07/21/whats-the...
It's kind of sad, because bluetooth seems to be the right protocol for this:
- it's supported by almost all devices (contrary to zigbee which needs a bridge)
- it's not totally broken in regards to local security like zigbee
- it keeps IoT devices in a local network where they belong in contrast to the WiFi IoT devices that form a botnet
- it takes less power than wifi
> Key feature updates include four times range, two times speed, and eight times broadcast message capacity. Longer range powers whole home and building coverage, for more robust and reliable connections. Higher speed enables more responsive, high-performance devices. Increased broadcast message size increases the data sent for improved and more context relevant solutions.
When will the chips be shipping anyone know?
And KSP just updated too.
Does anybody know the power usage (idle, advertising, data transferring, etc.) of BT 5 compared to BT 4.x LE?
Thanks
My smartphone let me answer emails and burning questions on the go, while also letting me give up my car. My VR headset is making me completely rethink what User Experience means to the point of making the current usage of the term UX just downright laughable.
But that's actually beside the point. I don't actually need Bluetooth to change my life. I need it to get rid of the wires in my life.
And if it worked as advertised, I could do that. But Bluetooth devices... they're just always a tad sucky. And the ways in which they just feel bad is in the secret society handshake of doom you have to do every time you want to use the device because it's 2016 and for some reason my devices still can't reliably pair with multiple other devices.
And then once they are connected, the latency in the communication almost makes them useless. I can't use Bluetooth headphones to play games, which is usually when I want to wear headphones. I can't use Bluetooth in any of my motion tracking wearable hardware prototypes, which is ostensibly the sort of thing Bluetooth wants to cover.
Something that might work for me: decouple the Bluetooth pairing from the host computer. Make it a part of the dongle. Make a dongle that is basically the wireless equivalent of a USB hub, and it's to that that I pair my devices. I'd be happy to bring that dongle with me everywhere I bring my Bluetooth devices. That might actually let me use my Bluetooth mouse on my home PC, on my laptop, and on my work PC.
Finally, would someone please design a decent, full-sized keyboard, with Bluetooth support.
Much less annoying than headphones/earbuds where the process is something like 1) Turn off earbuds. 2) Turn on earbuds. 3) Keep holding the power button for another 5 seconds to go into pairing mode. 4) Open settings app, go to bluetooth page, reconnect to device
Even if you swear by a headset in your car BT still allows call control via steering wheel buttons so you don't have take yours hands off.
Why is it that with my car, while it presumably supports having like 8 phones paired to it, I have to re-pair everytime someone else pairs?
If I'm in the car, but my wife isn't use my phone. If my wife is in the car, but I'm not use hers. If we're both in the car, pick one phone (I don't really care how). How hard is that? Rather it just seems to want to pair to whoever paired last even if that phone isn't around anymore.
This just kills me.