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.
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.
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.
PS I am in northern Europe, not the US.
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)
No, it's like phone chargers before EU regulators stepped in.
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...
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.)
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
When did this happen ?
/s
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.
My old box of chargers begs to differ
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.
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.
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?
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".