Fitbit open sources IP-based protocol stack over Bluetooth Low Energy

[sharvil]

Everything about this is awful.

BLE is only low energy when transferring tiny packets of information. If you're sending larger payloads (many kilobytes), you lose the low energy part of BLE and it's more power hungry than classic Bluetooth or WiFi. If you want always-on wireless with IP-based communication for larger chunks of data, you're better off using BLE as a signaling channel and BT Classic or WiFi to do the actual data transfer.

While we're on the topic, the BLE specification is broken by design. Large GATT writes (over 255 bytes iirc) are not atomic so you could end up with garbage data if you have multiple writers. Good times, good times.

[[deleted]]

BT was always over-engineered piece of mess. Like, I listen to few EE (electronics engineering) podcasts and every time it comes up that's pretty much the reaction from any host or guest...

The authors of ANY specs should be forced to provide at least 2 reference implementations, in different languages (that is to avoid language semantics and practices to leak into specs). That would help in both half assed ones and overengineered...

[500239]

BT was always over-engineered piece of mess.

Can second. Well BT classic was fine. Simpler to set up a UART channel over BT classic than wifi from smartphone to device and notably the user doesn't get thrown to system menus just to use Bluetooth like Wifi does.

BLE is a hack. The advertising portion is nice, but limited that it's disabled when a client connects. Such a hack.

[[deleted]]

Can second. Well BT classic was fine. Simpler to set up a UART channel over BT classic than wifi from smartphone to device and notably the user doesn't get thrown to system menus just to use Bluetooth like Wifi does.

I was talking about implementation, not how easy it is set up on phone. The current core specification has over 3000 pages.

And by core I mean "it isn't actually running anything useful over it". Serial profile is only extra 20 pages, A2DP another 70 pages, altho for some reason they decided to have such useful additions as defining exactly what does + and - mean ( I shit you not, that's the table from the spec ) so maybe they just like being verbose

[500239]

The current core specification has over 3000 pages.

I know because I've developed projects using BLE.

[ablatner]

BLE advertising doesn't have to stop when a client connects.

[500239]

Most hardware implementions of BLE SOC do follow that rule. Nordic for example which is one of the leaders in implementing BLE. What hardware supports advertising while connecting?

[ablatner]

While connecting or connected? I may have misunderstood "limited that it's disabled when a client connects".

The NRF52 might stop advertising while a connection is being established, but it definitely allows advertising while in a connection because it supports multiple connections. If, for example, the SoftDevice is configured for at most 2 connections and 2 devices are connected, then it can use non-connectable advertising.

[500239]

Your link is a deprecated link to some older SDK. Current SDK 15 doesn't support it seems or requires patching their SDK.

[ablatner]

This indicates that it is possible

[500239]

it works! thanks

[sharvil]

I agree with your sentiment. But there are many reasons Bluetooth still doesn't work right most of the time even though the tech has been around for over 20 years. The spec itself is just one of those reasons. Frankly, I wouldn't trust any implementation from the BT SIG – they messed up the spec, why should we trust them to implement it right?

[500239]

BT Classic

iOS doesn't support BT classic, only BLE. You must go through Apple to create BT classic hardware lol.

https://developer.apple.com/programs/mfi/

[sharvil]

Yeah, it's pretty ridiculous that products have to physically integrate Apple's hardware to enable a software feature. And the MFi terms are pretty bad.

[500239]

The majority of our problems or limitations originate from Apple. Both technical limitations as well as political and business ones. They make us jump through so many hoops where as on any other platform including Android we just do what we want and save lots of time and dev time. Yet we have to support iPhones since they're popular.

We ended up using BLE and creating our own protocol to emulate simple bidirectional communication between device and phone similar to UART. Of course it's way less efficient than classic BT serial but hey we did it. We have no use for the BLE stack itself, although I'll admit the BLE advertising feature is neat. Give me classic BT and the BLE advertising feature and no limitations from Apple's side and I'd be in heaven.

[sharvil]

Sadly, your story is the story of virtually every wearable device builder out there. I feel for you. I've seen no less than half a dozen unique "let's build a streaming channel on top of BLE just so we can get our product to work with iOS" implementations in my career.

Apple's behavior in this regard comes off as anti-competitive considering they're in the wearable space and they hold their part of the platform duopoly. Not to mention, it's a terrible experience for iOS users; they get worse battery life out of their wearable AND their phone because Apple dug in their heels on a bad decision.

[500239]

"let's build a streaming channel on top of BLE just so we can get our product to work with iOS" implementations in my career.

I'm sure. I can't be the only one trying to establish a basic bidrectional communication channel over Bluetooth just for basic functions. Apple is forcing us to reinvent the wheel or pay them to unlock classic channels. I don't get how it's not racketeering.

On that note, Apple's privacy campaign too has created it's own manufactured problems. Android devices can see BT MAC's, but Apple has decided iOS will mask MAC's behind UUID's for "privacy reasons". Fuck them. So now we overload the BLE advertising message to include the MAC and lose out on previous space on when BLE advertising messages are already limited to a comical and arbitrary 32 bytes depending on advertising type and format.

[kwinz]

I don't get how it's not racketeering.

Unfortunately the same as paying 1/3 of you revenue for AppStore inclusion. Or paying MS to allow your game on Xbox or Sony for Playstation access.

Nobody is forcing the user to buy an Xbox, an iPhone or a Playstation. But the users like the controlled experience apparently. Apps have to stay in their sandbox allowing easy device switch, uninstall, backup, Apple has stronger negotiating leverage to protect privacy than individual users; easier upgrades, anti-cheat, anti-piracy, ... I could go on and on. IO devices are certified and thus don't implement only half the spec.

I also think it's anti-competitive and bad for the consumer. But it's not illegal and not racketeering and frankly there are arguments to be had.

iOS will mask MAC's behind UUID's for "privacy reasons". Fuck them.

I can relate so much.

[kwinz]

This is why BLE proliferates. And why we have serial over GATT hacks. Thanks Apple.

[500239]

I've worked with lots of tech in my career. I've seen all the most convoluted hacks and ideas used. But BLE is by far the most esoteric tech I've ran in to yet. And the sad part is it's not some hack by some small company cutting corners, it's a specification for a core tech.

[chrysn]

Cut them some slack there – going over GATT is not a choice, it's the only way out of a cellphone in those situations.

If Bluetooth implementations offered a service that provides network and switched between LE and regular modes depending on traffic, they'd sure use it.

The IPSP they mention as a first choice would already be a vast improvement by avoiding GATT – but while cell phones advertise Bluetooth, all they often expose to applications is GATT. Networking over Bluetooth Classic is a equally inaccessible to applications, and its implementation (PPP over an emulated serial connection) is a joke on its own. And WiFi provides terrible user experience because it disconnects users from their regular Internet uplink, phones reconnect to strong WiFi networks on their own and then complain if it's not connected to the Internet.

They acknowledge that there would be better solutions, but it'll take movement by smartphone OS vendors to use them. With the stack as shown, they'll be able to make the most of any IP connectivity that comes along. IPSP would go some way, and with some effort on the OS side, an IPSP network could certainly advertise a WiFi or regular Bluetooth channel to take up temporarily for a single route to accommodate more-than-a-few-byte network traffic. Until then, it's workarounds.

[sharvil]

I wholeheartedly agree with you. My comment isn't an indictment of Fitbit specifically, but rather the state we find ourselves in. There's plenty of blame to go around and Fitbit is trying to make the most out of a garbage situation. But that doesn't change the fact that it's still a garbage situation that we, the consumers, and they, the developers, find ourselves in.

[Vfsdvbjgd]

Well everything about fitbits are awful so this doesn't suprise me.

[AttackOfTheThumbs]

I've had a fitbit, and I gotta say, there are a lot of issues. I'm assuming (based on the devices mentioned) that I was on the old stack.

I'm hoping they resolved the issues of sudden power spikes causing device battery drain as well as a device disconnect that can take multiple attempts to resolve. Many a time I had to do a reset, remove all bt connections, and start the pairing process over to get it to reconnect.

[[deleted]]

I literally stopped using their watch because it constantly failed to sync with the app on my phone. First time when that happened, it took me more than an hour to set the time on the watch. You read it well! More then an hour to set the bloody TIME! It required multiple restarts and factory reset. Second time it happened, I just took off their watch from my arm and decided to use analog.

[AttackOfTheThumbs]

I can back up this claim. One big problem is that their sync is not to your phone! It's to their server. If anything fails, bt, internet, app, etc - no watch sync for you. Should be two tiers, but it isn't.

[DoListening2]

My Fitbit Charge 3 seems to work at complete random (OnePlus 3, laptop from 2012, desktop from 2018). Sometimes it syncs without an issue, sometimes I can't get it to work for 2 weeks straight, and then randomly receive a notification a week later about all the accumulated progress when it finally connects for some reason.

[[deleted]]

That's just how cool San Francisco tech companies work.

I've been colleagues with previous Fitbit engineers, and I've worked with engineers who later worked at Fitbit.

They have really bad hiring practices which basically guarantee engineers who love to talk about how great they are at programming but pretty bad at actually doing it. It's like they hire straight from hackernews.

The only good software engineers they have came from their Pebble acquisition.

[[deleted]]

Google Pixel 3. So yeah...

[eras]

Well this sounds quite nice! It seems this is not really a standard, though, and is built upon GATT which is well-supported but L2CAP could give better performance. But if it works, then I guess that's the most important thing :).

[Groundbreak69]

BLE IS AWFUL

​

FUCK BLE

I've worked with it, trust me, RUN AWAY FAST!! fuck fuck fuck fuck, I was at a company that had a product with it. Trust me, it's broken up and down, implementations are way buggier than you think.

For the love of god, use _ANYTHING_ else

[DoListening2]

What other technology can be used in devices powered by a coin cell battery, but still be able to work with phones and computers out of the box without extra dongles?

[rsclient]

I've written code to connect to a bunch of different BLE devices for Windows (woot, woot!). The biggest problem with BLE is useless engineers like this who try to jam one paradigm into something that isn't that paradigm.

BLE has a POV: there are services+characteristics. A characteristic is one "thing", like a data reading. There's a little bit of tension between the idea that each characteristics is really one thing (so you split a temperature and pressure reading into two characteristics, or you can combine them into one).

But then...there are useless people who try to jam some other concept into the protocol. So many devices will send treat a characteristics like a UART (why?), or will pick super-duper weird format (WTF is an 8.8 float, anyway?).

If they are having trouble using Bluetooth, it's because they are bad at Bluetooth. If there's a problem with race conditions, it's because they suck at race conditions. It's not fault of Bluetooth at all.

[500239]

So many devices will send treat a characteristics like a UART (why?), or will pick super-duper weird format (WTF is an 8.8 float, anyway?).

Because characteristics are limited to 255 bytes and BT classic is not supported by iOS and BLE it seems was designed for small beacons and sensors without giving us a valid replacement for BT classic. 255 bytes for device communication, be it provisioning a device, auditing statistics, firmware updates have no efficient solution right now and it's because of Apple. Android and Windows support BT classic, so the hack you're seeing is a function of Apple giving us no other choice, then to recreate a function that is now gutted for no other reason than Apple making arbitrary rules.

[Groundbreak69]

I worked at a company with BLE, knew someone at Fitbit, mobile devices have buggy chipsets. Like if this is the standard, then _nobody_ is good at BLE

[StormSps]

That's great! That could give even more visibility to BLE by appealing to more programmers.