> 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.

Same experiences. I don't even bother trying blutooth anything anymore. It's more frustration than it's worth. It's disabled on all my devices.

>just last week I was having issues pairing my iPhone 7 to my friend's new Jeep and ended up giving up

for audio, right?

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.

Indeed.

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'm glad your experience was very different from mine.

All due respect, it does work much better today than it did 5 years ago. Many things now "just work" and it used to be more fiddly.

> that in the case of one major chip vendor, is not coded using source control(!),

In this day and age it's absolutely insane to not have revision control.

I was using SVN for my personal projects 10+ years ago. It's crazy to think that some companies may not be using source control even today...

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.

You guys must not work in electronics.

I worked in electronics 30 years ago and we had revision control.

They're definitely out there.

Even in places that think they do, it seems pretty common to have an additional codebase in the database without any real version control.

I'd like to know how problems like this correlate to data breaches.

I worked for a client years ago, Dropbox was source control. It wasn't as bad as none, but you lost changes at the 30 day mark.

Were the (technical) employees happy about it?

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 :)

> neat trick: ... and you get the benefits of "commit" and "push"

GP seems to be deliberately avoiding commands relating to remote management, such as push.

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.

just so you know, git on dropbox is not a great idea in a team. solo it should be fine but you are probably better off using bitbucket for free.

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.

Is there any reason to hope things might be finally resolved in the somewhat near future?

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.

Based on 16 years of the technology never failing to disappoint, none whatsoever.

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...

On the bleeding edge, the future with reversible connectors is here, with USB-C style connectors (on both ends!) for everything.

'course, now there's a hundred dollars in various adaptors to rebuy...

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.

The best tool for low-level Bluetooth/BLE sniffing and injection that isn't obscenely expensive is probably the Ubertooth One.[0]

[0] https://greatscottgadgets.com/ubertoothone/

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.

You're a radio guy, I have two questions:

- 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.

Another radio question: what about having long distance radio communication between 2 devices or more? Any project around it?

Local radio text chat could also be fun... Think of an IRC channel, only for the people who can grab the signal...

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.

APRS is something like that, popular with hams.

for just 'text' maybe something like LoRaWAN[1]

[1] https://en.wikipedia.org/wiki/LPWAN#LoRa

Oh yeah that nordic chip sounds familiar.

ANT+ could be enough for a control path or maybe keyboard.

I always wanted to try zigbee but it felt too much like a closed world, although people seemed very satisfied with it it seems.

Isn't zwave an option for more complex networks?

> 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.

[1] https://en.m.wikipedia.org/wiki/HAVE_QUICK

[2] https://en.m.wikipedia.org/wiki/SINCGARS

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).

FHSS is an amazing technology, from the standpoints of both efficiency of spectrum usage and being a clever loophole for regulators.

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?

To provide an alternative data point, everything works flawlessly with my Bluetooth wireless speaker except my MacBook. It constantly skips.

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.

I can't understand why AirDrop is as unreliable as it is. It's abysmal and only Apple is to blame.

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.

Now that is 100% true. Is AirDrop bluetooth or Wifi though?

Seems there is a bit of both, depending on what generation of hardware and software involved.

That's probably why it's on the flaky side.

I can't even get the Apple Wireless keyboard working on my Mac :( Keeps disconnecting every odd minute

Close to a hotspot or a noisy microwave nearby?

It's pretty much transparent to me using Android and my Windows PC too. I didn't realize it was supposed to be "unreliable."

Oh I've definitely found it unreliable elsewhere, especially in the cheaper Android handsets I used to get.

I guess it's a matter of getting what you pay for. It works quite well with my Nexus 6P.

You can't have a bluetooth serial adapter on the iphone, because it only supports a few bluetooth profiles. This cuts a lot of complexity.

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.