Batería en sensores LoRaWAN: cuánto dura y cómo alargarla

La batería en sensores LoRaWANProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil dura diez años según casi todas las fichas técnicas, pero muchos equipos mueren a los tres, y casi siempre por la radio.

La cifra de diez años no es mentira. Es un cálculo hecho en unas condiciones concretas: un mensaje cada cierto tiempo, una carga útil corta, buena señal y temperaturas suaves. Si cambia cualquiera de ellas, cambia el resultado, a veces por cinco. El problema es que nadie le dice al integrador qué supuesto falló hasta que mueren las primeras baterías en campo, normalmente todas a la vez y en los sitios más difíciles de alcanzar.

Esta guía explica adónde va la energía de un sensor LoRaWAN, qué parámetros pesan más y cómo estimar la duración para tu propio despliegue en lugar de fiarte del folleto. Incluye un ejemplo calculado con el mismo sensor en dos ubicaciones y una lista de ajustes que vacían baterías sin que nadie se dé cuenta. Da por sabido lo básico de cómo funciona LoRaWAN.

Batería en sensores LoRaWAN: de dónde salen los diez años

Detrás de cada cifra de duración en una ficha técnica hay un balance energético. Cuando leas «hasta 10 años», busca la nota al pie. Casi siempre dirá algo así: un uplink cada hora, una carga útil de unos diez bytes, spreading factor 7 u 8, 25 °C.

La pareja de condiciones del medio es la importante. Spreading factor 7 significa que el sensor está cerca de un gateway y con buena señal, así que cada transmisión es corta. En un despliegue real, una parte del parque siempre estará lejos de un gateway, detrás de un muro o dentro de un armario metálico. Esos equipos transmiten con spreading factors más altos, y cada uno de sus mensajes puede tardar más de 20 veces lo que dice la ficha.

Así que la forma honesta de leer una cifra de batería es como el mejor caso de un equipo con buena cobertura. Tu trabajo es calcular qué pasa con los que no la tienen, porque son los que van a generar visitas.

El cálculo no es complicado. Hacen falta cuatro números: cuánta corriente consume el equipo en cada estado, cuánto tiempo pasa en cada estado por mensaje, cuántos mensajes envía al día y cuánta capacidad útil tiene de verdad la batería.

Adónde va la energía: reposo, radio y sensor

Un sensor LoRaWAN de clase A pasa casi toda su vida dormido. Se despierta, mide, transmite, escucha un momento por si hay respuesta y vuelve a dormir. Cada una de esas fases cuesta energía.

De la tabla salen dos conclusiones.

La primera: el consumo en reposo pesa más de lo que parece. Cinco microamperios es muy poco, pero corre las 24 horas del día durante años. En un equipo que transmite cada 15 minutos con un buen spreading factor, el reposo puede ser la partida más grande del balance.

La segunda: la transmisión manda en cuanto la señal se debilita. La corriente de emisión es alta, y el tiempo de transmisión crece deprisa con el spreading factor. Un equipo que pasa de SF7 a SF12 multiplica por más de 20 la energía de cada transmisión.

El sensor también cuenta. Una sonda de temperatura lee en milisegundos. Un sensor de nivel por ultrasonidos, un sensor de gas que tiene que calentarse o una sonda que necesita unos segundos para estabilizarse puede gastar más que la radio. Mira el tiempo de estabilización en la ficha del propio sensor, no en la del módulo de radio.

Spreading factor: el ajuste que lo cambia todo

LoRa cambia velocidad por alcance mediante el spreading factor (SF). Cada paso de SF7 a SF12 duplica, más o menos, el tiempo que un mensaje pasa en el aire. El receptor puede decodificar señales más débiles, y por eso los equipos lejanos usan spreading factors altos, pero el emisor paga cada milisegundo de más.

Para una carga útil típica de unos 11 bytes en un canal de 125 kHz, el tiempo en el aire queda así. Puedes comprobar cualquier combinación con la calculadora de tiempo en el aire de The Things Network.

En la mayoría de redes el spreading factor no se fija a mano. Lo gestiona el servidor de red con el adaptive data rate (ADR): observa la calidad de señal de los últimos uplinks y le dice a cada equipo que use el spreading factor y la potencia más bajos que sigan llegando. En sensores fijos, el ADR es de lo más eficaz que hay para ahorrar batería.

El ADR tiene límites. Necesita una señal estable para funcionar bien, así que en equipos que se mueven suele desactivarse o restringirse. Y solo puede bajar el spreading factor hasta donde lo permite la cobertura: un sensor en un sótano seguirá en SF12 haga lo que haga la red. Eso es un problema de cobertura, no de configuración, y se arregla con una antena mejor colocada o con otro gateway. El método para medir la cobertura antes de instalar está en nuestra guía sobre el alcance LoRaWAN.

El spreading factor también afecta a la red, no solo a la batería. En Europa, la banda de 868 MHz impone un ciclo de trabajo, y las redes comunitarias añaden límites de uso justo. The Things Network, por ejemplo, documenta una política de uso justo de 30 segundos de uplink al día por equipo. Un equipo en SF12 que envía cada 15 minutos usa unos 142 segundos al día, casi cinco veces ese límite.

Un ejemplo calculado: el mismo sensor, dos duraciones

Toma un mismo diseño de sensor e instala dos unidades: una cerca de un gateway y otra en una arqueta al borde de la cobertura. Las dos envían un mensaje de 11 bytes cada 15 minutos, 96 mensajes al día. Los números de abajo son valores típicos para ilustrar, no medidas de un producto concreto.

Común a las dos:

• Batería: una pila AA de litio cloruro de tionilo, de unos 2.600 mAh nominales.
• Reposo: 5 µA, es decir, 0,12 mAh al día.
• Medida: 3 mA durante medio segundo por mensaje, unos 0,04 mAh al día.
• Transmisión a 40 mA.

Unidad A, cerca del gateway, SF7:

• Transmisión: 96 mensajes de 62 ms a 40 mA, unos 0,07 mAh al día.
• Ventanas de recepción y despertar: unos 0,03 mAh al día.
• Total: unos 0,26 mAh al día.

Sobre el papel, la pila duraría décadas. En la práctica, la autodescarga y la vida útil de la pila lo limitan mucho antes, así que la respuesta realista es que la batería dura más que el proyecto, normalmente entre 10 y 15 años.

Unidad B, en la arqueta, SF12:

• Transmisión: 96 mensajes de 1.483 ms a 40 mA, unos 1,58 mAh al día.
• Ventanas de recepción y despertar: más largas en SF12, unos 0,2 mAh al día.
• Total: unos 1,94 mAh al día.

Eso son unos 1.340 días, o 3,7 años, sin descontar nada por frío ni por envejecimiento de la pila. Con un margen razonable, la unidad B necesita un cambio de batería hacia el tercer año.

Mismo sensor, mismo firmware, mismo intervalo. Uno dura todo el contrato y el otro genera una visita en el tercer año. Multiplica la unidad B por la parte de tu parque que está al borde de la cobertura y tendrás tu presupuesto real de mantenimiento. En un proyecto de contador de agua inteligente, con contadores metidos en arquetas, esa parte puede ser grande.

La pila: química, temperatura y picos de corriente

El balance energético da por hecho que la pila entrega su capacidad nominal. Muchas veces no lo hace.

La mayoría de sensores LoRaWAN de larga duración usan pilas de litio cloruro de tionilo (Li-SOCl2). Tienen una densidad de energía muy alta, una curva de descarga plana a 3,6 V y una autodescarga de alrededor del 1 % al año, y por eso encajan en equipos de diez años. También tienen dos manías.

Pasivación. Durante periodos largos de consumo muy bajo se forma una capa fina dentro de la pila. Cuando la radio pide de golpe entre 40 y 120 mA, la tensión puede caer bruscamente antes de que la capa se rompa. Si cae por debajo del umbral de reinicio del equipo, el sensor se reinicia en plena transmisión. En campo, el síntoma es un equipo que se reinicia o vuelve a hacer join con regularidad aunque le queda capacidad de sobra.

Capacidad de pico. Las pilas de tipo bobina, las de más capacidad, no entregan bien picos de corriente altos. Los diseñadores añaden un condensador, o usan un pack con condensador de capa híbrida, que suministra el pico de emisión mientras la pila lo recarga despacio. Si estás eligiendo hardware, pregunta cómo resuelve el equipo el pico de transmisión.

La temperatura agrava los dos problemas. El frío reduce la capacidad disponible y empeora las caídas de tensión. Un sensor que funciona años en una oficina puede fallar en un invierno en un monte o dentro de un almacén frigorífico. Usa la capacidad a tu temperatura real de trabajo, no a 25 °C.

La autodescarga también entra en el balance. Con alrededor del 1 % al año, una pila pierde cerca de una décima parte de su capacidad en una década sin alimentar nada, y los meses en almacén antes de la instalación también cuentan. Un equipo que pasó un año en un almacén empieza su vida útil con menos de lo que supone la ficha.

La regla práctica: descuenta entre un 20 % y un 30 % de la capacidad nominal en un despliegue exterior normal, y más si el frío es sostenido.

Ajustes que vacían baterías sin avisar

Algunas de las peores pérdidas de batería vienen de la configuración, no del hardware. Estos son los primeros que hay que revisar.

• Uplinks confirmados. Pedir a la red que confirme cada mensaje duplica la actividad de radio en los dos lados y, cuando la confirmación no llega, provoca retransmisiones. Usa mensajes confirmados para las alarmas que de verdad lo necesitan, no para las lecturas rutinarias.
• Bucles de join. Un equipo que pierde la sesión y sigue intentando unirse por OTAA puede transmitir peticiones de join una y otra vez con spreading factors altos. Una clave mal configurada o un problema en el servidor de red pueden vaciar las baterías de un parque en semanas.
• Intervalos demasiado cortos. Enviar cada cinco minutos cuando el proceso cambia cada hora gasta batería y no aporta nada. Ajusta el intervalo al proceso y usa eventos para los cambios que no pueden esperar.
• Downlinks frecuentes. Cada downlink es una respuesta que el equipo tiene que recibir y muchas veces confirmar. Cambiar la configuración de vez en cuando está bien; consultar un equipo por downlink cada hora, no.
• Clase C por error. Los equipos de clase C mantienen el receptor encendido todo el tiempo. Es lo correcto para actuadores con alimentación de red y letal para un sensor a pilas.
• ADR apagado en equipos fijos. Sin él, los equipos pueden quedarse en un spreading factor alto mucho después de que mejore la cobertura, por ejemplo cuando se instala un gateway nuevo.

Nada de esto aparece en una prueba de laboratorio de pocos días. Aparece como un montón de baterías muertas un año después.

Cómo alargar la batería en sensores LoRaWAN en campo

La duración se decide en tres momentos: cuando eliges el hardware, cuando lo instalas y mientras operas el parque.

Al elegir el hardware:

1. Pide el cálculo de batería para tu intervalo, tu carga útil y el spreading factor que usarán tus peores equipos, no solo el mejor caso.
2. Comprueba el consumo en reposo y el tiempo de estabilización del sensor.
3. Pregunta cómo resuelve el equipo los picos de transmisión y el frío.

Al instalar:

1. Mide la señal en la posición real antes de cerrar la caja. Sacar una antena de un armario metálico puede bajar varios spreading factors al equipo, y cada paso hacia abajo reduce más o menos a la mitad la energía de transmisión.
2. Anota el spreading factor y la calidad de señal de los primeros uplinks de cada equipo. Esa línea base será tu aviso temprano más adelante.

Mientras operas:

1. Activa el ADR en los equipos fijos y comprueba que el servidor de red lo aplica.
2. Envía la tensión de la batería en la carga útil y vigila la tendencia de cada equipo, no solo un umbral absoluto.
3. Genera una alarma cuando un equipo deja de enviar, agrupada por zona para que la caída de un gateway no se convierta en cien incidencias.
4. Revisa cada pocos meses la distribución de spreading factors del parque. Si crece la parte en SF11 y SF12, la cobertura está empeorando, y las baterías irán detrás.

Casi todos estos datos salen del servidor de red, que ve la calidad de señal y el spreading factor de cada uplink. Cloud Studio IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil recibe los datos LoRaWAN a través de servidores de red externos como The Things Stack, LORIOT o ThingPark X, así que la tensión de batería que envía el equipo se puede guardar, representar y usar en reglas de alarma, junto con un aviso cuando un equipo se calla, con notificaciones por correo, SMS, WhatsApp, llamada de voz o push. Para ver dónde encaja el servidor de red, mira nuestra guía del servidor de red LoRaWAN. Para la cuestión más amplia de mantener un parque sano durante años, mira la gestión de dispositivos IoT.

Conclusión

La batería en sensores LoRaWAN es predecible si la calculas para los equipos difíciles de alcanzar, no para los fáciles. Lo esencial:

• Las cifras de la ficha son el mejor caso: cargas útiles cortas, intervalos largos, buena señal y temperatura suave.
• El spreading factor es la variable que más pesa. SF12 cuesta unas 24 veces el tiempo en el aire de SF7 para el mismo mensaje.
• El mismo sensor puede durar más de diez años cerca de un gateway y unos tres al borde de la cobertura.
• Descuenta capacidad por frío y por picos de corriente, y elige hardware que resuelva bien el pico de emisión.
• Los uplinks confirmados, los bucles de join, los intervalos cortos y la clase C por error vacían parques en silencio.
• Mide la señal al instalar, mantén el ADR en los equipos fijos y vigila las tendencias de batería y de spreading factor.

Si estás dimensionando un despliegue LoRaWAN y quieres revisar el balance energético o el plan de cobertura, mira nuestras soluciones LoRaWAN o habla con el equipo. Para el panorama general de los sensores IoT y lo que cambia cuando un parque crece, lee nuestra guía sobre escalabilidad IoT. La introducción técnica de Semtech a LoRa y LoRaWAN es una buena referencia sobre la radio.

Preguntas frecuentes

¿Cuánto dura la batería de un sensor LoRaWAN?

Depende sobre todo de la señal. En el ejemplo calculado de esta guía, el mismo sensor enviando cada 15 minutos dura de 10 a 15 años cerca de un gateway en SF7 y unos tres años en el borde de la cobertura en SF12. Las cifras de la hoja de datos son el mejor caso de un equipo bien cubierto.

¿Por qué las baterías LoRaWAN duran menos de lo que dice la hoja de datos?

Porque los diez años suponen un payload corto, un intervalo largo, buena señal y temperatura suave. Los equipos lejos de un gateway transmiten con spreading factors altos, y cada mensaje puede tardar más de 20 veces más en el aire. El frío, los uplinks confirmados y los bucles de rejoin la acortan todavía más.

¿Cómo afecta el spreading factor a la batería?

Cada paso de SF7 a SF12 duplica más o menos el tiempo que un mensaje pasa en el aire. Para un payload de 11 bytes, SF7 son unos 62 ms y SF12 unos 1.483 ms, alrededor de 24 veces la energía de transmisión para el mismo mensaje.

¿El ADR ahorra batería?

Sí, en sensores fijos. Con el adaptive data rate, el servidor de red le indica a cada equipo el spreading factor y la potencia más bajos con los que todavía llega. No puede bajar de lo que permite la cobertura: un sensor en un sótano se queda en SF12 hasta que mejore la posición de la antena o la cobertura del gateway.

¿Qué tipo de pila usan los sensores LoRaWAN?

La mayoría de los sensores de larga duración usa pilas de litio-cloruro de tionilo (Li-SOCl2): densidad de energía muy alta, una curva de descarga plana de 3,6 V y una autodescarga de alrededor del 1 % al año. Aguantan mal los picos de corriente, así que los diseñadores añaden un condensador, y el frío reduce la capacidad disponible.

¿Cómo se alarga la batería en un despliegue LoRaWAN?

Mide la señal en la posición real antes de cerrar la caja, deja el ADR activo en los equipos fijos, evita los uplinks confirmados en las lecturas rutinarias y ajusta el intervalo al proceso. Después vigila la tendencia de la tensión de batería y del spreading factor por equipo, y resta entre un 20 % y un 30 % a la capacidad nominal en exterior.