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.

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.