
Faking Bluetooth LE - tdrnd
http://dmitry.gr/index.php?r=05.Projects&proj=15&proj=11.+Bluetooth+LE+fakery
======
acgourley
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.

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

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

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

~~~
krasin
Have you noticed that you had to enter a serial number in order to get your
SDK?

~~~
FigBug
Yes, is the Sdk somehow locked to the processor serial? How does production
work?

~~~
foolsday
The soft device is provided as a hex file and does not contain any DRM
whatsoever.

~~~
krasin
Can you post a download url to this hex file? Will the license allow you to do
so?

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

~~~
krasin
Thanks for the information.

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.

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

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

~~~
JimDabell
> This is something Apple released on day 1

Actually, iOS had support for acting in central mode only in iOS 5 and added
support for acting in peripheral mode in iOS 6.

------
locacorten
Another cool hack with Bluetooth from MSR. Emulating a long-lived connection
to a smartphone even when the phone is blocking incoming Bluetooth
connections:

[http://research.microsoft.com/en-
us/um/people/ssaroiu/public...](http://research.microsoft.com/en-
us/um/people/ssaroiu/publications/mobisys/2009/bluemonarch.pdf)

------
swamp40
So I don't really get why you'd want to use a $2.50 chip to half-ass implement
the functionality of a $3 chip.

(You can't bond, you can just advertise, and you can't do the necessary CRC.)

The code's not that much different - just buy an nRF8001.

Nordic started with the nRF24LE1 and tweaked the hardware to match the
Bluetooth specs and turned it into an nRF8001.

(Or better yet, use a TI CC2540/41\. The documentation is much better.)

------
nl
Related, Samsung announced that they will be enabling ANT± on all their S4
phones, and apparently the S3 hardware can be enabled too(!)

That's big news for anyone doing connected devices.

~~~
stbtrax
It's good for legacy devices, but I can't think of any reason to use ANT in
future products since you'd need to have a BLE version for iOS users.

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

[1] [http://www.dcrainmaker.com/2013/09/curiositysurvey-
different...](http://www.dcrainmaker.com/2013/09/curiositysurvey-different-
cycling.html)

[2] [http://www.dcrainmaker.com/2013/10/symposium-keynote-
present...](http://www.dcrainmaker.com/2013/10/symposium-keynote-
presentation.html)

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

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

I _wish_ it did, and I hope they will fix it.

------
thethimble
Does anyone have any good resources for learning more about BLE?

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

Highly recommend... [http://www.amazon.com/Bluetooth-Low-Energy-Developers-
ebook/...](http://www.amazon.com/Bluetooth-Low-Energy-Developers-
ebook/dp/B009XDA1G8)

~~~
timthorn
He is also a very good speaker, if you ever get the chance to hear him.

