Un fabricante le dirá que su sensor LoRaWAN funciona diez años con una sola pila. Puede ser cierto. También puede equivocarse por un factor de cinco con exactamente el mismo hardware, porque en LoRaWAN la duración de la batería es resultado de la configuración, no una especificación del hardware. La respuesta honesta a “cuánto duran estas baterías” está en algún punto entre cerca de un año y aproximadamente una década, y dónde se sitúe dentro de ese rango lo deciden la frecuencia con que el dispositivo transmite, la distancia a la que está de un gateway y si se permite que la red ajuste la radio por usted.
Así que la pregunta de planificación no es “cuánto dura la batería”. Es “qué le estoy pidiendo a este dispositivo y cuánta energía cuesta eso”. Si se equivoca, o sobredimensiona con baterías más grandes que no necesitaba, o despliega sensores que se apagan en campo un año antes de lo previsto. Esto es lo que de verdad determina la cifra, lo que cambia el Adaptive Data Rate y cómo detectar una batería agotándose antes de que deje un dispositivo inservible.
Qué agota realmente una batería LoRaWAN
Un sensor de bajo consumo pasa casi toda su vida dormido, consumiendo casi nada. La energía se va durante la transmisión. Por eso, todo lo que aumente cuánto tiempo o con qué frecuencia se enciende la radio es lo que le cuesta caro.
La frecuencia de uplink es la palanca más grande que controla directamente. Un sensor que reporta una vez por hora durará más que el mismo sensor reportando cada minuto, a menudo años más, porque dedica sesenta veces menos esfuerzo a transmitir. El tamaño del payload importa por la misma razón: un mensaje más largo tarda más en enviarse, y más tiempo en el aire es más energía.
La distancia al gateway determina el spreading factor, y el spreading factor determina el tiempo en el aire. Un dispositivo cerca de un gateway puede operar en SF7, terminar un mensaje rápido y volver a dormir. Llévelo al límite de la cobertura y subirá a SF12, donde el mismo mensaje permanece en el aire mucho más tiempo y consume mucha más energía, del orden de veinte veces más por cada transmisión. El sensor que “todavía conecta” al límite del alcance suele ser el primero en morir.
Los mensajes confirmados añaden un segundo coste. Cuando un dispositivo pide a la red que confirme cada uplink, tiene que mantener el receptor abierto para escuchar el downlink, y los downlinks fuerzan al gateway y al dispositivo a intercambios adicionales. Las ventanas de recepción son más baratas que la transmisión, pero no son gratis, y el tráfico confirmado en cada mensaje se acumula rápido. La mayoría de los sensores de campo no necesitan confirmación en cada lectura.
La temperatura es la silenciosa. Las pilas de litio pierden capacidad útil con el frío, y una química que parece correcta en el banco a temperatura ambiente se comporta distinto en un tejado en invierno o dentro de una caja recalentada por el sol. Los extremos en ambos sentidos acortan la vida real por debajo de la cifra de la hoja de datos.
Qué es el ADR y por qué importa
Adaptive Data Rate es la red decidiendo, en su nombre, los ajustes de radio de menor consumo con los que un dispositivo puede salir adelante y aun así ser escuchado. El network server observa la calidad de señal de los uplinks recientes de un dispositivo. Si llega con buena señal, el servidor le indica que baje a un spreading factor menor y a una potencia de transmisión menor. Un spreading factor menor significa menos tiempo en el aire. Menos potencia significa menos energía por transmisión. Ambas cosas ahorran batería, y el dispositivo sigue haciendo su trabajo.
Esto funciona porque muchos dispositivos operan mucho más conservadoramente de lo necesario. Un sensor atornillado a una pared a cien metros de un gateway en un tejado podría estar transmitiendo en SF10 por precaución cuando SF7 llegaría sin problemas. El ADR encuentra ese margen y lo aprovecha. Para un dispositivo fijo con cobertura estable, activar el ADR es casi vida de batería gratis, y es el ajuste que más vale la pena acertar.
El ADR está pensado para dispositivos que no se mueven y cuyas condiciones de radio se mantienen estables. Ahí es donde brilla y donde debería dejarlo activado por defecto.
Cuándo ayuda el ADR y cuándo no puede
El ADR funciona aprendiendo del historial, así que asume que el pasado reciente predice el futuro cercano. Esa suposición se sostiene para un sensor fijo y se rompe para uno en movimiento.
Un dispositivo sobre un activo en movimiento, un camión, un palet, una persona, ve sus condiciones de radio cambiar más rápido de lo que el ADR puede seguir. El servidor baja los ajustes del dispositivo para una ubicación con buena señal, el activo se mueve a una de señal débil, y ahora el dispositivo transmite demasiado bajo para ser escuchado. Para dispositivos móviles, la especificación LoRaWAN indica dejar el ADR desactivado y que el dispositivo gestione su propia tasa de datos, normalmente de forma conservadora.
El ADR tampoco puede arreglar una mala cobertura. Si un dispositivo está realmente al límite, encerrado tras hormigón o lejos de cualquier gateway, no hay ningún ajuste menor que darle. El servidor lo mantendrá en el spreading factor alto que necesita, y la batería paga el precio. El ADR optimiza dentro de la cobertura que tiene. No crea cobertura. Un dispositivo atascado en SF12 porque está en una zona muerta es un problema de cobertura, y la solución es un gateway mejor ubicado o adicional, no un ajuste de radio.
Pasos prácticos para alargar la batería
La energía más barata es el mensaje que nunca envía. Empiece por ahí.
Reduzca el intervalo de reporte a la cadencia más lenta que su caso de uso tolere. Una lectura de temperatura cada quince minutos en lugar de cada minuto es un ahorro grande para una medición que rara vez cambia tan rápido. Envíe por cambio o por umbral donde los datos lo permitan, para que un dispositivo se mantenga en silencio cuando no pasa nada.
Mantenga los payloads pequeños y desactive los mensajes confirmados salvo que la lectura tenga que confirmarse de verdad. Reserve la confirmación para el puñado de eventos que importan, no para la telemetría rutinaria. Active el ADR en cada dispositivo fijo y déjelo desactivado en cualquier cosa que se mueva. Coloque bien los gateways para que los dispositivos puedan mantener un spreading factor bajo, ya que la altura y la ubicación del gateway hacen más por la vida de batería de la flota que cualquier ajuste por dispositivo. Y dimensione la batería para el extremo frío del rango de temperatura que el dispositivo verá de verdad, no para el banco.
Vigile la batería antes de que muera
Todo lo anterior define cuánto debería durar una batería. Nada de eso le dice cuándo un dispositivo concreto en campo está a punto de fallar, y ese es el fallo que cuesta una visita al sitio y un hueco en sus datos.
La mayoría de los dispositivos LoRaWAN reportan el estado de la batería en su status, ya sea como nivel o como voltaje, junto con sus lecturas. TagoIO ingesta esa telemetría de batería igual que cualquier otra variable, a través de su network server LoRaWAN y de integraciones MQTT, y la almacena por dispositivo. A partir de ahí la pone en un dashboard, de modo que una flota de sensores muestra la batería actual de un vistazo y una línea de tendencia revela cuáles van cayendo. La parte que de verdad le ahorra el viaje al campo es la alerta: defina un umbral y TagoIO le avisa cuando un dispositivo lo cruza, mucho antes de que la pila se agote. Reemplaza una batería en una visita planificada en lugar de descubrir un sensor muerto después de que los datos ya se hayan perdido.
TagoIO es agnóstico respecto a la conectividad y vive del lado de la plataforma, así que una flota mixta de dispositivos LoRaWAN y celulares reporta la batería a un solo lugar con una sola configuración de alertas. Está certificado en ISO 27001 y alineado con GDPR para los equipos que necesitan esa postura. La radio decide cuánto dura la batería. La plataforma se asegura de que usted lo vea venir.
