Un proyecto de monitoreo remoto casi nunca falla por el sensor. Falla porque alguien dimensionó la energía del nodo, dimensionó por separado la energía del gateway, y se olvidó de que el sitio necesita un tercer consumidor, casi siempre el más grande de los tres: el enlace que saca los datos a internet. Ya explicamos cómo dimensionar batería, panel solar o alimentación fija para un nodo individual y por qué la autonomía solar real rinde menos que la de catálogo. Esta guía se enfoca en el paso que casi siempre se hace mal: sumar sensores, gateway y conectividad en un solo presupuesto energético, y elegir la tecnología de backhaul según cuánto le cuesta en vatios, no solo en dólares.
Un sitio remoto no es un nodo: es una pila de tres consumos
Cuando el gateway y los sensores están en la misma finca, camaronera o subestación sin acceso a red eléctrica ni fibra, el sistema de energía tiene que sostener tres cargas con perfiles muy distintos:
- Sensores/nodos LoRaWAN. Duermen casi todo el día y despiertan segundos para medir y transmitir. Consumo diario típico: pocos mAh/día por nodo.
- Gateway LoRaWAN. No duerme: escucha radio de forma continua en varios canales. Consume del orden de 2–5 W de forma sostenida, las 24 horas.
- Backhaul (la salida a internet). Aquí está la sorpresa: según la tecnología que elija, este tercer eslabón puede pesar lo mismo que el gateway o varias veces más, y casi nadie lo incluye en el cálculo inicial.
El error de diseño más común no es subestimar el sensor —ya hay suficiente literatura sobre eso—, es tratar el backhaul como un accesorio de red en vez de como una carga eléctrica que compite por el mismo panel y la misma batería que todo lo demás.
Cuánto pesa cada opción de backhaul
No todas las formas de sacar datos de un sitio remoto consumen igual. Compare:
- Celular NB-IoT / LTE-M para sensores individuales. Si lo que necesita es que un solo nodo reporte directo a la nube por celular (sin gateway LoRaWAN de por medio), estos estándares están diseñados para bajo consumo: en modo de ahorro de energía (PSM) caen a corrientes de reposo de pocos microamperios, similares a una radio LoRa dormida. El costo aparece en la transmisión: el módem celular tarda más en engancharse a la red que un uplink LoRaWAN Class A, y durante ese proceso exige picos de 100–250 mA, más largos que el pulso de un radio LoRa. Sigue siendo viable con batería si el nodo reporta pocas veces al día.
- Router celular 4G (Cat-1/Cat-4) como backhaul de un gateway. Aquí el perfil cambia por completo: el router tiene que mantenerse asociado a la red de forma prácticamente continua para que el gateway pueda entregar paquetes en cualquier momento. Un router 4G típico consume del orden de 2–6 W sostenidos, comparable al del propio gateway LoRaWAN, es decir, prácticamente duplica la carga continua del sitio.
- Radio punto a punto (por ejemplo, enlaces tipo Ubiquiti airFiber). Si existe línea de vista hacia otro punto con internet —una oficina, una torre, otra finca de la misma empresa— a distancias de unos pocos kilómetros, un enlace de radio dedicado puede consumir entre ~20 y 40 W continuos según el modelo y la banda, sin mensualidad de datos. Es la opción más eficiente en costo recurrente, pero exige infraestructura: mástil, alineación y, sobre todo, esa línea de vista que en terreno con vegetación, cerros o cultivos altos no siempre existe.
- Starlink. Entre ~20 W (Mini) y 50–75 W (estándar) continuos, sin necesitar línea de vista a nada más que el cielo. Es, con diferencia, el consumidor más grande del sitio, capaz de superar varias veces la suma del gateway y todos los sensores juntos. Ya cubrimos en detalle cómo dimensionar la energía de un backhaul Starlink; esta guía lo ubica en el contexto más amplio de comparar esa opción contra las demás.
La diferencia entre la opción más liviana (celular en PSM para un nodo suelto) y la más pesada (Starlink estándar) es de más de dos órdenes de magnitud en consumo continuo. Elegir mal el backhaul no es un detalle de cobertura: es la decisión que más impacta el tamaño del panel y la batería de todo el sitio.
El criterio de selección: cobertura antes que preferencia
Ninguna de estas opciones es “la mejor” en abstracto. El orden práctico para decidir es:
- ¿Hay señal celular utilizable en el sitio? En Ecuador, la cobertura 4G rural varía bastante entre operadoras y zonas; conviene verificar en sitio con una SIM de prueba antes de comprometerse, no confiar solo en el mapa de cobertura del operador. Si la señal es estable, celular suele ser la opción más barata en energía y en equipo.
- Si no hay celular, ¿existe línea de vista a un punto con internet a pocos kilómetros? Si la respuesta es sí y ya hay infraestructura propia en ambos extremos (torre, mástil, energía en el punto remoto de origen), un enlace punto a punto suele ganar en costo recurrente frente a una mensualidad satelital, aunque consuma más que el celular.
- Si no hay ni señal celular ni línea de vista, Starlink (o satelital equivalente) deja de ser una opción entre varias y se vuelve la única viable, sin importar que sea la más pesada del grupo. Ahí el diseño solar simplemente tiene que dimensionarse para ese consumo, como se explica en la guía específica.
Verificar el punto 1 antes de comprar nada evita el error más caro del proceso: instalar un sistema solar de gran tamaño pensado para Starlink en un sitio donde, en realidad, sí había señal celular estable y bastaba una fracción de ese presupuesto energético.
Cómo se arma el presupuesto energético total
El método es el mismo que para un solo nodo —consumo diario en Wh/día, HSP del peor mes del sitio, factor de pérdidas del sistema y margen de sobre-dimensionamiento—, pero aplicado a la suma de las tres cargas:
- Sume el consumo diario de cada capa por separado: nodos (mAh/día × cantidad), gateway (W × 24 h) y backhaul elegido (W × horas que debe permanecer activo). Un backhaul que solo necesita subir datos en ventanas —por ejemplo, cada hora, si la aplicación lo tolera— consume mucho menos que uno que debe permanecer asociado 24/7 para aceptar comandos entrantes.
- Convierta todo a la misma unidad (Wh/día) y súmelo. Es habitual que el backhaul, no el gateway ni los sensores, termine siendo el mayor renglón del total.
- Dimensione panel y batería con el HSP del mes más desfavorable del sitio, no del promedio anual, aplicando el factor de pérdidas real (derating térmico, suciedad, eficiencia del regulador) que ya detallamos en la guía de autonomía solar.
- Agregue redundancia con cabeza fría. Un failover celular-Starlink suena atractivo, pero si mantiene los dos radios encendidos todo el tiempo “por si acaso”, está pagando el consumo de ambos backhauls a la vez. Lo habitual es diseñar el respaldo para que se active solo cuando el enlace principal cae, no en paralelo permanente.
Un ejemplo de campo
Una estación de monitoreo de calidad de agua con tres sensores LoRaWAN, un gateway y un router 4G como backhaul, instalada en una zona con cobertura celular aceptable pero sin red eléctrica:
- Sensores (3 nodos, ~5 mAh/día c/u a 3,7 V): ≈ 0,06 Wh/día — prácticamente despreciable frente al resto.
- Gateway LoRaWAN (3 W sostenidos × 24 h): 72 Wh/día.
- Router 4G como backhaul (3 W sostenidos × 24 h): 72 Wh/día.
- Total del sitio: ≈ 144 Wh/día, casi el doble de lo que arrojaría dimensionar solo el gateway sin contar el backhaul.
Si ese mismo sitio no tuviera cobertura celular y necesitara Starlink Mini (~20 W continuos ≈ 480 Wh/día solo en el backhaul), el presupuesto total del sitio se multiplicaría por más de tres frente al escenario con router 4G. Es la diferencia entre un panel de un par de decenas de vatios y un arreglo bastante más grande, con su banco de baterías proporcional.
Conclusión
Dimensionar la energía de un sitio remoto no es dimensionar el sensor, ni siquiera es dimensionar el gateway: es sumar sensores, gateway y backhaul como un solo sistema y elegir la tecnología de conectividad sabiendo cuánto pesa en vatios, no solo cuánto cuesta en dólares al mes. La cobertura celular, cuando existe, casi siempre gana en energía; la radio punto a punto gana cuando hay línea de vista e infraestructura propia; y el satelital, con Starlink a la cabeza, resuelve los sitios sin ninguna de las dos opciones anteriores, al precio de ser el consumidor más grande del presupuesto.
¿Va a desplegar sensores, gateway y conectividad en un sitio sin red eléctrica ni fibra? Conozca el Yubox Sensor HUB y nuestros gateways LoRaWAN, o conversemos sobre su proyecto para dimensionar sensores, gateway y backhaul como un solo sistema desde el inicio.