[HN Gopher] Building a GATT Server on Pi Pico W
       ___________________________________________________________________
        
       Building a GATT Server on Pi Pico W
        
       Author : vha3
       Score  : 36 points
       Date   : 2024-08-16 18:12 UTC (4 hours ago)
        
 (HTM) web link (vanhunteradams.com)
 (TXT) w3m dump (vanhunteradams.com)
        
       | evanjrowley wrote:
       | 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...
        
         | mplewis wrote:
         | In short, GATT is the main building block you use when moving
         | data between devices over Bluetooth Low Energy.
        
         | jwtorres wrote:
         | 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.
        
         | written-beyond wrote:
         | 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
        
         | dmitrygr wrote:
         | 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
        
       | MuffinFlavored wrote:
       | Equivalent in Rust: https://github.com/embassy-
       | rs/embassy/blob/main/examples/rp/...
        
         | evanjrowley wrote:
         | Nice to see an Apache-licensed solution for this. Thanks for
         | sharing.
        
       | clumsysmurf wrote:
       | 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?
        
         | trescenzi wrote:
         | It was enabled in mid 2023:
         | https://www.raspberrypi.com/news/new-functionality-bluetooth...
        
       | trescenzi wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2024-08-16 23:00 UTC)