
Show HN: Bluetooth 5 and Bluetooth Low Energy – A Developer's Guide - mafaneh
https://www.novelbits.io/book
======
barbegal
Sadly this book is probably of limited use because it doesn't appear to cover
getting BLE (Bluetooth low energy) to work with Android and iOS.

Using BLE according to the standards is relatively simple if you have control
over both ends of the communication link. Unfortunately in most cases you have
a BLE device that you wish to talk to a smartphone or tablet. In this case you
have no control over one end of the link because that is controlled by the
smartphone chipset and the OS (Android or iOS). Getting BLE to work well and
consistently across a range of smartphones and tablets is tricky because the
API has changed between OS versions, with Android becoming more focused on
preserving battery life rather than offering developers a way to make BLE work
in the precise way they want. In addition chipset differences means even with
the same version of the OS you get different behaviours especially when
multiple BLE devices are involved.

Lots of the nice stuff in the standards flat out doesn't work with iOS and
Android. Out of band pairing (except NFC pairing on Android) doesn't work
meaning in most cases you have to revert to insecure pairing methods because
your BLE device has no user interface.

~~~
mafaneh
First, a disclaimer that I'm the author of the e-book listed.

Yes, I agree that getting BLE to work with smartphones is not an easy task.
The APIs are ever-changing and evolving and differ across different devices as
well. In the end, though, they must adhere to the official specification and
provide an interface to the underlying protocol.

There are many embedded developers that are looking to learn the protocol and
don't know where to start (myself included, especially when I first starting
learning the technology). The specification is quite overwhelming and there is
a lack of resources that cover both theory and implementation together.

The book is targeted at embedded developers with the goal to help them learn
the basics of the technology by guiding them through various exercises and
examples. There are also many new use cases popping up where an embedded
platform is used on both ends making the task easier (compared to pairing with
a smartphone app).

------
flyingcircus3
The entire bluetooth ecosystem is an enigma, and I say that as someone that
has spent the last couple of years professionally developing embedded systems
primarily using Nordic Semiconductor parts, one of the flagship companies of
the industry.

It is one of the most reviled protocols by developers, when they are the
users. Yet, the basic goal of Bluetooth has always been to vertically
integrate the entire OSI model, from Application to Physical to Application.
So one might say they've taken a bigger bite than they can stomach.

I haven't dabbled with 5 yet, but I believe I could effectively tutor any HNer
in 4.2, if they were willing to put the effort that learning anything
worthwhile requires.

One of the largest paradigm shifts coming from the TCP/IP stack world, to the
Bluetooth world, is that you are inherently creating application level
"software", but since its highly embedded, "firmware" developers end up doing
a big chunk of that work. Ew.

For instance in BLE, or Bluetooth Low Energy, to integrate a heart rate
monitoring application, the Bluetooth specification defines a heart rate
service. As the name implies, the heart rate service encapsulates all of the
information that is pertinent to monitoring hearts, given sufficient sensors.

A service is made up of characteristics. As the name implies, characteristics
are data structures that encapsulate a single piece of information that would
likely be useful at the application level. In the case of our heart rate
monitor, it is simply the frequency at which your heart beats. Your heart
rate.

In the parlance of Model View Controller, the actual sensor logic to provide
that heart rate, is traditional embedded development, and out of the scope of
Bluetooth.

However, that Model's main deliverable to our microController is that heart
rate. We don't care how he got it, we trust him to measure hearts.

At least in Nordic's implementations, and I would assume others, there is a
callback you register, associated with each characteristic. This callback's
job is to transfer the heart rate from the model, to the user of said heart.
So the callback is calling the highest level client call into the model,
uint16_t myHeartRate = getHeartRate(); Then the heart rate value is given to
the radio subsystem firmware, which is almost always code written and owned by
the chip vendor, whether thats TI, or Nordic, or whoever.

So, in summary, if you find that you've focussed on the View side of the MVC
world for your entire career, you will likely find both the model and the
controller very confusing. Your first instinct, like all novices, will be to
say "I'll show these guys how its done". So you'll eschew your own Design
Patterns, and attempt to bring the model and the controller back into the
view. Let me know how that works out. On the other hand, if you accept that
iPhones and Androids are actually just Views, you may come to realize that a
separation of concerns was a pretty ok idea after all.

~~~
nradov
How does Bluetooth compare to ANT+ in that regard?

~~~
flyingcircus3
Well, I kind of think of it as a distribution, just like debian, or mint, or
whatever. Even though they all say their the best Linux, as if that is somehow
tautological. The nRF52832 can do both Bluetooth and ANT, because they share
common lower level protocols.

I haven't used ANT in a project yet, but I've worked at places that have, just
on other teams. It has a more restrictive license, and you have to sign NDAs
to even get the key binaries. Thats not to say that Nordic's mainline BLE is
open source, but the closed source binaries are freely distributed.

My educated guess though is that Bluetooth developers have "tricked
themselves" into thinking they've mastered a design, when they've actually
just learned a little more about todays implementation. But as any nordic
developer knows, focusing for any measureable amount of time on SDK12 just
means you're gonna be super pissed when you hear about SDK13, and thats
because nRF decided to totally rewrite SDK14, which will eventually fail hard
enough long enough to convince them to spin up into SDK15.

But like they always say, Trust us, we only hire the best.

Edit: something something word word

~~~
mafaneh
What you're describing focuses too much on the implementation on a specific
platform. It's true that each vendor will provide their own way of doing
things (perfectly normal), and things will change as well (also expected). But
you have to also keep in mind that there is a lot that can be learned about
the Bluetooth protocol and technology itself that is independent of the
platform its implemented on. If the developer does not understand the protocol
and specification, then they will end up getting sucked into the
implementation of the specific platform. I don't work for Nordic nor have any
affiliation with them, but from my experience, their support is top-notch and
I love the community interaction and support they offer through their DevZone
site. No vendor is perfect, so it goes without saying that there will always
be pros and cons.

~~~
flyingcircus3
Believe me, I stick with Nordic, and I think they stand the best chance at
success. My overall point is that the system is basically at the point where
it is nearly impossible to be a generalist, and very painful to be a
specialist. So whats left?

The release of SDKs, and softdevices, and silicon are accelerating. If you are
supporting customers on SDK12, who have heard about the shiny new features of
SDK14, by the time you've signed the contract to do the migration, Nordic is
imminently releasing SDK16. Forget the odd numbers in between.

~~~
mafaneh
Some good points there. I agree that things are accelerating at a rapid pace
that's hard to keep up with!

~~~
flyingcircus3
I literally put my foot down with one of my fellow developers about a year
ago, because we kept wasting 30 minutes everytime we'd discuss some bug,
because he'd be referring to SD132v2, SDK11, NRF52832, but since I was
developing for a client that day who prefered SD132v3 SDK12 NRF52832, I kept
saying "dude, I promise you that bug does not exist", while he keeps screaming
"bro, I've got the breakpoint hit right now!!!".

Our solution was to standardize all of our conversations, by first saying,
52-132v3-12 has this bug, yadda, yadda. And that worked great for a couple of
months, until Nordic decided to release a better product, the nrf52840, but
couldn't find enough courage to make a unique name for it.

So, I predict that in the very near future, Universities everywhere will make
Linear Algebra and Deep Learning prerequisites for Introduction to C and
Embedded. Because thats the only way you'll ever stay ahead of anything for
more than an instruction cycle.

