Building a GATT Server on Pi Pico W(vanhunteradams.com)
vanhunteradams.com
Building a GATT Server on Pi Pico W
https://vanhunteradams.com/Pico/BLE/GATT_Server.html
17 comments
GATT is great if you want to make yet another heart rate monitor. I was building a lock that worked over BTLE and I spent most of my time trying to get around the problems with GATT. It's been 8 years now but I believe that that there was a bunch of extra overhead that bloated the packets and the packets were too small. Resulted in too much back and forth etc. I really just wanted a socket. iOS eventually allowed you to interact directly with the Logical Link Control and Adaptation Protocol aka L2CAP. Seems like every time someone try to design a generic structure that does one job but is also extendable, it's a mess. Just give me the byte stream and move on. L2CAP doesn't seem to be accessible on the pico yet, https://github.com/micropython/micropython-lib/issues/803
It’s not a full generic GATT server but I implemented a server for temperature sensors with MicroPython if anyone is curious what that looks like. I have it running on two picos to collect data across my house and then I push it to a MQTT server. Honestly would love feedback too because it’s pretty gross and error prone.
https://git.tcrez.dev/tcrez/micropython/src/branch/main/temp...
https://git.tcrez.dev/tcrez/micropython/src/branch/main/temp...
When I last look at the description of the Pi Pico W from adafruit
https://www.adafruit.com/product/5544
it says:
"Bluetooth Low Energy - note this isn't supported in software yet, its just a hardware capability."
Yet this blog discusses BTStack so it must work at some level ... Can anyone clarify: if you want to use BLE on this device, is BTStack the only option or is this outdated info?
https://www.adafruit.com/product/5544
it says:
"Bluetooth Low Energy - note this isn't supported in software yet, its just a hardware capability."
Yet this blog discusses BTStack so it must work at some level ... Can anyone clarify: if you want to use BLE on this device, is BTStack the only option or is this outdated info?
It was enabled in mid 2023: https://www.raspberrypi.com/news/new-functionality-bluetooth...
I'm trying to understand what GATT is.
From what I've found in the links below, it looks Bluetooth 5.4 spec contains an Attribute Protocol (ATT) that allows for sharing of custom attributes between bluetooth devices. Attributes have a type identified by UUID, a server-specific 16-bit handle, a higher-level handle group, a value, and then permissions. Permissions specify read/write capability and requirements for encryption, authentication, and authorization. Generic Attribute Profile (GATT) is a service discovery/management framework built around ATT.
While wondering about what applications this is intended for, I found an example in Figure 2.2 the GATT spec (2nd link) showing a computer communicating with a sensor over bluetooth, so presumably, this is ATT and GATT are meant to improve IoT networks utilizing bluetooth. Appendixes A and B show examples of the protocol containing data for battery status, temperature sensors, and glucose monitors.
Is this the current state of the art for this type of information over Bluetooth, or is there something else that is currently being used?
I'd like to see a Pi Pico W bluetooth host for my custom split keyboards, and it obtaining from the the battery status to display on a small LCD/OLED display. The Nordic nRF52-based keyboards I have are already capable of reporting that type of information over bluetooth, so is that an example of GATT in the wild? Is GATT what's currently enabling my Apple Magic Trackpad and Pixel Buds Pro to report their battery status over bluetooth, or will GATT be the next generation of that capability?
Found in the Bluetooth 5.4 spec:
Part G. Generic Attribute Profile (GATT): https://www.bluetooth.com/wp-content/uploads/Files/Specifica...
Part F. Attribute Protocol (ATT): https://www.bluetooth.com/wp-content/uploads/Files/Specifica...
From what I've found in the links below, it looks Bluetooth 5.4 spec contains an Attribute Protocol (ATT) that allows for sharing of custom attributes between bluetooth devices. Attributes have a type identified by UUID, a server-specific 16-bit handle, a higher-level handle group, a value, and then permissions. Permissions specify read/write capability and requirements for encryption, authentication, and authorization. Generic Attribute Profile (GATT) is a service discovery/management framework built around ATT.
While wondering about what applications this is intended for, I found an example in Figure 2.2 the GATT spec (2nd link) showing a computer communicating with a sensor over bluetooth, so presumably, this is ATT and GATT are meant to improve IoT networks utilizing bluetooth. Appendixes A and B show examples of the protocol containing data for battery status, temperature sensors, and glucose monitors.
Is this the current state of the art for this type of information over Bluetooth, or is there something else that is currently being used?
I'd like to see a Pi Pico W bluetooth host for my custom split keyboards, and it obtaining from the the battery status to display on a small LCD/OLED display. The Nordic nRF52-based keyboards I have are already capable of reporting that type of information over bluetooth, so is that an example of GATT in the wild? Is GATT what's currently enabling my Apple Magic Trackpad and Pixel Buds Pro to report their battery status over bluetooth, or will GATT be the next generation of that capability?
Found in the Bluetooth 5.4 spec:
Part G. Generic Attribute Profile (GATT): https://www.bluetooth.com/wp-content/uploads/Files/Specifica...
Part F. Attribute Protocol (ATT): https://www.bluetooth.com/wp-content/uploads/Files/Specifica...
Bluetooth/BLE has the unique problem that you don't own the code on both sides of the wireless tx/rx. In webdev, you have control over client side and server side code and can make them work together in some unique way, without worrying about interoperability. But with Bluetooth/BLE devices, not only do you need to be able to communicate with random peers you've never seen before, those peers also need to be able to connect to countless other BT/BLE devices and read information about the services available on those devices. In order to enable this interoperability between BLE devices, a standardized format needed to be developed: GATT. GATT is the very highest layer of this interoperability and is considered "user-level" from the perspective of a BT firmware dev. In BT classic, the SDP table provides nearly the same service as GATT, except that data isn't carried over it, just service discovery.
GATT, at the lowest level, is a spec that allows you to access what is substantially a key-value store over bluetooth. It was part of the 4.0 spec.
Keys are 16-bit "handles", values are arbitrary byte bags. Handles may change between connections and are not considered stable, which is why there is a higher level of abstraction used. Each K-V pair is called an attribute.
On top of that simple kv-store, are built higher-level concepts like characteristics and services. A characteristic, for example, is made of a few attrbutes with sequential handles: a "header" attrbiute that declares that this is a "characteristic" and states how many next handles are part of it, a "name" attribute, which is a UUID, a "permissions" attribute, a "value" attrbiute, and possibly a "control" attribute that allows one to ask to be notified of value changes.
A "service" is a collection of attributes which describe one cohesive "thing"/feature/whatever.
Some "services" are defined in the spec and any device implementing them properly can talk to any device expecting to access them. But many devices use "manufacturer specific" services, mostly defeating the point.
GATT also specifies a number of operations to perform searches on this database, such as by-uuid, by-type, etc
Keys are 16-bit "handles", values are arbitrary byte bags. Handles may change between connections and are not considered stable, which is why there is a higher level of abstraction used. Each K-V pair is called an attribute.
On top of that simple kv-store, are built higher-level concepts like characteristics and services. A characteristic, for example, is made of a few attrbutes with sequential handles: a "header" attrbiute that declares that this is a "characteristic" and states how many next handles are part of it, a "name" attribute, which is a UUID, a "permissions" attribute, a "value" attrbiute, and possibly a "control" attribute that allows one to ask to be notified of value changes.
A "service" is a collection of attributes which describe one cohesive "thing"/feature/whatever.
Some "services" are defined in the spec and any device implementing them properly can talk to any device expecting to access them. But many devices use "manufacturer specific" services, mostly defeating the point.
GATT also specifies a number of operations to perform searches on this database, such as by-uuid, by-type, etc
I had a play with BLE a few years ago but found the entry point too high to get started with - do you know of any high-level introductions to the terminology and concepts (possibly illustrated or animated, as that seems make the data flows easier to grasp)?
the BT 4.0 (not later) spec chapter on GATT is relatively understandable.
In short, GATT is the main building block you use when moving data between devices over Bluetooth Low Energy.
Adafruit has an overview:
https://learn.adafruit.com/introduction-to-bluetooth-low-ene...
https://learn.adafruit.com/introduction-to-bluetooth-low-ene...
I spent a good part of a year working specifically with the Bluetooth GATT spec designing my own client and servers which would try to function as close to the spec as possible.
The spec is very bad, I'm sorry but I understand the amount of effort that must have gone into building it. There are blatant holes in the entire spec, documents are broken apart in some chaotic pattern where to implement a single ATT you need to reference 3 documents simultaneously(almost).
The documents have broken links or just flat out incorrect links. Worst part is, a lot of device manufacturers just yeet the GATT out the window and have custom UUIDs with custom everything which you'll never be able to implement properly with reverse engineering it.
Idk I think the spec is a good initiative marred by execution
The spec is very bad, I'm sorry but I understand the amount of effort that must have gone into building it. There are blatant holes in the entire spec, documents are broken apart in some chaotic pattern where to implement a single ATT you need to reference 3 documents simultaneously(almost).
The documents have broken links or just flat out incorrect links. Worst part is, a lot of device manufacturers just yeet the GATT out the window and have custom UUIDs with custom everything which you'll never be able to implement properly with reverse engineering it.
Idk I think the spec is a good initiative marred by execution
> Worst part is, a lot of device manufacturers just yeet the GATT out the window and have custom UUIDs with custom everything which you'll never be able to implement properly with reverse engineering it.
Sorry, I’m part of the problem. ^_^; If you read the BLE Developers Handbook, it paints a beautiful picture of a mesh of low power sensor devices that periodically advertise information, and it helped put the design of GATT into context for me. Of course, we had no interest in using GATT in that manner - we just wanted the other features of BLE. One fundamental issue is that if you want E2E transport encryption to a specific mobile app, LE bonding is no longer sufficient. So you start rolling your own crypto only to realize that negotiated MTU means your max datagram size is variable and dynamic. From there, you’re well on your way to implementing a custom transport layer on top of GATT. If you don’t horribly abuse GATT and use it for its intended purpose (like some of the standardized profiles on top of GATT), it works fairly decently.
Sorry, I’m part of the problem. ^_^; If you read the BLE Developers Handbook, it paints a beautiful picture of a mesh of low power sensor devices that periodically advertise information, and it helped put the design of GATT into context for me. Of course, we had no interest in using GATT in that manner - we just wanted the other features of BLE. One fundamental issue is that if you want E2E transport encryption to a specific mobile app, LE bonding is no longer sufficient. So you start rolling your own crypto only to realize that negotiated MTU means your max datagram size is variable and dynamic. From there, you’re well on your way to implementing a custom transport layer on top of GATT. If you don’t horribly abuse GATT and use it for its intended purpose (like some of the standardized profiles on top of GATT), it works fairly decently.
Just a BLE jargon that roughly equates to UDP/IP.
Equivalent in Rust: https://github.com/embassy-rs/embassy/blob/main/examples/rp/...
Nice to see an Apache-licensed solution for this. Thanks for sharing.