aioble or low-level bluetooth for generic health device client on PICO-W?

[brianreinhold]

I need to write a generic client/central for health devices on a PICO-W. Some of these heath devices follow the BT SIG health device profiles but most are proprietary and one can never predict in advance what one might have to do in order to communicate with these devices.

The question is does the aioble high level library provide access to all the features of the low-level library such that proprietary devices can be handled? As I see it the advantages of the low-level library are

1. It closely follows the BTLE standards such that if you are familiar with the standards it is pretty easy to identify the APIs you need to use to do those tasks.
2. It follows the typical event callback structure used by a lot of BTLE APIs: Nordic (C), Renesas (C), and even Android (Java). If you have worked with those, the low-level API should be quite familiar.
3. It is likely to change primarily due to new features in the BTLE standard since it follows the standard quite closely
4. Hopefully it allows one to do all possible GAP and GATT transactions

The aioble lib, on the other hand, is completely unfamiliar to me and requires learning a set of unique APIs that apply only to it. It also appears to try and hide/simply the event nature of BTLE which means a considerable investment in learning its structure (which is difficult in a dynamically typed language because you don't know what the fields in the examples mean). On the other hand, the number of lines of code one has to write seems considerably smaller though it might take a while to get used to what the async/await operations hide and how to use them.

If one can do everything using aioble that one can do in the low level API, then it is probably worth the learning curve for aioble. Anybody have experience between using aioble versus the low-level API?

[andrewleech]

I've used Bluetooth in C on a few embedded platforms in the past, and have been involved in the development of Bluetooth support on stm here in micropython.

When aioble was first introduced here it was an absolute game changer for me, I think it's one of the best innovations in the entire Bluetooth industry to be honest. It dramatically simplifies BLE usage, especially for newer developers, and for me it provides significantly faster development of Bluetooth devices.

I believe aioble code is far easier to review and clearly see what characteristics are expected to do. At work, junior developers have been able to ramp up on (existing) aioble based code and add new characteristic handling easier, which is definitely not the case on traditional C embedded platforms I'm used previously.

To be fair, I was already a long term micropython developer and also very comfortable with asyncio usage.

I don't know for sure if there's "feature parity" with all underlying Bluetooth features, in fact I've still got a few open pull requests for additional features. It's a pretty light weight library though and easy to expand once you find your way through it!

[brianreinhold]

@andrewleech I can certainly understand that and I am sure that once you get used to it and become familiar with what objects and methods there are, it will become easier. My experience with async/await has only been with Angular typescript where the event loop is hidden. I don't know if it is a clear analog to the Python implementation but I have been spending this PM reading this absolutely excellent article
https://realpython.com/async-io-python/#the-10000-foot-view-of-async-io
on async/await.

Clearly I am biased by my experience with the use of C on embedded platforms and the Java APIs of Android which follow the classic callback nature of BTLE. The advantage (for me) is that I am very familiar with GATT/GAP and have worked on BT SIG health device standards and it is easy for me to see the correspondence between the standards and these APIs, including the low-level bluetooth micropython library, I could immediately understand how to use it, but using it would clearly take a LOT more coding effort.

THat being said, do you have any idea what the overhead introduced by the micropython is compared to using C SDK? It's hard to find much about the C SDK for Bluetooth/PICO. In the end this health device client will need not only handle the Bluetooth but make translations to HL7 FHIR and upload that to FHIR servers using cellular/wifi. Space and performance may become an issue. We are looking at the sixfab PICO LTE.

[andrewleech]

I've never looked at a C SDK for the Pico, these days I only use a C platform if a project needs an extreme cost down (large sell quantity) and gets forced to use a much smaller micro. Micropython speeds up development enough to be worth any overheads.

There's certainly some overheads to micropython in flash and ram use, most things are objects and the VM is running bytecode. It's pretty hard to see a processing speed difference on something as fast as the Pico though.

For more complicated data processing of there's speed issues I either use @native (https://docs.micropython.org/en/latest/reference/speed_python.html) or a quick user C module for just the fast loop stuff.
Float speed processing is limited without a hardware float engine in the Pico, but C isn't any faster there.

[jimmo]

@brianreinhold I wrote and designed both the low-level API and aioble.

I think if you're familiar with writing callback-based code, and if you understand BLE well (which you clearly do) then you'll probably have a pretty OK time with the low-level API.

One of the things I wish I could revisit is the way the arguments are passed to the various events (via the data tuple) as this doesn't give us a lot of flexibility to change things without breaking existing code (especially with the tuple-unpacking syntax I used in the examples).

If your app is already asyncio-based, then working with a callback-based API can be quite challenging. We wrote aioble largely because we were also developing asyncio and encouraging it as a good way to do embedded MicroPython development (and I definitely think this is true).

Making aioble wasn't simple but I'm pretty happy with how some of the common GATT use cases turned out to be very simple, and in particular l2cap CoC channels are quite straightforward. Unfortunately I moved onto other things before I could really finish a lot of the "fine details" (as you've already noticed, the pairing support is minimal) and a lot more documentation and examples would go a long way. I do plan to revisit it soon (my current project is to get the low-level API working on the Zephyr port and then do another round of aioble work).

One major thing that would make aioble much more useful would be to implement a library of common services, so the user would never see the underlying characteristics and data types. You'd just e.g. use the environmental sensing library.

[brianreinhold]

I would argue that providing support for decoding the millions of characteristics BT SIG has dreamed up should be of lower priority. BT SIG did not do much thinking when they dreamed up their profiles and there was often little consideration as to what was in one profile when they developed another one, even if they were quite similar in functionality - case in point compare the Glucose profile with that of the CGM. I wonder if they even talked to each other! This is especially true for health devices (my main interest) and the reason most manufacturers of health devices ignore the standards and develop proprietary solutions instead. Having a robust GAP/GATT/Security library works for EVERYTHING. Dealing with the annoyances of the individual profiles

Is the pairing support complete using the low-level API? It looks like it is when skimming through the documentation, but I have not tried to implement anything yet. There are not any examples that I have found that include pairing/bonding.

There are also some other questions I have that maybe you could help me with both with respect to the low-level and aioble libraries. These are mainly questions about who takes responsibility for various exchanges.

• On the central side, is the application responsible for maintaining service discovery information between connections or is that done by the library?
• Does the library handle storage of long term keys or is that handled by the library?
• Does the application handle resolvable private addressing or must the application do it (it will need the IRKs)?
• Does the client application need to handle the required generic access and generic attribute services (0x1800, 0x1801) or is this done by the library?
• How does the client library handle a security request? Is this passed up to the application or does the library invoke pairing/encryption?
• When receiving an insufficient authentication errors is the application responsible for invoking pairing or is this handled by the library?

Thanks for any help/clarifications!