Prueba de campo Wi‑Fi HaLow

Introducción y contexto

Esta es la primera publicación de LUMA Lab. Antes de entrar en la prueba de Wi‑Fi HaLow, queremos dar el contexto mínimo para entender por qué llegamos hasta esta tecnología. Quien haya venido solamente por el experimento puede avanzar mediante el índice.

LUMA es un proyecto que desarrollamos desde 2024. Somos Mateo Archimaut y Sebastián Pérez, dos primos del interior de Uruguay que llevamos años trabajando juntos en distintas iniciativas. Esa experiencia terminó convergiendo en un proyecto para automatizar tareas que todavía dependen de observaciones y recorridas manuales.

Creemos que la inteligencia artificial, la robótica y los sistemas conectados van a asumir una parte cada vez mayor del trabajo humano. En el agro, esa transformación empieza por algo básico. Antes de automatizar una decisión hay que obtener información sobre lo que ocurre en el campo. Ahí encontramos el lugar de nuestro primer IoT, dispositivos capaces de observar condiciones del entorno y transmitir datos desde lugares donde hacerlo todavía es muy difícil.

El primer problema que elegimos fue el monitoreo de plagas. La idea inicial tomó como referencia una trampa Jackson para mosca de la fruta. Más adelante trabajamos sobre un diseño de tipo delta. Aunque tienen diferencias, ambas siguen una lógica conocida. Estas trampas, tal como las conocemos, funcionan con un atrayente que conduce al insecto hacia una superficie adhesiva que lo retiene. Las trampas se distribuyen en el terreno según el cultivo, la plaga y el protocolo de monitoreo. Luego una persona debe recorrerlas, abrirlas, observar qué cayó y registrar el resultado.

El procedimiento funciona y se utiliza desde hace años. Su límite está en la distancia entre lo que ocurre y el momento en que se conoce. Cuando existen muchas trampas distribuidas, obtener el dato exige visitarlas una por una. La información describe lo observado durante la recorrida, pero el campo continúa cambiando entre una visita y la siguiente.

Nuestra intención no era reemplazar el criterio del ingeniero agrónomo, sino entregarle información más frecuente y ordenada. Una imagen no decide qué hacer ante una plaga, pero puede reducir el tiempo necesario para detectarla. El valor no estaba solamente en evitar una recorrida, sino en dejar de depender de la próxima para saber, por lo que el objetivo del sistema era capturar imágenes, transmitirlas a un servidor y analizarlas mediante visión artificial para presentar información útil al responsable técnico.

En paralelo buscamos comprobar si el problema era reconocido por quienes trabajan con él. Realizamos una encuesta a 45 personas vinculadas a la producción y con participación en las decisiones. De ellas, 33 eran propietarias de establecimientos y 38 declararon que ya realizaban monitoreo de plagas. Dentro de ese grupo, 24 utilizaban trampas con feromonas y 20 empleaban sistemas de captura masiva con atrayentes. Las respuestas incluyeron productores de frutales de hoja caduca, hortalizas, cítricos y vid.

La encuesta también expuso la distancia entre el interés y la adopción. De las 45 personas, 32 no conocían dispositivos de monitoreo automático y solamente una declaró utilizar uno. Al preguntar por los beneficios esperados, 28 eligieron las alertas inmediatas ante la aparición de una plaga y 19 señalaron los mapas en tiempo real. Al concluir, 32 pidieron recibir información cuando existiera una versión validada. Estos resultados no demuestran intención de compra, pero indican que una parte relevante de la muestra comprendía el problema y el valor de recibir datos a tiempo.

Además de la encuesta, mantuvimos varias reuniones con especialistas de INIA y con Martín Lanfranco, referente técnico de la citricultura uruguaya. Esas conversaciones nos ayudaron a contrastar la idea con prácticas reales de monitoreo y a entender que una solución nueva tendría que demostrar confiabilidad, resistencia, bajo mantenimiento y compatibilidad con los métodos existentes.

El proyecto recibió también USD 5.000 y mentoría a través del VIN. Ese apoyo financió parte del desarrollo y nos permitió avanzar hacia un prototipo que pudiera salir del taller. Hasta ese momento teníamos un problema reconocido, una primera exploración de mercado y componentes que funcionaban por separado. Todavía faltaba evaluar cómo se comportaban juntos en el lugar para el que habían sido pensados.

El paso al campo cambió la naturaleza de las preguntas. Ya no alcanzaba con comprobar que la cámara tomaba una imagen o que un módulo podía transmitir datos. El sistema debía funcionar durante horas, administrar su energía y mantener la comunicación a distancia. La prueba no invalidó todo el trabajo anterior, pero reveló dos límites concretos: el consumo energético y la conectividad.

Dos prototipos, dos problemas

Ambos prototipos compartían un ESP32, una cámara, un módem 4G, una batería, un panel solar y regulación de voltaje. Con el primero probamos el montaje, la captura de imágenes, la transmisión, el consumo y el funcionamiento en exteriores cercanos. El segundo incorporó cambios en el circuito y conservó la forma y las dimensiones de una trampa delta convencional. Esta decisión surgió de una recomendación de INIA. La geometría influye en el ingreso de aire y en la dispersión del atrayente, por lo que no queríamos modificarla sin evidencia. Este segundo prototipo fue el primero que instalamos en una producción de manzanas.

Uno de los problemas fue el consumo energético. Según las mediciones que registramos durante el diagnóstico, el módulo Mini-360 basado en el MP2307DN consumía entre 15 y más de 40 mA en reposo, dependiendo de las tensiones de entrada y salida. El integrado mantenía activo su oscilador de 340 kHz incluso sin carga. Con una entrada de 12 V, el módulo llegó a consumir cerca de 0,9 W sin realizar trabajo útil. El módem 4G tampoco podía apagarse por completo. Aunque el ESP32 utilizaba modos de bajo consumo, la batería se descargaba en pocos días y el panel solar no alcanzaba a recuperarla.

La alimentación podía corregirse cambiando el regulador y desconectando físicamente los módulos mientras permanecieran inactivos. El segundo prototipo ya incorporó elementos adicionales, incluidos MOSFET, para mejorar ese control. Todavía era necesario medir el consumo total en cada estado antes de diseñar una placa propia.

El otro problema fue la conectividad. Probamos el dispositivo en un establecimiento de San José dedicado a la producción de manzanas, con Antel y Movistar. La conexión aparecía de forma esporádica, pero la señal era demasiado débil para transmitir imágenes con estabilidad. Los mapas generales de cobertura no representaban lo que ocurría en el punto exacto de instalación.

El consumo dependía de decisiones que podíamos cambiar dentro del dispositivo. La cobertura celular no. El 4G podía servir en algunos establecimientos, pero no ofrecía la continuidad necesaria para operar con independencia de la señal disponible en cada predio.

LoRaWAN tampoco resolvía el caso de uso. Su bajo consumo y alcance son adecuados para telemetría, conteos o mensajes breves, pero nosotros necesitábamos enviar imágenes de cientos de kilobytes. Fragmentarlas implicaba demasiado tiempo de aire, más reintentos y una transferencia poco práctica.

Así quedaron definidos los dos límites del prototipo: reducir el consumo total y encontrar una red capaz de transportar imágenes en el campo sin depender de la cobertura celular.

Por qué decidimos probar Wi‑Fi HaLow

La nueva red debía cumplir requisitos concretos. Tenía que conectar varios dispositivos alimentados con energía solar, atravesar la vegetación, cubrir distancias de cientos de metros y transportar imágenes de aproximadamente 200 a 600 KB. La latencia no era prioritaria. Para el caso de uso inicial bastaba con confirmar una imagen por día, aunque queríamos conservar la posibilidad de aumentar esa frecuencia.

Después de descartar la cobertura celular como base del sistema, buscamos alternativas en documentación, foros y conversaciones con personas que trabajan con redes de largo alcance alrededor del mundo. La tecnología apareció durante esa búsqueda y comenzó a tener sentido por la combinación de alcance, capacidad de transmisión y compatibilidad con redes IP.

Wi‑Fi HaLow es la denominación comercial de IEEE 802.11ah. Opera en bandas inferiores a 1 GHz y permite construir una red Wi‑Fi entre un punto de acceso y varios dispositivos. Para nuestro caso, la arquitectura podía separar el problema en dos tramos. Un gateway conectado a internet por Ethernet funcionaría como punto de acceso HaLow y las trampas se conectarían a él desde el campo. Así, los nodos no dependerían de cobertura celular ni de otra red pública. Bastaría con disponer de internet en algún punto del establecimiento, incluso mediante un enlace satelital, y extenderlo hacia el campo mediante HaLow.

El esquema permitía usar protocolos IP, un gateway basado en Linux u OpenWrt y herramientas conocidas para configurar la red, transferir archivos y administrar los dispositivos. También dejaba abierta la posibilidad de incorporar actualizaciones remotas, diagnóstico y otros equipos IoT. La contrapartida era un hardware más costoso y complejo que una radio diseñada solamente para enviar mensajes breves.

También consideramos el LR2021 de Semtech. Este chip incorpora FLRC, una modulación distinta de LoRa y LoRaWAN, con mayor velocidad de transmisión. En principio podía enviar una imagen mediante ráfagas breves y consumir menos energía que HaLow. A diferencia de HaLow, FLRC es una modulación y no una red IP completa. Para usarla en nuestro caso debíamos desarrollar o integrar una capa adicional que coordinara los nodos y asegurara la entrega de cada imagen. FLRC era reciente y contaba con menos equipos, bibliotecas y experiencias de campo disponibles para nuestro caso. HaLow ya podía comprarse en productos de evaluación y desarrollo, incluidos equipos de Heltec. Por eso decidimos probarlo primero. No concluimos que fuera superior. Elegimos la opción que nos permitía medir antes una red completa con hardware comercial y dejamos FLRC para una evaluación posterior.

Antes de comprar el equipamiento abrimos cuatro discusiones en Reddit. Las preguntas se centraron en el envío de imágenes, el consumo por transferencia, el efecto de la vegetación, la coordinación de varios nodos y la comparación entre HaLow y FLRC. En conjunto, los hilos registraron 33.200 visualizaciones, 44 puntos y 38 comentarios.

Las respuestas no demostraban que una tecnología fuera adecuada. Sí ayudaron a precisar qué debíamos medir. La unidad relevante no era solamente la velocidad del enlace, sino la energía necesaria para entregar una imagen completa bajo vegetación y con posibles reintentos. También señalaron que administrar entre 10 y 50 nodos podía eliminar parte de la ventaja de FLRC si exigía mantener un protocolo propio.

La decisión fue entonces acotada. Compramos hardware HaLow para comprobar alcance, estabilidad y transferencia de datos en condiciones reales antes de diseñar una PCB custom, una placa creada específicamente para el dispositivo.

La prueba de campo

Conectamos el módulo HaLow al nodo AP y, desde una computadora, accedimos a un servidor web que ejecutaba una aplicación de benchmark para el módulo. La antena era omnidireccional. Con esa configuración fuimos recorriendo el predio. En cada parada miramos si había enlace, cómo se sentía la conexión y si pasaban datos. Marcamos nueve puntos con GPS y después vimos las distancias en el mapa.

Hubo dos recorridos. El primero cubrió puntos a unos 140, 260 y 280 metros. El segundo partió de otra referencia y llegó hasta 640,1 metros. En total analizamos 69 pruebas.

Cerca de la antena el enlace anduvo bien: entre 2,5 y 2,9 Mbps. Cuando la señal bajó, los resultados empezaron a variar. Hacia −90 dBm este montaje se volvió más lento, más irregular y, a veces, falló. En los peores momentos, dos pruebas no pasaron nada y otra llegó a 0,013 Mbps después de esperar mucho. Eso describe este equipo en este lugar, no un límite del estándar.

En el punto más lejos el dispositivo seguía conectado. Una prueba a 640,1 m bajó a 0,218 Mbps y subió a 0,053 Mbps, pero en la misma tanda hubo fallas. Estar asociado no es lo mismo que servir.

En esta tanda analizamos 69 pruebas. La distancia máxima en el mapa fue 640,1 m. Cerca de la antena vimos 2,5 a 2,9 Mbps. El servicio se volvió frágil alrededor de −90 dBm.

El alcance de la tecnología es muy bueno: en condiciones ideales puede llegar hasta 3 km. Lo que más corta el resultado en campo son los desniveles y lo que hay entre la antena y el dispositivo: plantas, cortinas, una diagonal a las filas. En paralelo o con camino despejado la señal aguanta mejor. En diagonal o con cortina, se debilita aunque el punto esté cerca.

Hay que ser honestos: no es perfecto. No tiene el alcance de LoRa ni su estabilidad a largas distancias. Lo que hace, lo hace bien: entre 200 y 700 metros, con pocos obstáculos, cuando el caso pide mucha subida y bajada de datos.

Como pueden ver, más lejos no siempre fue peor. En el punto medio, a 353,1 m, atravesábamos cortinas y quedábamos más abajo. En el largo, a 534,4 m, más alto y con otro camino, funcionó mejor.

La bajada estaba a 531,8 m, casi lo mismo que el largo, pero con desnivel y maleza. Ahí las transferencias fallaron o casi no movieron datos.

No sabemos exactamente cuánto aporta cada factor. Sí vimos que un desnivel o un obstáculo cortan la señal muy rápido. Eso se mitiga con una antena direccional, reposicionando el punto o con otro nodo para esa zona. La distancia sola no alcanza para diseñar.

Para pensar una instalación hay que ser realistas: esto no es una cobertura definida. Ponemos la antena al medio y miramos hasta dónde llega en un extremo. Una cortina o una diagonal pueden dejar afuera un punto que en el plano parece adentro. A 640,1 m había tres o cuatro cortinas, una muy espesa.

Gran parte del recorrido la conexión respondía en 25 a 46 milisegundos. Eso no cuenta la historia completa: en una prueba se trabó 4,5 segundos y en otra 22,5 segundos. Entre un dato y el siguiente, cerca el hueco era de menos de un segundo; al borde llegó a unos 2,8 segundos. Una foto que puede llegar tarde quizá lo tolere. Un comando o una válvula, no. En diez segundos vimos 25 dB de variación en la señal: una lectura puntual no alcanza.

Al alejarnos, la subida se cayó antes que la descarga. Para una cámara, eso importa: la foto tiene que subir. Si la pregunta es cuánto tardaría una imagen, estos tiempos salen de la subida que vimos. Una transferencia real tardará más.

Precisión técnica

Arriba está la lectura. Acá, los números con los que la armamos. 69 pruebas únicas, de siete archivos, en dos recorridos y nueve puntos marcados con GPS. Las distancias son línea recta en el mapa, no el camino ni el relieve. Las paradas fueron estacionarias. En cada una miramos enlace, latencia, estabilidad, descarga, subida y señal.

La figura junta tres cosas que no se midieron juntas. LoRa, en campo y en documentación, suele quedar en décimas o centésimas de Mbps y empuja más kilómetros a cambio. FLRC, en la prueba pública de NiceRF (Shenzhen), aparece acá solo en 650 kbps Sub‑GHz: entre 876 m y 1,8 km el PDR fue 100/99/95 con payload de 255 B — más estable que 2,6 Mbps en ese ensayo, y todavía mucho más rápido que LoRa. HaLow, en esta tanda con vegetación, entregó décimas a ~1 Mbps útiles entre 350 y 535 m, falló en una bajada casi a la misma distancia que el “largo”, y a 640 m aún pasó datos con fallas en la misma tanda.

Los tiempos de imagen de la sección anterior son tamaño partido por la subida observada. No incluyen reintentos ni pausas. Los 3 km son techo en condiciones ideales, no un dato de este predio. Los diámetros de diseño son estimación, no cobertura mapeada.

El método no es del todo fiable. Una tanda, un predio, un montaje. Hacen falta más pruebas, en otras condiciones, para confirmar lo que vimos. Aun así nos sirve para ubicar dónde esta tecnología rinde: cuando hace falta más velocidad de datos, HaLow entra en un hueco que LoRa y otras radios de paquete corto no cubren.

Eso es todo por ahora. Más adelante, lo que sigamos midiendo.

Fuentes: siete exportaciones TOML del 1 y 2 de agosto de 2026; registro GPS de la prueba; fotografías del equipo; informe técnico interno de LUMA. Comparación externa (Figura 7): MDPI Sensors 2023 (HaLow vs LoRa); NiceRF LR2021 FLRC/LoRa range-PDR. Contexto de estándares: IEEE 802.11ah; Semtech LR2021; Semtech USP. Este borrador distingue resultados observados, interpretación e hipótesis pendientes.