Antes de empezar a explicar cómo crear un programa con App Inventor para que responda por Bluetooth con nuestra placa Arduino 101, vamos a intentar entender en qué se diferencia este nuevo modelo de Bluetooth BLE con respecto al antiguo que ibamos utilizando a través de la librería SoftwareSerial con el conocido módulo HC-05.
Durante el desarrollo de estos tutoriales utilizaremos la placa Arduino 101, pero estos modelos de programación se pueden desarrollar de la misma manera para los módulos Bluetooth HC-08, HC-10 y HM-10.
BLE (Bluetooth Low Energy) – Funcionamiento
El funcionamiento de los BLE difieren con respecto a los sistemas Bluetooth clásicos es que reducen su potencia.
En principio esta explicación no sirve de mucho ya que la comunicación con un Bluetooth clásico es tan sencilla como operar con el monitor serie y enviar y recibir datos desde los dos pines de recepción y transmisión.
Pero los BLE no funcionan de la misma manera, llegando a resultar algo más sofisticado y a la vez un poco más complejo.
Los módulos Bluetooth estándar realizan una comunicación asíncrona directa entre dos dispositivos a través de una comunicación serie. De manera que todo lo que se escribe desde el pin de transmisión ha de ser recopilado por la recepción de otro dispositivo sin asegurar un modo de gestión de eventos.
Es por ello, que los módulos clásicos gastan mucha más energía que los protocolos de BLE. porque están constantemente atendiendo la existencia de un dato recibido.
Se puede entender un dispositivo BLE como un tablón de anuncios al que otros dispositivos pueden acceder para leer o escribir información sobre ellos. A diferencia de los módulos Bluetooth tradicionales que se basaban en la comunicación Maestro- Esclavo.
En el siguiente esquema podemos ver un tablón denominado Peripheral. Este es el módulo Bluetooth del que se quiere obtener información y que es el creador del tablón de anuncios. Y los que están alrededor son otros modulos BLE denominados Central; que son los dispositivos que requieren información de este tablón. Una vez que se conectan al tablón pueden leer información o escribir sobre la misma de tal manera que el Peripheral puede observar el cambio.
*Esto no quiere decir que se permita comunicación múltiple. Las conexiones son exclusivas; es decir que un BLE Peripheral puede solo conectarse con un BLE Central en cada momento. En el momento que se conectan, el Peripheral deja de estar visible para otros módulos; hasta que la conexión se libere.
En cambio el central puede comunicarse con varios peripheral.
Dentro de este modelo, un dispositivo puede ejecutar el tablón. Se pueden entender a los Peripheral como lado servidor y los Central como el lado cliente.
Con este sistema, los clientes, buscan unicamente los datos que les son de interés haciendo que este intercambio de información dure unos pocos milisegundos.
Además de esto, el Peripheral puede dar permisos de lectura y/o de escritura para los Central.
Pero la ventaja más llamativa a considerar es que la programación se ejecuta mediante eventos, de manera que los módulos solo se activarán para intercambiar información solamente cuando haya información disponible.
Este modelo de eventos es beneficioso para ambos dispositivos y podremos diferenciarlo en App Inventor de la siguiente manera.
Estos son los eventos disponibles para el uso del Bluetooth estándar.
Esto quiere decir que para conocer cuándo se comunica otro módulo Bluetooth con nuestra aplicación será necesaria un Timer que vaya actualiando la existencia de un dato recibido en un periodo de tiempo definido por este Timer.
Para un módulo BLE, disponemos de la captura de los eventos que se muestran en las siguientes imágenes
Es por ello, que el módulo BLE ofrece algunas ventajas a cambio de profundizar en este modelo de comunicación.
En este contexto se podría decir que es sencillo de aplicar, pero vamos por partes. Para conseguir todo esto hay que atender varios módulos que integran este sistema y son los siguientes.
- BLEPeripheral → Se encarga de crear un tablón con servicios y características
- BLECentral → Se encarga de ejecutarse en modo lector
- BLEService → Anuncio identificativo mediante UUID
- BLECharacteristic → Contenido del anuncio
- BLEDescriptor → Es una manera de definición de atributos
Funcionamiento del modelo BLE
Como hemos visto en la imagen anterior, un módulo que actúa como Peripheral crea un tablón de anuncios. Dentro de este tablón de anunciós los mensajes se pueden distribuir con lo que se denominan Servicios. Los Services son el papelito clavado en una chincheta sobre el tablón.
En cada papelito podemos escribir muchos mensajes, es decir, que podemos alojar información variada. A cada uno de los mensajes se les llama Characteristic. Esta información puede ser de lectura, de escritura o basada en modo notificación.
Composición de Servicios – Como intercambiar información
Cada uno de los services y cada uno de los Characteristics contiene un UUID para ser identificado. De manera que el modulo “Central” se habrá de dirigir solo a ese anuncio del tablón para obtener una información específica.
Todos los servicios y todos los Characteristics se integran en el tablón como Atributos del mismo y se asocian entre sí para crear la estructura con sus UUIDs definidos.
UUID
El UUID es un identificador de 16 bit o de 128 bit definido por el estándar BLE.
Los UUID de 16 bits están registrados para operaciones concretas y se pueden consultar en la página oficial para Services y para Characteristics.
Para las aplicaciones personalizadas se han de utilizar identificadores de 128 bit, así que tendremos que inventarnos un número de serie muy largo.
Como consejo, para integrar un funcionamiento definido, podemos adoptar el siguiente modelo de definición de UUIDs, en el que solamente tenemos que cambiar los 4 últimos números de la primera porción del identificador.
O si no queremos pensar tanto, podemos escoger UUIDs aleatoriamente desde el siguiente enlace.
Tipado de Characteristics
Otro aspecto que nos proporciona robustez dentro de las librerías BLE es el tipado de los datos de comunicación.
Dentro de cada mensaje hay que definir explicitamente que tipo de dato es el que se va a contener en el mensaje. Ya no nos vale que todo sea una cadena de texto. Ahora hay que diferenciar entre los tipos de booleano, caracter, número o decimal, ya sea con signo o sin signo.
Aquí se puede ver la lista de tipos de datos posibles:
- BLEBoolCharacteristic
- BLECharCharacteristic
- BLEUnsignedCharCharacteristic
- BLEShortCharacteristic
- BLEUnsignedShortCharacteristic
- BLEIntCharacteristic
- BLEUnsignedIntCharacteristic
- BLELongCharacteristic
- BLEUnsignedLongCharacteristic
- BLEFloatCharacteristic
- BLEDoubleCharacteristic
LocalName
A la hora de registrar un peripheral podemos establecer un nombre para diferenciarlo de los demás sin necesidad de acceder a él mediante comandos AT. Esto se consigue con la función setLocalName.
ble.setLocalName(“BLE_IMU”);
Esta manera de abstraernos del mundo de los comandos AT, puede ser una de las mayores ventajas y e definitiva el BLE es una mejora dentro de las opciones disponibles. Pero ahora hay que ponerlo a funcionar y crear aplicaciones. Así que empezemos con ello en la siguiente lección.