This isn't the first time I've talked on this. I've had some experience with bluetooth on Linux, and as a radio guy. The answer is there are problems from Layer 1 to Layer 7, needless complexity, and design by committee.
Bluetooth is an EXTREMELY complex radio protocol on Layer 1. It's like a mating dance between scorpions in the middle of a freeway. High chance something gets messed up.
Layer 1 keeps drastically changing too. Bluetooth 1 and 2 use completely different modulations, and are not backwards compatible. Bluetooth 3 simply was an extension to 2. "Let's agree over Bluetooth 2.0 to use WiFi instead." Bluetooth 4, while much simpler, uses an entirely different scheme.
Instead of a "general purpose" wireless network like WiFi, Bluetooth tried to be application specific. Except the only profiles everyone wants are mice, wireless audio, and fitness trackers. If you look at the application layer spec, it reeks of design by committee. Everyone haphazardly jammed their pet projects together, and there are redundant and vestigial parts everywhere.
The Linux side of BlueZ is abysmal. Honestly, I don't even know how anyone does anything with Bluetooth on Linux besides a mouse and keyboard. And barely even that.
As much as I hate on the protocol, the Layer 1 spec is truly ahead of it's time, in some areas. Watching two radios frequency hop, and negotiate to avoid a congested wifi channel was unreal.
> This isn't the first time I've talked on this. I've had some experience with bluetooth on Linux, and as a radio guy. The answer is there are problems from Layer 1 to Layer 7, needless complexity, and design by committee.
I'll add on to this a bit.
The Bluetooth stacks out there are, in general, tested only for a few of the many profiles BT supports. The firmware running on the BT chips is always of questionable quality, it is a black box, that in the case of one major chip vendor, is not coded using source control(!), figured out empirically as we'd get firmware drops that had fixed out latest reported issue, but bugs from previous FW drops would be present again. (Maybe they did use source control, and just had the world's worst regression test suite, e.g. none?)
That is device side. On the PC/Phone side, things are exactly the same. EVERY phone has problems with their Bluetooth stack. The Android Bluetooth stack introduces new bugs in between major revisions So does the iPhone BT stack. The iPhone BT stack had a problem for, I believe it was 3 major OS revisions, where it would just drop connections to BTLE devices, and users had to turn BT on and off on the phone to reconnect. It was reported to Apple by multiple vendors, it took multiple years for a fix to come out, and it made BTLE on iPhone a horrible experience. But similarly severe bugs exist everywhere.
HID is the one profile that will work. Serial also probably works, more or less, but serial you have to build a lot of other infrastructure on top of it. BT pairing on phones works nowadays, thanks in part to the popularity of wearable devices, but it barely functioned 5 years ago.
Other specs, including simple ones like media control (AVRCP, which is an awesome spec by the way, give it a read), will have differences in implementation between OSs (desktop and mobile), typically some basic features are not implemented for who knows what reason.
All that said, BTLE is incredibly simple and easy to understand. :)
The biggest problem we have on the Android side of things is the steaming pile that is Broadcom's bluedroid. The codebase does its own allocation tracking, threading, scheduling, and has state machines with call ins, outs, and backs (none of them used the same way). In my time on Glass, bluedroid was one of the biggest headaches we had with Bluetooth, not to mention the Bluetooth chip firmware. We tried to clean up as much as we could (and did a fair amount) bit the stack truly needs a rewrite from scratch. Some things you just can't incrementally fix -- especially when new features are continually dropped into the codebase from afar, without regard to the damage they do to the codebase.
Some things you just can't incrementally fix -- especially when new features are continually dropped in from afar,
It is the new features here that are the problem. I think you actually can incrementally fix anything, but such a project can be as expensive as a rewrite -- and neither will succeed if new stuff is constantly being thrown in.
Some very insightful discussion! I work with BLE at the software level on iOS and ever since iOS 8 it has been pretty stable, iOS 6 was terrible. However, it does seem to be quite flaky at times (interference, cheap BT chip, etc).
I've been doing iOS development for wearables for a few years and have found that you can generally make BLE for an iOS app very reliable. But it requires some work in the software to cover up some of the underlying flakiness. Reminds me a lot of building resilient networking code for apps back when cell service was slow and spotty. But if you do a little work to build in command queues, auto-reconnect, etc it can be very solid for the user.
Oh, and it helps a lot to pick a good chip. From my experience, the Nordic NRF5x series is the best. But as has been mentioned elsewhere in this post you still need to have a quality antenna design. I've noticed a huge difference between using a reference design and one that spends some time in a chamber with a good RF engineer.
> BT pairing on phones works nowadays, thanks in part to the popularity of wearable devices, but it barely functioned 5 years ago
Huh? Pairing worked like 10 years ago. And sending files between phones. Everyone in school was sending J2ME games/apps around :D Audio with media control also worked. And modem (using the phone's GPRS/EDGE connection on a PC).
I don't know, just last week I was having issues pairing my iPhone 7 to my friend's new Jeep and ended up giving up. I usually just keep bluetooth turned off on my phone and don't buy bluetooth devices since I find it's often more frustrating than not.
TL;DR: Remove old paired devices! I just went through this this week with a 2013 Wrangler. Here's what fixed it for me: deleting the other bluetooth devices from the radio. It had my old iPhone and my brother's iPhone. Neither was anywhere nearby, but when I tried to pair with my new iPhone, it wouldn't work. I tried multiple times over multiple days. Finally, as a test I just removed the other 2 phones from the profile. It paired perfectly after that and has worked since.
Any suggestions for pairing a OnePlus 3 with a (2016) BMW for audio? Mine works like a champ for speaker phone but in order to play any kind of media, the OnePlus refuses to do it. (Though my son's Samsung Galaxy S5 works.)
My experience was that Bluetooth was solid at the end of the dumbphone era (although the UI was often crap). Like you we were bluetoothing files back and forth, I was syncing phone contacts with my Mac over iSync Bluetooth, sending SMS/getting call notifications on my Mac (can't remember the name of that app), etc.
But when iOS/Android smartphones came on the scene it took a huge step back in reliability. A2DP also took a huge step back in audio quality until the new platforms tweaked their SBC parameters and added in MP3/AAC support.
The craziest setup i ran with back then was a Nokia N800 paired up with a Sony Ericsson C702 and a no-name folding keyboard. The C702 was also paired up with a pair of Jabra headphones/headset.
At certain times all of those could be in use. The C702 acting as the modem/router for the N800, whole also playing music through the Jabras, and me typing comments on the Maemo forum etc.
The only times there were a hitch were when i used the modem profile between the N800 and the C702, rather than the PAN. Something about the intensity of chatter or something between the two made the music and keyboard stutter.
Do note though that headphones can act up if you are out and about with little for the signal to bounce off. Best then to have all devices on the same side of the body for less obstructions.
I used to use Bluetooth PAN with my M600i (UIQ3): no wifi? No problem! I connected to my dodgy windows 2000 laptop with some BT software and drivers (and a dongle), and shared its connection to my phone :)
I used to work with SVN in a group of 3 developers and several branches (test, staging, master) and it was pretty messy.
When I read the original comment about bug fixes disappearing, it reminded me of merging test onto stable by hand, not knowing what was "the good code" and having to ask, research, etc. It was messy and some times we got regressions.
We called this thing, a bug fix got "merged away".
Nowadays with Git, feature branches, better test coverage, continuous integration; things have got much better.
I.e. was it just a crazy requirement handed down, or did they not know better?
I just can't imagine it even for solo development, nevermind collaborative work! "Agh. We must have had a merge conflict, damn, the core part of my work is gone... Let me see if I have a recent copy... Oop, no, I don't, because I've run out of disk space from all these clone backups."
FWIW, I use git inside Dropbox for my personal solo projects. I don't want to have to use commits and git's remote syncing mechanisms to share in-progress code between my desktop at home and my laptop. I want to be able to pick up exactly where I was on the other machine, including my git staging area and local unstaged changes. It works perfectly for this.
I do occasionally get Dropbox-level merge conflicts for tmp editor/IDE files, but I can't recall getting any for source files.
So, neat trick: "git clone" your local Dropbox copy somewhere, and you get the benefits of "commit" and "push", but it's local; and then your remote is synced via Dropbox :)
I use a similar setup. I use spideroak hive since its 'zero knowledge', I don't however sync any binary or IDE directories. This allows me to have the source files and git repos synced, but still keep somewhat independent set ups.
All projects were single developer. It was a burn and churn environment. Contractors from all over the world, share a folder from the root, they work in it, when they completed it, the folder was unshared and they were paid.
It worked OK for that purpose. And I still have dropbox mainly for that reason. My source code is always local. Everything goes into TFS, but the local is backed up to dropbox.
I'm not sure, I'm no longer working on products that use BlueTooth. I know that BT pairing has gotten easier and easier over time (improvements to the spec), but the real important parts are the BT stacks and BT chip firmware. From what I understand working with BT Engineers, the best BT stack was from Stonestreet One, who was recently bought up by Qualcomm. If someone had bought them up and open sourced their code, the world of BT would be a much better place right now.
Well, after 20 years, USB (another specification which aims at making a hundred kinds of different coffees, like about every specification designed in the last 20 years) kind of works nowadays, so there might be a bit of hope. Hmmm wait, except twice a week when I plug USB devices in the 'wrong' order on my computer. Oh well...
Serial has its issues too. We are using a serial port over BTLE and when you need to do anything with debuffering/buffering and online data... you no longer have a UI because the transmission is so slow.
> As much as I hate on the protocol, the Layer 1 spec is truly ahead of it's time, in some areas. Watching two radios frequency hop, and negotiate to avoid a congested wifi channel was unreal.
What are you using to watch Bluetooth at a low level?
My Magic Mouse at work would get very jerky with my Mac Pro. Resetting it would sometimes clear it up for a while. I swapped it with my Magic Trackpad from home, and the mouse is fine at home, and the trackpad now has the jerkiness although not as much as the mouse did.
I tried moving the Mac up on to the top of the desk so the mouse/trackpad is only a few feet away, and has line of site instead of having a metal desk between it an the computer, but that made no difference.
I'm speculating that it is some kind of interference from the office downstairs. (It's an office of Azima DLI, which develops all kinds of stuff that might be noisy in RF).
I'd like to be able to take a look at what is actually going on in my office (1) with RF in general, and (2) specifically between my Mac and my trackpad or mouse.
I thought this might be an excuse to step up from one of those $15 SDR dongles I've played around with to a HackRF, but from what I've read the HackRF cannot fully deal with the Bluetooth frequency hopping. I think I read that using multiple HackRFs one can do it, but that's beyond what I want to spend.
USB 3.0 devices can interfere with Bluetooth. Do you have any external hard drives in plastic enclosures? Non-shielded cables?
USB 2.0 doesn't present this kind of problem.
> Watching two radios frequency hop, and negotiate to avoid a
> congested wifi channel was unreal.
Exactly. As I said in another comment, we did a test in a very busy office space and didn't loose a single bit of data @ several 100kbit/s over a week transmitting continously. We could see it hopping on the sniffer.
True, as long as both transceivers are 100% to spec. The problem is, it's a VERY large and complicated spec, and it's easy to make one little slip and have to completely renegotiate the connection.
- Are there similar close range wireless protocols that are stupid simple (say like IR communications but on Radio spectrum)
- Could someone or some team something stupid that could be handled by todays micro controlers (esp32 is 7€ for a dual core 32bit processor, I suppose it can be used as a dedicated comm. proc)
In a way, wifi is perfect for 0-50m~, we just need a similar idea for 0-10 and low bandwidth.
You want Nordic nRF24L01+ radios. That can be trivially handled by an 8bit micro using SPI, modules with these cost peanuts. However, if you want a PC/phone connectivity you would have to build your own dongle - or reprogram one from a wireless mouse/keyboard. Many use these chips.
Another option is ANT+ - that is very low power but also very low bandwidth (8 byte long messages 4x a second ...) protocol used mostly by fitness gear like training bikes, treadmills and such. Many smartphones have radios that are able to use it. Again something that is easy to make work even with an 8bit micro.
For more advanced stuff there is Zigbee, but that is quite a bit more complex (but still manageable even by an 8bit MCU) and there are some licensing issues which kept it rather obscure.
It sounds like you'd be interested to get into ham radio. There are plenty of digital modes, and you can communicate all the way around the Earth in the right atmospheric conditions using a big enough antenna, or even bounce signals off the Moon.
There are videos of HAM guys scanning randomly through the spectrum to find people. I remember one video, 80% of it was static, and then a blip.. the guy (somewhere in the US) started to poke around that freq. another blip.. then a voice. It was a Russia dude answering, it was surreal.
Everyone says this, yet I use bluetooth products (all Apple hardware) literally every day. Apple has really polished bluetooth to the point where I don't even remember I'm using it, and never have to deal with pair requests, signal loss, etc.
In most everything I own, bluetooth is frustrating crap. Apple's somehow gotten it (mostly) right, so why can't anyone else?
This and the random disconnections of my BT trackpad and keyboard are really annoying.
I believe more people here will have encountered this behaviour when all of your paired devices suddenly disconnect from the MacBook, what have helped me is to turn my Wi-Fi radio off, wait for the devices to reconnect and then turn it on again. This has happened to me for at least the past 3 or 4 major versions of OS X/macOS.
That's interesting, I've never had any issues at all with my Bluetooth. (MBP late 2014, mid-2012 prior to that one). I use the keyboard, trackpad and mouse and never have used anything else.
This, I have the same experience with my BT bose speaker, forever having issues. Sometimes it'll need to be re-joined, other times it works, but then starts skipping. Granted I've had pretty good experience with Apple to Apple BT. Like Apple BT mouse or trackpad, where as the Logitech BT mouse is jumpy/sluggish.
I've been having a shitty experience with 2.4GHz WiFi combined with Bluetooth on my late 2013 MacBook Pro Retina for ages. The Wifi performance goes to shit with multiple devices connected and the bluetooth devices stutter and disconnect. It was completely unusable in Yosemite but slightly better in some version after that. It's currently "usable" unless I do heavy downloads over 2.4GHz with a bunch of bluetooth devices connected. With 5GHz Wifi everythings fine and dandy.
It's not an issue when running Windows on the machine and it's not due to congestion regarding 2.4GHz wifi networks. And it's not AP related. It's macOS related. I am also not alone in experiencing it. Not the worlds biggest issue but frustrating as hell.
Personally I've always had skipping problems with -ANY- Bluetooth speaker, be it with my Macbook, iPhone, Android handsets, etc. And I've got everything from a bluetooth enabled car stereo to a Bose Soundlink II, just doesn't seem to ever get better.
Yep. I took to emailing pictures to myself to transfer them because it was so flakey. The tricky part was that because it was supposed to Just Work there's not much configuration or anything you can twiddle to refresh or anything, so when it Just Doesn't you're completely out of luck.
> As much as I hate on the protocol, the Layer 1 spec is truly ahead of it's time, in some areas. Watching two radios frequency hop, and negotiate to avoid a congested wifi channel was unreal.
Is it really ahead of its time?[1][2] I recall reading somewhere that Bluetooth traces much of its roots to military radio applications.
Funny thing is that the profiles are what i actually like about Bluetooth. Particularly the ones imported from OBEX.
While wifi is perhaps more interesting, at least with OBEX push and FTP i know (and it have yet to have it fail, knock on wood) that i can transfer files, albeit slowly, between two devices.
Get two devices on the same wifi network and i still need to figure out a protocol both of them can talk so that they can exchange data (never mind that they had to introduce wifi direct because certain devices refused to connect to ad-hoc wifi hotspots).
But bluetooth keeps getting rammed down our throats with bluetooth hardware being installed on motherboards (sometimes not even as removable modules) and bluetooth software in the O.S. turned on by default (lolsecurity), sometimes even at the BIOS/EFI layer.
Add in all the complexity of different bluetooth versions and you have something that "seemingly everyone" has but few people reliably use.
Bluetooth is an EXTREMELY complex radio protocol on Layer 1. It's like a mating dance between scorpions in the middle of a freeway. High chance something gets messed up.
Layer 1 keeps drastically changing too. Bluetooth 1 and 2 use completely different modulations, and are not backwards compatible. Bluetooth 3 simply was an extension to 2. "Let's agree over Bluetooth 2.0 to use WiFi instead." Bluetooth 4, while much simpler, uses an entirely different scheme.
Instead of a "general purpose" wireless network like WiFi, Bluetooth tried to be application specific. Except the only profiles everyone wants are mice, wireless audio, and fitness trackers. If you look at the application layer spec, it reeks of design by committee. Everyone haphazardly jammed their pet projects together, and there are redundant and vestigial parts everywhere.
The Linux side of BlueZ is abysmal. Honestly, I don't even know how anyone does anything with Bluetooth on Linux besides a mouse and keyboard. And barely even that.
As much as I hate on the protocol, the Layer 1 spec is truly ahead of it's time, in some areas. Watching two radios frequency hop, and negotiate to avoid a congested wifi channel was unreal.