Hacker News Reader

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

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.

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.

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

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.

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

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

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.

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

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.

You guys must not work in electronics.

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

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.

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.