En muchas ocasiones trabajamos con tecnologías y conceptos que no llegamos a dominar por completo, pero que gracias a librerías y frameworks que nos abstraen toda la complejidad, conseguimos desarrollar aplicaciones totalmente funcionales.
Uno de los casos más comunes lo podemos encontrar con algo tan cotidiano como es el Bluetooth.
Si eres desarrollador, te gusta cacharrear con arduinos, raspberrys y temas relacionados con IOT, seguro que has trasteado con algún proyecto que hace uso del Bluetooth, pero siendo sinceros ¿Te has parado a pensar cómo funciona toda la comunicación o simplemente has integrado la librería XYZ y todo ha funcionado a la primera?
En internet existe mucha información, pero en unas ocasiones es muy dura y en otras es demasiado escueta o está mal estructurada.
Hoy queremos compartir una traducción libre del artículo “Introduction to Bluetooth Low Energy: A basic overview of key concepts for BLE” donde la gente de Adafruit hace un repaso sobre los conceptos en los que se basa BLE, que es lo que viene pegando fuerte de un tiempo a esta parte, y que nos vienen genial para entender mejor el código que programamos todos los días.
Link original: “Introduction to Bluetooth Low Energy: A basic overview of key concepts for BLE”
Introducción
Bluetooth Low Energy (BLE), a veces conocido como «Bluetooth Smart», se introdujo como parte de la especificación de Bluetooth 4.0. Aunque existe cierto solapamiento con el Bluetooth clásico, BLE proviene de un proyecto inicialmente desarrollado por Nokia y conocido como ‘Wibree’ antes de que fuera adoptado por Bluetooth SIG (Special Interest Group).
Existen un montón de protocolos wireless para uso en IOT, pero lo que hace que BLE sea tan interesante es que es el más sencillo para implementar la comunicación entre pequeños dispositivos y una aplicación en cualquier plataforma móvil actual (iOS, Android, Windows phones, etc.), y particularmente en el caso de los dispositivos Apple, es el único método que permite la interacción de periféricos con aplicaciones, sin necesidad de certificaciones MFI y otros requisitos legales que exige iOS.
Este artículo es una pequeña introducción a BLE, concretamente sobre cómo se organizan los datos y como los dispositivos anuncian su presencia y podemos recibir y transmitir datos.
Soporte de BLE
Bluetooth 4.0 y BLE son soportados en la mayoría de plataformas a partir de las versiones listadas a continuación:
- iOS5+ (iOS7+ preferred)
- Android 4.3+ (numerous bug fixes in 4.4+)
- Apple OS X 10.6+
- Windows 8 (XP, Vista and 7 only support Bluetooth 2.1)
- GNU/Linux Vanilla BlueZ 4.93+
GAP
Es el acrónimo para el Generic Access Profile, y se encarga de controlar las conexiones y los anuncios en BLE. GAP es lo que permite que tu dispositivo sea público hacia el exterior y determina como dos dispositivos pueden (o no) interactuar entre ellos.
Roles
El GAP define varios roles para los dispositivos, pero lo único que debemos tener claro es que vamos a tener dispositivos centrales y los periféricos.
- Los periféricos son dispositivos pequeños, de baja potencia, de bajos recursos, que pueden conectarse a dispositivos centrales mucho más potentes. Un ejemplo de periférico puede ser un glucómetro, un medidor de pulsaciones, un beacon, etc…
- Un dispositivo central se corresponde normalmente con un teléfono móvil o una tablet que y que tienen una capacidad de proceso mucho mayor
Transmisión de datos en GAP
Hay dos maneras de transmitir información a través de GAP: El Advertising Data payload y el Scan Response payload.
Ambos payloads son idénticos y pueden contener hasta 31 bytes, pero solo el advertising data payload es obligatorio, ya que es el payload que se transmite continuamente desde el periférico, para permitir que los nodos centrales en el alcance sepan de su presencia. El scan response payload es opcional y puede ser pedido desde un dispositivo central. De este modo los periféricos pueden transmitir información extra como el nombre del dispositivo o alguna característica especial definida por el fabricante.
Proceso de Advertising
Un periférico emite su Advertising Data payload a intervalos regulares configurables. Cada vez que el intervalo pasa, el periférico emite su Advertising Data payload.
Intervalos altos, permiten ahorrar batería, mientras que intervalos cortos, permiten ser más reactivos.
Si un dispositivo central necesita más datos y el periférico lo permite, puede solicitar adicionalmente el scan response payload, y el este contestara con la información adicional.
El modo Broadcast
Si bien la mayoría de los periféricos se anuncian para que se pueda establecer una conexión y se puedan utilizar los servicios y las características del GATT (lo que permite intercambiar mucha más información y en ambos sentidos), hay situaciones en las que sólo se desea anunciar datos (advertising).
El principal caso de uso, es cuando se desea que un periférico transmita datos a más de un dispositivo a la vez. Esto sólo es posible utilizando el Advertising Data payload ya que los datos enviados y recibidos en modo conectado sólo pueden ser vistos por los dos dispositivos conectados.
Incluyendo una pequeña cantidad de datos personalizados en los 31 bytes del advertising o scan payloads, podemos usar un periférico BLE para enviar datos unidireccionalmente a dispositivos centrales en el rango de alcance. Esto es lo que se conoce como Broadcasting in BLE.
Este es el modo utilizado por la especificación iBeacon de Apple, que introduce información personalizada en el advertising payload, usando el campo Manufacturer Specific Data.
Una vez que se establece la conexión entre un periférico y un dispositivo central, el proceso de advertising suele detenerse y usará los servicios y características del GATT para comunicarse en ambas direcciones.
GATT
GATT es el acrónimo de Generic Attribute Profile, y define la manera en que dos dispositivos BLE pueden comunicarse usando los Servicios y Características. La comunicación se realiza mediante un protocolo conocido como ATT, que se usa para almacenar los servicios, características y datos relacionados en una tabla usando identificadores de 16-bit para cada entrada en la tabla.
GATT entra en juego una vez se ha establecido una conexión dedicada entre dos dispositivos, lo que significa que ya hemos pasado previamente por el GAP.
Lo más importante a tener en cuenta con el GATT y las conexiones, es que las conexiones son exclusivas. Un periférico BLE sólo puede ser conectado a un dispositivo central (un teléfono móvil, etc) a la vez. Tan pronto como un periférico se conecta a un dispositivo central, dejará de anunciarse y otros dispositivos ya no podrán verlo o conectarse a él, hasta que se finalice la conexión existente.
Establecer una conexión también es la única forma de permitir la comunicación bidireccional, en la que el dispositivo central puede enviar datos al periférico y viceversa.
El modo Connected
El siguiente diagrama nos muestra como los dispositivos BLE funcionan en un entorno conectado. Un periférico sólo puede conectarse a un dispositivo central (como un teléfono móvil) a la vez, pero el dispositivo central puede conectarse a varios periféricos.
Si hay que intercambiar datos entre dos periféricos, será necesario implementar un sistema de buzón personalizado donde todos los mensajes pasen a través del dispositivo central. Sin embargo, una vez que se establece una conexión entre un periférico y un dispositivo central, la comunicación puede tener lugar en ambas direcciones, lo cual es diferente al enfoque de difusión unidireccional utilizando en GAP.
Transacciones GATT
Un concepto importante para entender en GATT es la relación servidor / cliente.
El periférico se conoce como el servidor GATT, que contiene los datos de búsqueda ATT y las definiciones de servicio y características, y el cliente GATT (el teléfono / tableta), que envía solicitudes a este servidor.
Todas las transacciones son iniciadas por el dispositivo maestro, el GATT Client (central) , que recibe la respuesta del dispositivo esclavo, el GATT Server (periférico).
Al establecer una conexión, el periférico sugerirá un ‘intervalo de conexión’ al dispositivo central, y el dispositivo central intentará volver a conectar cada intervalo de conexión para ver si hay nuevos datos disponibles, etc. Es importante tener en cuenta que esta conexión Intervalo es realmente sólo una sugerencia. Es posible que su dispositivo central no pueda cumplir la solicitud porque está ocupado hablando con otro periférico o los recursos del sistema necesarios no están disponibles.
El siguiente diagrama ilustra el proceso de intercambio de datos entre un periférico (el Servidor GATT) y un dispositivo central (el Cliente GATT), con el dispositivo central iniciando cada transacción:
Servicios y Características
Las transacciones GATT en BLE se basan en objetos anidados de alto nivel denominados Perfiles, Servicios y Características, que se pueden ver en la siguiente ilustración:
Perfiles
En realidad, no existe un Perfil en el propio periférico BLE, sino que es una colección predefinida de Servicios que ha sido especificada por el Bluetooth SIG o por el fabricante del periférico. Por ejemplo, el perfil de frecuencia cardiaca combina el servicio de frecuencia cardiaca y el servicio de información de dispositivos. La lista completa de los perfiles de GATT oficialmente adoptados puede verse aquí.
Servicios
Los servicios se utilizan para dividir datos en entidades lógicas y contienen trozos específicos de datos llamados características. Un servicio puede tener una o más características y cada servicio se distingue de otros servicios por medio de un ID numérico único denominado UUID, que puede ser de 16 bits (para servicios BLE adoptados oficialmente) o de 128 bits (para servicios personalizados ).
Se puede encontrar una lista completa de los servicios BLE adoptados oficialmente en la página del Portal de desarrolladores de Bluetooth. Por ejemplo, si observamos el Servicio de Frecuencia Cardíaca, podemos ver que este servicio oficialmente adoptado tiene un UUID de 16 bits de 0x180D, y contiene hasta 3 características, aunque sólo es obligatorio la primera: Medición de la frecuencia cardíaca, Sensor corporal Ubicación y Punto de Control de la Frecuencia Cardíaca.
Características
El concepto de nivel más bajo en las transacciones GATT son las características, que encapsulan un único tipo de dato (aunque puede contener una matriz de datos relacionados, como valores X / Y / Z de un acelerómetro de 3 ejes, etc.).
De forma similar a los Servicios, cada Característica se distingue a través de un UUID predefinido de 16 o 128 bits, y usted es libre de usar las características estándar definidas por el Bluetooth SIG (que asegura la interoperabilidad a través de HW / SW habilitado para BLE) O definir sus propias características personalizadas que sólo su periférico y aplicaciones entienden.
Como ejemplo, la característica de medición de la frecuencia cardíaca es obligatoria para el servicio de frecuencia cardiaca y usa un UUID de 0x2A37. Comienza con un único valor de 8 bits que describe el formato de datos HRM (si los datos son UINT8 o UINT16, etc.), y continúa incluyendo los datos de medición de la frecuencia cardiaca que coinciden con este byte de configuración.
Las características son el elemento principal que vamos a usar para interaccionar con nuestro periférico BLE, por lo que es importante entender el concepto. Pueden ser de solo lectura o de escritura. De esta manera se pueden usar para realizar comunicaciones bidireccionales de una manera muy sencilla.
En Solid GEAR cada vez desarrollamos más proyectos relacionados con Bluetooth, NFC, RFID y en próximos artículos os explicaremos con ejemplos como manejamos estas comunicaciones.
Más información
Articulo original: link
Documentación oficial Bluetooth SIG
- Bluetooth Core Specification
- Bluetooth Developer Portal
- Officially Adopted BLE Profiles
- Officially Adopted BLE Services
- Officially Adopted BLE Characteristics
Existe algún perfil de audio en Bluetooth 5 para poder hacer streaming a más de un dispositivo? La idea es hacer audio multiroom con Bluetooth