bclose

Conceptos Bluetooth BLE

Presentando la jerga BLE

Conceptos básicos del Bluetooth BLE 

 

 
  • Veremos las diferencias entre Bluetooth Classic y BLE
  • Veremos qué es Bluetooth BLE
  • Modelo conceptual de BLE.
  • Estructura y conceptos BLE
  • Crearemos un servidor BLE.
 

 

Material requerido.

 

 Tienda EspañaTienda Mexico
 vista lateral del esp32
Un ESP32

 

Bluetooth

 

BlueTooth es un estándar inalámbrico de comunicación entre dispositivos electrónicos, al que, sin duda, todos los que estáis leyendo esto, estáis acostumbrados a usar porque viene en todos los móviles celulares desde hace generaciones.

Hay dos sabores de Bluetooth básicos:

 
  • Bluetooth Classic. El de toda la vida y el que habitualmente se ha usado en el mundo Arduino con los HC-06 y Hc-05 y que se corresponde con lo que en la sesión anterior presentamos como Bluetooth Serial en el ESP32.
  • Bluetooth BLE: O bluetooth de Baja energía (Bluetooth Low Energy) diseñado específicamente para consumir el mínimo posible y poder durar al máximo con baterías, de ahí lo de LOW Energy, además de ofrecer mejoras en las prestaciones del protocolo que iremos viendo. 

El modelo conceptual detrás de cada uno de ellos es completamente distinto y por eso vamos a dedicar una pequeña introducción a describir ese modelo aquí, porque es imprescindible comprender la organización y la jerarquía del BlueTooth BLE para poder programar un servidor o cliente (Que por supuesto se llaman de otra manera para que no se fácil y todo parezca mucho más complicado de lo que realmente es)

El Bluetooth Classic tiene un modelo como el mecanismo de un chupete:

 
  • Un Bluetooth servidor publica su disponibilidad
  • Un cliente Bluetooth busca ese servidor y se conecta
  • Los datos puede fluir ya en ambas direcciones.
  • Eso es todo.  

En el Bluetooth BLE, la cosa es un poco más complicada, aunque se mantiene la idea de servidores que ofrecen información y clientes que la buscan, pero que ahora se llaman de otro modo (Por joder). Además, el bluetooth BLE se ha diseñado para consumir el mínimo posible, pero también eso supone que el alcance va a ser inferior al Bluetooth Classic

Para entender Bluetooth BLE tienes que comprender que el modelo se ha refinado mucho y se ha jerarquizado y estructurado, para ofrecer una colección de servicios y características que amplíen el uso de la norma Bluetooth y eso naturalmente significa complicar un poco más el asunto.

Para crear e iniciar el servidor BLE, vamos a necesitar hacer todas estas tareas:

 
  • Crear el Servidor BLE.
  • Crear un Servicio BLE.
  • Crear una Característica en el Servicio BLE.
  • Crear un descriptor BLE en la Característica.
  • Arrancar el Servidor.   

Por eso tenemos que empezar hablando de un conjunto de nuevos acrónimos que harán que todo parezca super difícil, pero que va, son ideas bastante frecuentes en el mundo cliente servidor, pero adaptadas y con diferente nombre. Por eso nos conviene empezar hablando de uno de esos nuevos acrónimos: GAP protocol

 

Protocolo GAP

 

GAP viene de General Access Protocol (Protocolo de acceso general) y se encarga de que tu dispositivo vea los servidores y se puedan conectar. Para ello el GAP define varios roles para los nodos Bluetooth, que pueden ser:

 
  • Broadcaster: El dispositivo emite paquetes de disponibilidad e información para que otros nodos puedan conectarse a el. Un nodo Broadcaster no puede conectarse a otros dispositivos solo organizar que se conecten a el
  • Observer: El dispositivo rastrea la disponibilidad de bradcaster en sus proximidades y lo reporta a la aplicación, pero el no puede conectar, solo informar a la aplicación.
  • Peripheral device: Estos son pequeños dispositivos (Slaves) de bajo consumo, por regla general, que pueden conectarse a otros dispositivos. Es el caso de sensores, proximity tags etc
  • Central Device: Son quienes establecen y controlan la conexión con otros dispositivos (Clientes). Típicamente son los teléfonos móviles tabletas y similares que suelen ser mas potentes que el resto de roles. 

Los roles Peripheral y Central devices son los mas importantes y frecuentes en BLE y lo curioso de este modelo, es que por regla general, el cliente es computacionalmente más potente que el servidor, al revés de lo que es habitual en el modelo típico Cliente /Servidor en uso en las redes TCPIP.

Cuando un Peripheral quiere conectar con un Central, usa el protocolo GAP para establecer la conexión. Habrá un intercambio de paquetes entre ambos hasta que la conexión queda fijada y ahora se activa el protocolo GATT para realizar la transmisión de información.

 

Protocolo GATT

 

Los dispositivos BLE se reconocen y conectan entre si mediante GAP y luego se transmiten información mediante GATT, (Generic Attribute Profile) , y es quien se encarga fijar los procedimientos para que se puedan enviar y recibir datos entre dos dispositivos conectados con BLE, siempre que previamente se haya establecido la comunicación con GAP.

El mecanismo de conexión GATT es muy similar al modelo cliente / servidor al que estamos acostumbrados en la informática de servidores, y cualquier periferal puede ser considerado un servidor y un Central un cliente (Este es uno de esos casos en los que uno no puede dejar de pensar que los que pusieron los nombres eran imbéciles o con ganas de complicarlo todo)

Una vez que ya hemos establecido la comunicación con GAP, El protocolo GATT establece el método de comunicación y ahora nos falta entender que la comunicación se hace sobre Perfiles, Servicios y características (¿????)

 

Perfiles, Servicios y características

 

Si has trabajado algo con MQTT o JSON y similares, estarás familiarizado con las estructuras jerárquicas de datos, que, aunque inicialmente parecen complicadas, en realidad, contribuyen mucho a que haya un flujo organizado jerárquicamente de datos, que se puedan intercambiar entre dispositivos muy diferentes, con diferentes sistemas operativos, idiomas, y características, de forma sencilla y eficaz.

Lo que hace BLE es algo parecido orientado a conexiones a corta distancia, entre unos dispositivos bastante bien conocidos (Como relojes, teléfono, tablets, Pcs, cardiometros etc.) y otros no tanto. Y para ello define un modelo de datos que, aunque parece rarísimo no es para tanto.

Modelo conceptual BLE

Profiles: Son conjuntos de servicios definidos en directivas del Bluetooth SIG (Special interest Group) que clasifica servicios como (Sensores de presión sanguínea, o reproductores de Audio, niveles de batería y demás)

Services: Aquí es donde vienen los datos de sensores, por ejemplo, que a su vez tienen subcategorías, llamadas properties, values y descriptors.

Characteristics: Por ejemplo, un Sensor como el BME280, tiene disponibles lecturas de temperatura, humedad y presión barométrica. Cada uno de esos sensores a su vez dispone de propiedades y lecturas del valor correspondiente. Y aunque no es el caso podría tener un descriptor que anuncia su disponibilidad a los centrales que se conecten. Se trata de una estructura jerárquica similar a otras que ya hemos visto en Prometec:

Ejemplo de un sensor BME280

 

UUIDs

 

En Bluetooth BLE, absolutamente cada Servicio, Característica y descriptor, necesita un identificador único que lo diferencie del resto y a eso le llamamos UUID (Universally Unique Identifier), que es un número de 128 bits y que debe ser único para cada uno de esos elementos Bluetooth BLE.

Si vamos a hacer una aplicación propia necesitamos generar un UIID por cada servicio, característica y propiedad que definamos. Afortunadamente hay disponibles generadores aleatorios de UUIDs en Internet.

Y con todas estas extrañas (Y extravagantes) ideas nuevas metidas en nuestra mollera, podemos ya presentar el esquema general de cómo poner en marcha un servicio BLE.

 

Iniciando un Servidor Bluetooth BLE

 

Lo primero que vamos a hacer es cargar en nuestro ESP32 el programa de ejemplo que tenemos en:

\\Archivo\Ejemplos\Es32 BLE Ardunino\BLE_Server

Vamos a arrancar el servidor de ejemplo que viene con nuestro ESP32 BLE, pero antes vamos a buscar en ese programa la línea:

BLEDevice::init("Long name works now");

Que es el nombre que va a publicar en el BLE y que puedes cambiar por lo que quieras. En mi caso le voy a llamar (Sorprendentemente) Prometec.

BLEDevice::init("Prometec");

Ahora vamos a buscar la línea:

pCharacteristic->setValue("Hello World says Neil");

Que es donde ponemos el valor de la característica que hemos definido y pones lo que se os ocurra. Por ejemplo:

pCharacteristic->setValue("Pues, aqui. Probando el BLE, oyes");

Compila y carga el programa, y ya podemos descargar alguna aplicación de Explorador BLE, como nRF Connect for Mobile o bien el mas sencillo BLE Scanner. Yo voy a usar el primero, y al arrancar verás los dispositivos BLE disponibles,

Si pinchas (En mi caso ) a Prometec se conectará. Verás que se despliega un segundo menú, mostrándote atributos y servicios:

Atributos BLE

Cada una de esas líneas que ves, se puede desplegar para mostrar mas información. Si le das al Unknown service, se desplegará información al respecto y veremos el valor que pusimos más arriba (Pensando en este momento), y el identificador de la característica que pusimos en el programa:   beb5483e-36e1-4688-b7f5-ea07361b26a8

Caracteristicas BLE

Así que parece que nuestro servidor BLE funciona después de todo. Lo vamos a dejar aquí por hoy y en la próxima sesión veremos el programa en mas detalle .

 

 

IMAGEN DE MARCA