This is awesome! The 2.4ghz nordic RF chip is cheap and easy to work with, I could imagine the guts of a simple "FitBit" style device made for just $5 at 'maker scale' of 1,000+ units. The ability to talk to android/ios phones cheaply will lead to some really cool projects. Obviously if you're going commercial you have so many other hurdles to cross that you may as well just use BTLE proper, but for hacking/making/prototyping it's very cool.
Why not just use a Nordic nRF51822 that comes with a full BLE stack, 32 arm processor, super low power. $2.50 per unit instead of using a separate micro and transceiver.
In order to use BLE stack in nRF51822, one will need to deal with their DRM for the S110 SoftDevice, or implement an open source BLE stack similar to what the article suggests.
What DRM is there? I thought the SoftDevice was just a binary blob? I'm currently in the prototyping phase of a product that uses the nRF5, I couldn't see any competitive advantage I would gain from developing my own stack considering the time investment it would take.
The website requires a Product Key (not serial number) before it allows you to download the installer (I would assume for licensing reasons). The installer also includes documentation and tools that make working with the soft device easier.
Yesterday, I have bought a few nRF51822, and will update this thread with my experience. While all early signs, including your words, indicate a good possibility that I will hit an unexpected problem due to the licensing scheme, the lack of the first hand experience does not let me be firm in my statements.
> It has absolutely nothing to do with bluetooth besides the name
Not really true.
APIs on Android are mostly the same with a small new set of classes. HTC and Samsung and Broadcom have an API for over a year now and there's an Android standard one in the latest Android announced at Google IO. Enabling and pairing and device discovery are all the same from the Android side, though. Maybe an extra constant indicating the device type.
Additionally, it's from the same group as Bluetooth, you often buy adapters and scanners and equipment and test software that are dual mode. This is why BLE is destroying older protocols for the same thing like ANT. ANT was never used much outside a few fitness and medical devices. BLE is all over the place since devices often have a Bluetooth chip in them anyway, so it isn't much more to make it dual mode. Many Android phones support BLE now.
Also in that area, the big Bluetooth Unplugfest conference and testing event is there for BLE just like Bluetooth. So all the companies that go to get Bluetooth certified are there with the BLE offerings.
Unfortunately, the Android BLE API only supports half of the standard, as Android devices cannot be placed in peripheral mode. This is something Apple released on day 1, and it's slightly infuriating when creating cross-platform applications.
There is no good, non-hacky way to do local radio comms between iOS and Android, and it stinks. Here's hoping Kit Kat rolls out with full BLE support.
Another cool hack with Bluetooth from MSR. Emulating a long-lived connection to a smartphone even when the phone is blocking incoming Bluetooth connections:
Oh, because ANT+ lets you connect to multiple devices simultaneously. BTLE doesn't let you do that, and it's a pretty big problem.
For example, if you do triathlons ANT+ lets you use a 910XT for the swim & run, and an Edge 500 for the ride without having to re-pair the devices.
This isn't just a theoretical problem: according to a very recent DCRainmaker survey[1] 29% of people use this exact scenario[2].
iOS is bit issue of course, but there are ANT+ dongles and BTLE->ANT+ retransmitters (in the form of a heart rate monitor band). It's worth noting that the Stages power meter does do the dual BTLE and ANT+ transmission thing.
I think ANT+ is going to hang around a lot longer than people think, especially in the field above casual fitness.
Bluetooth LE uses a client/server (called "central" / "peripheral") model; think of "server" like "web server", typically the client is your smartphone.
I could believe that a single peripheral can't simultaneously connect to multiple centrals (I'm just getting started with BTLE), but the typical pattern is for e.g. the heart rate sensor and smartwatch to both be peripherals of a smartphone.
The first article you reference says: So for folks that may use one device for cycling and another for running, this could cause issues if both devices tried to connect to the heart rate strap at the same time.
As long as you're not cycling and running at the same time, this isn't an issue.
I'm pretty heavily in this field (both as a user and occasional developer). I understand the models pretty well, and BTLE has this wrong, because of their smartphone-centric view of the world.
For casual fitness stuff they can get away with that, but as you get more hard-core it breaks down pretty quickly. After all, Garmin has built a multi-billion dollar business building devices that where a smartphone can handle 90% of the functionality. For that extra 10% you still need an extra device, and that extra 10% is often the rich, passionate end of the market.
Some specific examples:
In a triathlon you are unlikely to take your watch off after the swim when you get on your bike. The HR strap will remain paired to the watch and not your bike display (and given than the swim->bike transition and bike->run transition are often in different locations taking it off isn't realistic either).
People use gym equipment with built in ANT+ displays, but want to record their workouts on their personal devices.
These are both big markets (Garmin/Timex/Sunto/Polar all have specific devices just for them) and BTLE doesn't work in these scenarios.
This is the best resource on the subject, written by the designer of the protocol. The author is, surprisingly, a pretty good writer. This not only gives you everything you need to know (without grokking the spec), but also talks a lot about why they made the decisions they did.
