Bluetooth Low Energy

01 · Punto de partida

Una radio que ya está en todos los bolsillos

En el tema 13 vimos que Bluetooth LE es la red de menor consumo por mensaje y la que más depende de una infraestructura cercana. Esa dependencia deja de ser un problema cuando la infraestructura es el celular del usuario: no hay que instalar nada, no se paga un abono y el teléfono se encarga de llevar los datos a Internet cuando hace falta. Por eso BLE domina los dispositivos personales (relojes, balanzas, sensores de actividad) y la configuración inicial de equipos de todo tipo.

BLE no es una versión «ahorradora» del Bluetooth clásico, sino un protocolo distinto, pensado para enviar pocos datos de vez en cuando con un gasto mínimo. Los dos no son compatibles entre sí: el clásico sirve para audio y transferencias continuas; BLE, para datos pequeños y esporádicos. Muchos chips (ESP32, nRF52840) implementan BLE, y los celulares modernos hablan ambos.

Los fragmentos de C++ usan la biblioteca BLE de Arduino para ESP32; los nombres de clases y funciones varían entre bibliotecas y versiones, y los conceptos son los mismos en cualquier plataforma.

02 · Roles y anuncios

Roles y anuncios (GAP)

La parte de BLE que define cómo los dispositivos se descubren y se conectan se llama GAP (Generic Access Profile). Establece dos pares de roles:

• Periférico: el dispositivo IoT. Se anuncia y espera que lo conecten. Casi siempre tiene poca memoria y batería.
• Central: el celular, el gateway o la computadora. Escucha los anuncios, elige a quién conectarse y dirige la comunicación.
• Emisor (broadcaster) y observador: versiones sin conexión de los anteriores. El emisor solo transmite avisos; el observador solo los escucha.

Un periférico comunica de dos maneras muy distintas:

El aviso es la unidad básica. En cada evento de aviso el periférico emite el mismo paquete en tres canales de radio dedicados, y repite el evento cada cierto intervalo de aviso (de decenas de milisegundos a varios segundos). Un intervalo corto hace al dispositivo fácil de encontrar rápido y gasta más; uno largo ahorra energía pero el celular tarda en descubrirlo.

Los avisos son también un canal de datos por sí mismos: un sensor de temperatura puede incluir el valor en el paquete de aviso y no conectarse nunca (esquema de beacon o baliza). Es el modo más económico y escalable, con la limitación de que los datos viajan sin protección. Sirve para valores que no son sensibles y que cualquier gateway cercano puede recoger.

03 · Datos organizados

Servicios y características (GATT)

Cuando un central se conecta, necesita saber qué puede pedirle al periférico. La respuesta la da GATT (Generic Attribute Profile), que organiza los datos como una jerarquía simple, como una carpeta con archivos:

• El servicio agrupa datos relacionados (por ejemplo, «sensado ambiental» o «batería»).
• La característica es un dato concreto dentro del servicio (por ejemplo, la temperatura). Tiene un valor y unas propiedades que dicen qué se puede hacer con ella: leer, escribir, recibir notificaciones.
• El descriptor agrega información sobre la característica; el más importante es el que el central escribe para activar las notificaciones.

Cada elemento se identifica por un UUID. Para los datos más comunes, el Bluetooth SIG definió identificadores cortos de 16 bits y formatos estándar: el servicio de Environmental Sensing (0x181A), la característica de temperatura (0x2A6E, un entero de 16 bits con signo en centésimas de grado) o el nivel de batería (0x2A19, un porcentaje en un byte). Usar los estándares permite que aplicaciones genéricas del celular lean tu sensor sin código a medida. Para datos propios se define un UUID de 128 bits único.

Observá el parecido con el tema 12: elegir un entero escalado de 16 bits para la temperatura es lo que hace el estándar. El valor de 21,37 °C viaja como el entero 2137, en dos bytes, en orden little-endian (el byte menos significativo primero).

#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

#define SERVICIO_AMBIENTAL  BLEUUID((uint16_t)0x181A)
#define CARACT_TEMPERATURA  BLEUUID((uint16_t)0x2A6E)

BLECharacteristic *temperatura;

void setup() {
  BLEDevice::init("Sensor-A1B2");                         // nombre que verá el celular
  BLEServer *servidor = BLEDevice::createServer();
  BLEService *servicio = servidor->createService(SERVICIO_AMBIENTAL);

  temperatura = servicio->createCharacteristic(
      CARACT_TEMPERATURA,
      BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_NOTIFY);
  temperatura->addDescriptor(new BLE2902());              // permite activar las notificaciones
  servicio->start();

  BLEAdvertising *aviso = BLEDevice::getAdvertising();    // empezar a anunciarse
  aviso->addServiceUUID(SERVICIO_AMBIENTAL);
  BLEDevice::startAdvertising();
}

void loop() {
  int16_t centesimas = (int16_t)round(leerTemperatura() * 100);   // 21,37 °C → 2137
  temperatura->setValue((uint8_t *)&centesimas, 2);             // dos bytes, little-endian
  temperatura->notify();                                          // avisa al celular conectado
  delay(10000);
}

El esquema es el de todo periférico BLE: se declaran los servicios y las características una sola vez, se comienza a anunciar, y en el bucle se actualizan los valores. La función notify envía el dato al central que activó las notificaciones, sin que éste tenga que preguntar.

04 · Conexión

La conexión: intervalos, MTU y notificaciones

Una vez conectados, el central y el periférico se turnan en eventos de conexión a intervalos fijos. Tres parámetros gobiernan la conexión y determinan el compromiso entre consumo, rapidez de respuesta y rendimiento:

Dos cosas más afectan los datos útiles. El MTU es el tamaño máximo de un mensaje: por defecto 23 bytes (20 útiles), y las conexiones modernas lo negocian hasta unos 247. Mensajes más grandes se parten en varios paquetes. Y las notificaciones son la forma eficiente de recibir datos: el central las activa una vez y el periférico las envía solo cuando hay un valor nuevo, sin que nadie pregunte. Preguntar cada tanto (leer en bucle) gasta energía en ambos lados.

El rendimiento real de BLE es modesto: del orden de decenas a pocos cientos de kilobits por segundo con los ajustes clásicos, y más con las capas físicas rápidas de BLE 5 (hasta 2 Mbit/s a corta distancia). BLE 5 trae también un modo de largo alcance (capa física Coded) que puede cuadruplicar el alcance a cambio de velocidad. Todo esto convive con el enfoque de siempre: pocos datos, de vez en cuando.

05 · Seguridad y privacidad

Seguridad y privacidad

Una radio abierta a cualquiera que pase cerca necesita defensas. En BLE se combinan varias capas:

• Emparejamiento (pairing) y enlace (bonding). Los dos equipos intercambian claves y las guardan para reconectarse más tarde con la conexión cifrada. El método más sencillo («Just Works», sin que el usuario confirme nada) cifra el enlace pero no protege contra un atacante que se interponga durante el emparejamiento. Los métodos que muestran o piden un código de seis cifras, o usan otro canal (como NFC), sí lo hacen.
• Conexiones seguras de BLE 4.2 en adelante (LE Secure Connections), con criptografía de curvas elípticas, son la opción recomendada para equipos nuevos.
• Permisos por característica. Cada dato puede exigir que la conexión esté cifrada o autenticada. Una característica que acciona una cerradura nunca debe ser escribible por un central sin emparejar.
• Privacidad de la dirección. Un dispositivo que se anuncia siempre con la misma dirección física puede rastrearse: quien lo lleve es seguible. BLE ofrece direcciones aleatorias que cambian cada cierto tiempo; solo los equipos emparejados pueden reconocerlas.
• Los avisos son públicos. Todo lo que va en un paquete de aviso lo lee cualquiera. Nada sensible va ahí; y si el valor identifica a una persona (un oxímetro, un rastreador), hay que pensarlo con más cuidado.

06 · Hacia Internet

BLE como puente a Internet

BLE no llega a Internet por sí mismo. Siempre hay alguien en el medio que traduce, y la elección de ese intermediario define el producto.

BLE es además la herramienta preferida de configuración inicial. En lugar de que el dispositivo cree una red Wi-Fi temporal (tema 14), el celular se conecta por BLE y le entrega la clave del Wi-Fi de la casa de forma cifrada. Es más cómodo para el usuario y evita cambiar de red en el teléfono. Muchos productos usan BLE para configurar y Wi-Fi para operar.

Un detalle para quien desarrolla la aplicación: los sistemas operativos móviles piden permisos específicos para usar Bluetooth (en Android, además, el permiso de ubicación en versiones antiguas) y restringen el trabajo en segundo plano para cuidar la batería del teléfono. Un diseño que dependa de que el celular lea el sensor cada minuto, con la app cerrada, no funcionará como se espera. Para lecturas continuas hace falta un gateway fijo.

07 · Analogía con programación

Calcular el consumo de BLE en Python

Cada actividad de la radio consume una cantidad pequeña y fija de energía. Un evento de aviso (tres canales) dura unos 1,5 ms a 8 mA. Un evento de conexión, 0,8 ms a 6 mA. Conectarse, entregar un dato y desconectarse lleva unos 50 ms a 8 mA. El chip dormido gasta 3 µA, y la fuente es una pila de botón de 220 mAh. El programa calcula los mAh por día y la autonomía de tres estrategias con distintos intervalos, y al final muestra cómo se codifica una temperatura de 21,37 °C como la característica estándar de 16 bits.

import struct

BATERIA_MAH = 220            # pila de botón tipo CR2032
SUENO_UA = 3                 # microcontrolador BLE dormido
AVISO_MAS = 1.5e-3 * 8       # un evento de aviso (3 canales): 1,5 ms a 8 mA, en mA·s
EVENTO_CONEXION = 0.8e-3 * 6 # un evento de conexión: 0,8 ms a 6 mA, en mA·s
CONECTAR_MAS = 50e-3 * 8     # conectar, enviar y desconectar: 50 ms a 8 mA, en mA·s


def mah_por_dia(modo, intervalo_s):
    dormido = SUENO_UA / 1000 * 24
    if modo == "aviso":                     # los datos van en el paquete de aviso, sin conexión
        eventos = 86400 / intervalo_s
        return dormido + eventos * AVISO_MAS / 3600
    if modo == "conectado":                 # conexión abierta con notificaciones
        eventos = 86400 / intervalo_s
        return dormido + eventos * EVENTO_CONEXION / 3600
    eventos = 86400 / intervalo_s           # se conecta solo para entregar cada lectura
    return dormido + eventos * CONECTAR_MAS / 3600


print("modo                   intervalo   mAh/día   autonomía (pila de 220 mAh)")
for modo, nombre in (("aviso", "solo avisos"), ("conectado", "conectado, notifica"), ("reconectar", "conecta en cada lectura")):
    for intervalo in (0.1, 1, 10, 60):
        mah = mah_por_dia(modo, intervalo)
        dias = BATERIA_MAH / mah
        texto = f"{dias / 365:.1f} años" if dias >= 365 else f"{dias:.0f} días"
        print(f"{nombre:<24} {intervalo:>5} s {mah:>9.3f}   {texto}")

temperatura = 21.37
crudo = struct.pack("<h", round(temperatura * 100))      # característica estándar: entero de 16 bits en centésimas
print()
print(f"{temperatura} °C se transmite como {crudo.hex(' ')} (2 bytes, little-endian)")

Resultado con los valores iniciales. Solo avisos: cada 100 ms la pila dura 75 días, cada segundo 1,7 años, cada 10 segundos 6,0 años y cada minuto 7,8. Conectado con notificaciones: con intervalo de 100 ms, 180 días; de 1 s, 3,2 años; de 10 s, 7,2 años; de 60 s, 8,2 años. Conectando en cada lectura: cada 100 ms, 2 días; cada segundo, 23 días; cada 10 segundos, 213 días; cada minuto, 2,6 años. La temperatura de 21,37 °C se codifica como los dos bytes 59 08 (el entero 2137 en little-endian). Estas cifras ignoran la autodescarga de la pila y su límite de corriente, que en la práctica recortan los años más largos.

Tres lecciones. Una: mantener la conexión abierta con intervalos largos es más barato que reconectar: cada reconexión cuesta 50 ms de radio, más de 30 veces un aviso. Otra: la frecuencia importa más que el modo: dentro de un mismo modo, pasar de 100 ms a 10 s multiplica la autonomía entre 15 y 100 veces. Y una tercera: conviene reconectar solo cuando las lecturas son poco frecuentes, de a un minuto o más.

08 · Exploración interactiva

Tres formas de entregar un dato, de extremo a extremo

Este laboratorio ejecuta el mismo modelo del código anterior. Elegí la forma de entregar los datos, el intervalo (de aviso, de conexión o entre lecturas, según el modo) y la autonomía que se pretende. Las barras comparan los tres modos con el mismo intervalo, en escala logarítmica; el elegido va resaltado y la línea naranja marca el objetivo. Los consumos son valores didácticos.

Recorrido guiado

1. Con los valores iniciales (conectado, 1 s, objetivo de 3 años), calculá. 0,187 mAh por día y 3,2 años: «Cumple». Una conexión abierta con eventos cada segundo es razonable para un sensor que notifica con frecuencia.
2. Pasá el intervalo a 100 ms: 1,224 mAh por día y 180 días. Diez veces más eventos, casi siete veces más consumo. Una respuesta rápida se paga cara.
3. Elegí Solo avisos con 1 s: 0,360 mAh y 1,7 años. Es casi el doble que la conexión, porque el aviso se emite en tres canales aunque nadie escuche. Con 10 s: 6,0 años y «Cumple».
4. Elegí Conectar en cada lectura con 60 s: 0,232 mAh y 2,6 años; con 10 s, 213 días. A mayor frecuencia de lectura, reconectar se vuelve inviable.
5. Con Conectar en cada lectura y 1 s: 23 días. Cuando se necesita un dato por segundo, hay que mantener la conexión abierta (3,2 años).
6. Con Conectado y 60 s, objetivo de 5 años: 8,2 años. Es el mejor caso del modelo, pero la frescura de los datos es de un minuto.

09 · Método de trabajo

Cómo diseñar un dispositivo BLE

1. Definí el intermediario: ¿celular, gateway fijo o ambos? De eso depende todo lo demás.
2. Elegí avisos o conexión: avisos para datos públicos y pequeños que lee cualquiera; conexión para datos mayores, comandos o seguridad.
3. Diseñá el perfil GATT: usá servicios y características estándar cuando existan, y UUID propios para el resto; agrupá lo relacionado.
4. Elegí los intervalos: el de aviso para que el celular descubra el dispositivo en tiempo razonable, y los de conexión (intervalo, latencia y supervisión) según la rapidez de respuesta que necesitás.
5. Usá notificaciones en lugar de lecturas repetidas, y mensajes compactos (tema 12) que quepan en el MTU.
6. Protegé: emparejamiento seguro, permisos por característica y direcciones aleatorias; nada sensible en los avisos.
7. Probá con aplicaciones genéricas de exploración BLE y con distintos celulares y versiones de sistema; los comportamientos varían bastante.
8. Medí el consumo real con un instrumento en cada modo; los parámetros que acepta el celular a veces difieren de los que pediste.

Un consejo práctico: empezá con una aplicación genérica de exploración BLE antes de escribir tu propia app. Si el celular ve tu servicio y lee la característica, el firmware está bien; si no, el problema está del lado del periférico.

10 · Comprensión

Confusiones frecuentes

11 · Práctica guiada

Predecí antes de comprobar

1. Avisos o conexión

Elegí avisos o conexión para: (a) un sensor de temperatura ambiente cuyo valor puede leer cualquier gateway de la oficina; (b) una cerradura que se abre desde el celular; (c) la entrega de la clave de Wi-Fi a un equipo nuevo.

2. Cuántos eventos

Un periférico se anuncia cada 1 s. ¿Cuántos eventos de aviso hace por día? ¿Cuánta carga gastan si cada uno consume 1,5 ms a 8 mA?

3. Codificar la temperatura

La característica estándar de temperatura usa un entero de 16 bits con signo en centésimas de grado. ¿Cómo se envían 21,37 °C y −5,20 °C?

4. Reconectar o mantener

Un sensor entrega una lectura cada 10 segundos. ¿Qué es más económico: mantener la conexión o conectarse en cada lectura? ¿Cuánto dura la pila en cada caso (modelo del tema)?

5. Notificar o preguntar

Una aplicación necesita la temperatura cada vez que cambia. ¿Qué es mejor, leer la característica cada segundo o activar las notificaciones?

6. Privacidad

Un pulsera de actividad se anuncia siempre con la misma dirección física. ¿Qué riesgo hay y cómo se resuelve?

12 · Síntesis

Ideas para recordar

¿Listo para el tema 16?

Antes de avanzar, instalá una aplicación de exploración BLE en tu celular, buscá algún dispositivo cercano (un reloj, auriculares) y recorré sus servicios y características. Identificá cuáles son estándar y cuáles propietarias, qué propiedades tienen y si el dispositivo se anuncia con datos. Es la mejor forma de entender GATT antes de programarlo.

En el próximo tema pasamos a las redes de largo alcance: LoRa, qué la hace llegar a kilómetros, cómo se calcula el tiempo de aire, qué límites impone la regulación y cuándo es la mejor red para un sensor remoto.