Hacker News new | comments | ask | show | jobs | submit login
Show HN: Bluetooth 5 and Bluetooth Low Energy – A Developer's Guide (novelbits.io)
97 points by mafaneh 10 months ago | hide | past | web | favorite | 10 comments

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.

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

Yes and maybe.

A lot of the BLE5 spec like 2Mbps transfers is negotiated, and Apple specifically has an interest in always choosing the fastest reliable speed or biggest MTU.

SO YES, you are currently at the mercy of Apple and Android to support BLE5 which iirc only iPhone 8/X do for Apple - and yes, it’s confused that to be a “BLE5” device you don’t even need to use all BLE5 features - but it’ll get there.

I’m shipping a BLE5 device soon, it’ll be 99% BLE 4.2 features, it’ll update as available.

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.

How does Bluetooth compare to ANT+ in that regard?

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

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.

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.

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

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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact