Hacker News Reader

Comment by nine_k | Hacker News Reader

I tried to learn why BT is still somehow painful to use, and the article basically does not have an answer.

My take from comments here and my experience:

- Makers of BT devices can't agree on many important common things (easy discovery / pairing mode, priority, etc), and have little incentive to seek agreement. It's like phone chargers before USB.

- Makers of BT devices tend to cut corners and/or add not-entirely-standard features. They "save" on writing a good driver. They care little if devices made by their competition don't work reliably or at all in the mix. (And even sometimes their own!)

- RF noise makes radio interfaces like BT inherently not always reliable. But the user never notices when a small EM storm rages nearby, for the user it's just "damn bluetooth glitches for no reason at all".

View on HN

They do agree on an awful lot of stuff, but the tools provided by the Bluetooth guys aged very poorly (i.e. their tools for generating GATT interfaces as C code is absolute garbage, full of holes and has a built-in buffer overflow capability).

The one thing nobody seems to do is stick to the standards provided, because they simply aren't broad enough for the creative stuff that people do with Bluetooth and Bluetooth LE. Most of us working in this space have some cack-handed way to advertise data without connecting because (for example) most of the connections to Bluetooth LE devices involve you having to do device discovery, even if you are connecting to 500 of the same damn device.

Also, the bluetooth library in Android started out terrible and didn't improve despite being replaced, the Bluetooth chips in most cheap phones are also rubbish and fail when you exceed their undocumented number of connections, often requiring a reboot of the device etc.

In short: You can sheet a lot of the problems back to an ill thought out spec and bluetooth chips in things like phones that just plain suck.

Things like RF interference - I just don't know. Sometimes there is just a heap more bluetooth traffic around than anybody knows about. Packet sniffers are relatively cheap, it's interesting to fire one up in a busy office and see how many bluetooth packet collisions there are (hint: it's a lot). Blame RF storms or whatever but it's more likely to be something advertising a lot and spamming the spectrum.

Something I’ve noticed is that Bluetooth breaks down around major construction sites, like infrastructure projects. It’s very strange, I wonder if they have some kind of high power BT transmitters for some reason.

Any high power 2.4ghz transmitter will destroy Bluetooth communication, this is all in the same 2.45ghz ISM band. I guess they use some devices communicating on that band.

They certainly do - walkie-talkies!

Edit: Yes, they do exist - you can google this. But on reflection, a commenter below is probably right that it's more likely wireless security cameras, given typical site requirements (range, penetration depth)

Handhelds are usually UHF - in the 446MHz range. Do you know of personal radios that operate in the 2.4GHz unlicensed spectrum?

Drones (FPV), baby monitors to name two. I’m sure there’s more.

I don't think they use the 2.4 GHz band.

https://en.wikipedia.org/wiki/General_Mobile_Radio_Service

On construction sites, I'd suspect that the problem is an awful lot of EM noise from machinery that should have been replaced or at least maintained decades ago, like mechanic spark generators/distributors from simple combustion motors or brushed electric motors (e.g. in drills).

Additionally, remote controls for cranes, concrete pumps and other machinery may be the cause, depending on the frequency bands these use. Here in Germany, it's all 433/869 MHz from what I remember from sites I worked at, but no idea about the US.

It may be motor noise but anecdotal evidence suggests that it happens even when the machines are off, eg on national holidays. Some kind of transmitter seems likely though. I know one construction site had analog video signals in the 2.4 Ghz range for their surveillance cameras. I accidentally found out when I did a range sweep on a video receiver for other reasons.

PS I am in northern Europe, not the US.

> The one thing nobody seems to do is stick to the standards provided, because they simply aren't broad enough for the creative stuff that people do with Bluetooth and Bluetooth LE.

Yeah, I've been working with BLE now for clients for 3 years, it seems like most people think of their devices as little CRUD servers (unless you're doing genuine pairing with constant data streams). BLE would be much better using a simple REST model than the GATT table model.

> Also, the bluetooth library in Android started out terrible and didn't improve despite being replaced

One thing I'll give Apple credit for is having a very solid bluetooth stack. We've had only a handful of BLE connection failures on our testers apples devices over the past 3 years, whereas on android test devices we get at least one connection failure DAILY that interrupts test cases from running. Furthermore Android devices just reach a point of critical failure where you need to just restart the device to resume BLE.

/Opinion: "Makers of BT devices can't agree on many important common things (easy discovery / pairing mode, priority, etc)." => I think it is not the creators of the devices (peripherals), it is in my expierence the SmartPhones (Apple/Google) => iOS won't let you discover BLE Devices which have only generic or costum services/characteristics => iOS will hide parts of advertisment/discovery data from app developers => iOS won't let you know if a device is bonded/paired via API => on iOS if you want to initiate bonding, you have to initiate it from the peripheral => Android sometimes "forgets" keys of paired devices => Android sometimes scrambles data from characteristic notify() => Android sometimes "misses" characteristic writes (ratio 1:1000000) This is just what I could come up with in a minute. I develop both FW for peripherals and Apps, so my 2 cents => It's almost never the peripheral/fw and most time the Smartphone => RF noise is (almost) never an issue, glitchses come from phones

Why is this written with slashes and fat arrows?

> It's like phone chargers before USB.

No, it's like phone chargers before EU regulators stepped in.

Everyone except Apple was already on USB.

And even in the pre-smartphone days, phone chargers always worked reliably. Phone charging is and was the complete opposite of what bluetooth is today.

They most certainly were not: https://www.engadget.com/2009-06-29-nokia-apple-rim-and-othe...

Ok, so since 2009 everyone except Apple was on USB.

No, because there were many other manufacturers.

2009 is when the EU stepped in. They didn't have to set it into law because the industry agreed to it voluntarily except for Apple.

"industry agreed to it voluntarily" China before eu(~1-2y) forces usb chargers. and industry had choice, make special version for them or not.

Thankfully that EU initiative failed. They wanted the industry to adopt micro-usb as the standard, which would have sucked and would be worse than the situation today

How was getting all manufacturers to agree a "failure"?

The EU charger mandate required USB if USB was sufficient, IIRC apple managed to continue using lightning connectors b arguing that USB standards of the time where not enough for the iPhone.

Is the situation today not 'everything is micro-usb, usb-c, or apple'?

> Everyone except Apple was already on USB.

My old box of chargers begs to differ

That was my first association as well. This seems like a much much harder thing to regulate though...

For USB chargers industry had come up with a good solution but market failure meant there was no incentive to adopt it. That's text book regulation stuff. Here there doesn't seem to be a good proven solution out there that you could mandate...

there's no need to mandate it, but the EU could spend a few ebucks on consumer appliances interoperability testing, and simply shaming those that suck. (or at least put out a statement about the problem, which could be simply lack of incentives for cooperation on solving the issues. or maybe too much backward compatibility preventing the whole ecosystem to move to more robust BT standards, etc.)

for example just a few days (week) ago there was a thread about how Logitech wireless stuff and wireless headphones interfere.

sure, it's hard to point to a singular root cause (Logitech emits too much, or headphones are ill-designed and BT is simply not the right tool for this because this or that)

but there are clear software (firmware, drivers, kernel) failures, that stem from simply releasing absolute garbage. (and every layer just coding for the happy path.)

Logitech bluetooth wireless and apple airpods specifically. Logitech over their own wireless protocol, or any other set of wireless headphones is fine.

I have three sets of bluetooth headphones that I use on a rotating basis daily with my logitech bluetooth mouse and keyboard, and they are all dead reliable... well dead reliable for bluetooth devices

>No, it's like phone chargers before EU regulators stepped in.

When did this happen ?

2009

More info: https://en.wikipedia.org/wiki/Common_external_power_supply

I for one will be very happy when the EU forces my US iPhone to drop lightning.

The specs (there are multiple) are enormous and you honestly have zero hope of fully implementing one from scratch. It's thousands and thousands of pages covering everything from the physical layer all the way up to deep application-layer integration. Manufacturers rely on support libraries and hardware that does most of the work, and until only the last few years most of those on the whole have been total garbage (again because the specs are so massive it just costs too much time and effort to implement them). I don't expect anything less than a team of 10 people all with a mix of senior hardware and software/firmware experience could fully implement bluetooth & bluetooth LE from scratch in less than a year.

Bluetooth devices will "frequency hop" in a schedule to which they both agree. Noisy frequencies that result in lost data will be removed from their scheduled shifts.

There are only a maximum of 79 channels switched 1600/second, and if there is more noise than not, then the data rate will suffer, although updated modulation standards might compensate, if implemented.

BT device makers are also coming in a slightly less explored field and have to make UX decisions that might not have clear answers yet.

For instance some BT headset have only a few buttons, and the play/pause button does also redial the last connected phone number depending on the phone’s state. I’m sure someone thought this feature made a ton of sense and really helps them in their day to day life, while I hate with the heat of a thousand suns.

I’d expect it takes us a few more years to come to a consensus on how to cleanly solve this kind of diverging views.

Config files/settings.

This is of course part of the puzzle, and that behavior having no config is probably a sign it's still not mature enough.

I'll add that the specs are so bad that it's not commercially viable to try to fully understand them before building and launching BT products and middleware.

Most of it is the Bluetooth SIGs fault. It has got away from them. It reminds me of SMTP or HTTP, it is so useful that people couldn't wait for things and just implemented and added whatever they wanted. No certification is required just a registration for the logo so it has made it the wild wild west. Additionally being stuck in the "free" frequencies means that it has no ability to deliver quality in a noisy room.

Trying to understand bluetooth's awfulness is a dead-end. I tried. I thought, "yea, you're nerdy enough to read the tech specs, it will be boring but after an hour you'll understand and your bluetooth keyboard will pair every time instead of 85% of times". Nope.

Also, head units generally don't get updates and the lifespan of a car is quite long. The phones that we are using now didn't always exist when the head unit was made.

> user never notices when a small EM storm rages nearby

What's the easiest way to detect this? Is this something an average smartphone can detect with the right app? Or would I need to buy specific hardware to detect it?

We just learned that any Bluetooth device can detect it easily.

Reply on news.ycombinator.com