Del ejemplo LoRa de 6 km a una FUOTA fiable: alcance, airtime y Delta OTA en un huerto de mandarinos

Los valores de alcance y los tiempos FUOTA de este artículo no sustituyen las mediciones de laboratorio o de campo. Todas las hipótesis deben recalcularse después de fijar el modelo real del dispositivo, la antena, el plan regional de frecuencias y las condiciones del canal.

Resumen

Al principio el problema parece sencillo: ¿puede un nodo sensor basado en LoRa enviar datos desde un huerto de mandarinos hasta un gateway? Cuando el producto llega al campo aparece una pregunta más difícil: ¿cómo se pueden distribuir cientos de kilobytes de firmware de forma fiable por la misma conexión?

Este estudio parte del ejemplo aproximado de 6 km para SF9/125 kHz del resumen técnico de Semtech. Explica por qué esa cifra no puede trasladarse directamente a un huerto denso de mandarinos y analiza el compromiso entre alcance y velocidad de datos de spreading factor (SF) y bandwidth (BW). También explica por qué un link budget no consiste en sumar las potencias de salida de dos dispositivos: hay que evaluar conjuntamente el transmisor activo, la sensibilidad del receptor opuesto, las ganancias de antena y las pérdidas ambientales. Después se elige un huerto de mandarinos entre varios entornos de cultivo y se analiza la altura de las antenas. Finalmente se propone Delta OTA en lugar de una imagen completa, actualizaciones en varios pasos y selección de rutas delta en el servidor.

El resultado principal es claro: el éxito de FUOTA no consiste solo en encontrar el mayor alcance. La capacidad downlink fiable, el airtime total, el duty cycle, la pérdida de paquetes, la ubicación del gateway, la verificación del bootloader y la orquestación de actualizaciones deben diseñarse juntas.

1. Por qué el ejemplo aproximado de 6 km de Semtech no es un alcance real en el huerto de mandarinos

El resumen técnico LoRa de Semtech ofrece un ejemplo de aproximadamente 6 km para SF9/125 kHz. El mismo documento señala que esas cifras dependen del terreno (Semtech, LoRa and LoRaWAN: A Technical Overview). Los 6 km son una referencia para una configuración de modulación concreta y condiciones idealizadas de espacio abierto; no son una garantía de alcance bidireccional fiable en un huerto de mandarinos.

Las razones principales son:

1. La propagación con línea de visión en terreno abierto no es igual que la propagación NLOS entre hileras de árboles.
2. Una antena de sensor cerca del suelo es distinta de la antena elevada del gateway utilizada en una prueba de catálogo.
3. El alcance del fabricante depende de un SF/BW, tamaño de paquete, antena y potencia determinados.
4. El alcance utilizable debe incluir la dirección más débil del enlace bidireccional y la tasa de éxito de paquetes deseada.
5. La humedad, la lluvia, el riego, la densidad del follaje y la orientación de las hileras cambian durante la temporada.

Estudios de campo en huertos de mandarinos y otros frutales han analizado cómo las hojas, ramas, troncos, geometría de las hileras y altura de las antenas afectan a la pérdida de propagación (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards; citrus orchard RF deployment study). Por tanto, la tabla de 6 km de Semtech puede ser una hipótesis inicial para las mediciones de campo, pero nunca el resultado.

La pregunta central cambia en consecuencia:

¿En qué link margin, tasa de éxito de paquetes y airtime FUOTA se convierte la referencia de 6 km en espacio abierto de Semtech dentro de un huerto denso de mandarinos?

2. ¿Cómo cambian el alcance SF y BW?

En la capa física LoRa, el spreading factor determina cuánto se distribuyen los datos sobre los símbolos chirp. El resumen de Semtech explica que, entre SF7 y SF12, un SF mayor mejora la sensibilidad del receptor, pero reduce el bit rate y la velocidad de transferencia (Semtech, LoRa and LoRaWAN: A Technical Overview).

La relación puede resumirse así:

Tabla numérica de SF/BW y alcance para un huerto de mandarinos

La siguiente tabla es una estimación de planificación de ingeniería para un huerto de cítricos de unos 2,5–4 m de altura, con vegetación densa, regada y presente durante todo el año. Las celdas tienen el formato alcance (m) / bit rate PHY bruto (kbit/s); para un diseño fiable debe tomarse como referencia el límite inferior del intervalo. El escenario de cálculo supone E22-900M22S/SX1262, 868 MHz, CR 4/5, ganancia de antena de 0 dBi, 2 dB de pérdidas de cable y conectores, 10 dB de margen adicional para fading y seguridad, y una antena que no está enterrada (información del fabricante del E22-900M22S).

El bit rate PHY procede de la relación R_b = SF × (BW / 2^SF) × 4/5 y no representa el throughput real de la aplicación. Las cabeceras LoRaWAN, el duty cycle, las esperas, las retransmisiones, los metadatos de fragmentación y la pérdida de paquetes reducen aún más la velocidad útil. Los alcances son estimaciones de planificación basadas en las hipótesis RF indicadas, no mediciones de campo ni valores garantizados para un huerto de mandarinos. Las columnas SF5–SF6 y BW250/BW500 son comparaciones de LoRa sin procesar; las combinaciones fuera de los data rates estándar de LoRaWAN EU868 deben comprobarse frente a los parámetros regionales.

Los parámetros regionales de LoRaWAN definen planes de canales, data rates permitidos, límites de potencia y restricciones regionales. Por eso una tabla SF/BW debe comprobarse frente a los parámetros de la región y la banda utilizadas (LoRa Alliance RP002 Regional Parameters; consulte las publicaciones del Technical Committee de LoRa Alliance para la lista actualizada).

¿Por qué importa ADR?

LoRaWAN Adaptive Data Rate (ADR) permite al network server ajustar el data rate y la potencia de transmisión de un dispositivo según la calidad del enlace. Semtech describe el objetivo como mantener el link margin necesario usando un data rate mayor para reducir airtime y consumo de capacidad de red (Semtech, Understanding LoRa Adaptive Data Rate).

Para FUOTA, la consecuencia es clara: un dispositivo solo debería pasar a SF12 cuando realmente lo necesite. Si el enlace es fiable en SF9 o SF8, el SF menor puede acortar la actualización.

3. Link budget: las potencias de los dos dispositivos no se suman

Las potencias de salida de Dragino y E22 no pueden sumarse sin más en un único cálculo. Cada dirección RF debe calcularse por separado:

potencia recibida =
potencia de salida del transmisor activo
+ ganancia de la antena transmisora
+ ganancia de la antena receptora
− pérdidas de cables y conectores
− pérdida de propagación
− pérdidas ambientales de follaje, troncos, suelo y otros elementos

Para E22 → Dragino se usan la potencia de salida de E22 y la sensibilidad del receptor Dragino. Para Dragino → E22 se usan la potencia de Dragino y la sensibilidad de E22. El alcance bidireccional utilizable lo determina la dirección más débil. Como la sensibilidad varía con SF, BW, coding rate y las condiciones de medición, un único valor de “alcance del dispositivo” es técnicamente incompleto. El resumen técnico LoRa de Semtech explica la relación entre parámetros de modulación, sensibilidad y bit rate.

Para los cálculos de campo de este artículo, no se debe asumir un valor nominal en dBm antes de fijar los modelos exactos de Dragino y E22, el tipo de antena, la potencia conducida y los permisos regionales. Las hojas de datos no sustituyen las mediciones de campo.

4. ¿Por qué tratar el tipo de cultivo como un problema RF independiente?

La misma configuración de radio no produce el mismo resultado en todos los entornos agrícolas. Las hojas, ramas, troncos, humedad del suelo, geometría de las hileras y lluvia pueden afectar a la dispersión, la absorción y el desvanecimiento multitrayecto. Hay estudios que analizan por qué la línea de visión suele no estar disponible en los frutales y por qué el follaje modifica la pérdida de propagación (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

Por eso consideramos primero estos cultivos como escenarios candidatos:

• maíz,
• remolacha azucarera,
• tomate,
• patata,
• sandía,
• pimiento,
• cebolla seca,
• uva,
• manzana,
• mandarina.

No es una clasificación de producción mundial. Es un conjunto de escenarios de ingeniería que combina necesidades de sensores, sensibilidad a riego/EC, valor económico y dificultad RF. Para cada cultivo creamos primero una tabla de alcance–bit rate para combinaciones SF/BW y después una tabla de airtime FUOTA para esas mismas combinaciones. Son estimaciones iniciales para orientar un plan de pruebas, no garantías de campo.

5. ¿Por qué un huerto de mandarinos?

Entre estos candidatos, un huerto de mandarinos es una buena prueba de estrés:

• los árboles son perennes y tienen un follaje denso,
• las hojas y ramas pueden ocupar la trayectoria RF durante gran parte del año,
• los nodos suelen instalarse cerca del suelo o del tronco,
• puede haber varias hileras entre el gateway y el nodo,
• la propagación a lo largo de una hilera no es igual que entre hileras.

La existencia de estudios RF en cítricos que consideran conjuntamente la posición del nodo, la altura de la antena, la profundidad de la vegetación y la distancia demuestra que la ubicación de la antena no puede explicarse solo por la distancia en metros (citrus orchard RF deployment study). Los experimentos de ubicación de sensores en cítricos también han registrado distintos niveles de señal recibida con diferentes alturas de antena y cobertura arbórea (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

La pregunta crítica ya no es “¿Cuántos kilómetros alcanza LoRa?”, sino:

¿Puede cada sensor del huerto de mandarinos conectarse con suficiente link margin y puede ese mismo downlink completar una transferencia de firmware larga?

6. Altura de antena: 1 metro, 5 metros y 50 centímetros

Colocar el gateway a 1 metro

Un mástil de aproximadamente 1 metro puede dejar la antena dentro de la capa inferior de troncos y follaje. Las hileras, ramas y hojas entran entonces directamente en la trayectoria de propagación. Ver la otra antena no significa que la zona de Fresnel esté despejada: las reflexiones del suelo y las hileras pueden seguir dominando.

Colocar el gateway a 5 metros

Una altura de aproximadamente 5 metros puede acercar la antena del gateway a las copas de muchos mandarinos o situarla por encima. Eso no crea automáticamente línea de visión en todo el campo, pero puede reducir los obstáculos del lado del gateway, la pérdida relacionada con el suelo y el efecto de las copas en la trayectoria horizontal. Las mediciones en frutales muestran que el efecto del follaje depende de si las antenas están cerca del suelo o de la copa (orchard foliage path-loss study).

Por tanto, un mástil de 5 metros no es un “multiplicador de alcance”. Su beneficio debe medirse junto con:

• si el gateway está en el borde, en el centro o al final de una hilera,
• si la antena está orientada paralela o perpendicularmente a las hileras,
• la ganancia de antena y el patrón de radiación vertical,
• la pérdida del cable coaxial y de los conectores,
• la pendiente del terreno y las reflexiones del suelo.

Colocar ambas antenas a 50 centímetros

La ventaja de 50 cm es que la antena puede quedar por debajo del follaje superior y utilizar el corredor entre los troncos. Pero “no atraviesa hojas” no significa “hay línea de visión”. A esta altura:

• los troncos y las ramas bajas pueden ser obstáculos directos,
• pueden aumentar las reflexiones del suelo y las pérdidas sobre suelo húmedo,
• un enlace entre hileras puede ser mucho peor que uno a lo largo de la hilera.

El escenario de 50 cm debe medirse en la misma ruta que los escenarios de 1 m y 5 m; no debe tratarse como una mejora teórica del alcance. En muchos frutales, una hipótesis razonable es orientar la antena del sensor hacia el corredor de la hilera, elevar la antena del gateway por encima de las copas y añadir un segundo gateway si hace falta. Es una hipótesis de diseño derivada de la dependencia de altura y orientación observada en estudios RF de frutales; debe validarse en campo.

7. Un enlace de telemetría no es un enlace FUOTA

Que un sensor pueda enviar regularmente un pequeño paquete de medición no significa que pueda descargar una imagen de firmware de 1 MB por la misma red. La telemetría suele ser un uplink poco frecuente; FUOTA es una operación larga, principalmente downlink, que necesita retransmitir los fragmentos perdidos.

Los dispositivos LoRaWAN Class A abren dos ventanas cortas de recepción después de un uplink. Los dispositivos Class C mantienen el receptor disponible durante más tiempo cuando no transmiten, por lo que el funcionamiento temporal en Class C resulta útil para una transferencia downlink grande (LoRaWAN Specification).

FUOTA no es un único comando de “enviar paquete de firmware”. Los bloques de LoRa Alliance separan las responsabilidades:

• TS004 Fragmented Data Block Transport: fragmentación de datos grandes y gestión de la sesión (TS004-2.0.0).
• TS005 Remote Multicast Setup: programación de multicast temporal y ventanas de distribución Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol: gestión de versiones de firmware y hardware, reinicio e imágenes de actualización (TS006-1.0.0).
• TS007 Multi Package Access: comunicación de paquetes y FPorts del dispositivo para transportar varios comandos con menos downlinks (TS007-1.0.0).

Usar estos estándares juntos requiere desarrollo adicional y validación HIL, con independencia del alcance RF.

8. El coste de una imagen de firmware completa de 1 MB

Un cálculo aproximado del límite inferior para un firmware completo de 1 MB es:

número de bits que se transfieren / bit rate teórico

Con 1 MB y 5,47 kbit/s, solo el tiempo de transferencia PHY es de unos 25,5 minutos. Si aplicamos un uso del canal del 10% como hipótesis de escenario, el límite inferior teórico aumenta a unas 4,25 horas. Esto excluye cabeceras LoRaWAN, metadatos de fragmentos TS004, paridad/redundancia, pérdida de paquetes, reintentos y configuración de la sesión Class C. Hay que comprobar la normativa regional y los límites de uso del canal para la banda y el país (RP002 Regional Parameters).

Por eso elegir la configuración FUOTA solo por “el mayor alcance” puede ser un objetivo equivocado. La mejor configuración minimiza el airtime total y conserva un link margin fiable.

9. Delta OTA: transportar la diferencia, no todo el firmware

Con Delta OTA, el servidor envía la diferencia entre la imagen base comunicada por el dispositivo y la imagen objetivo. El dispositivo aplica el parche para reconstruir el firmware objetivo:

firmware base del dispositivo
        +
parche delta
        ↓
firmware objetivo
        ↓
verificación SHA-256 y firma
        ↓
MCUboot test boot y confirmación de salud

El proyecto open source detools es un ejemplo de enfoque delta para sistemas embebidos: documenta la aplicación en streaming de parches secuenciales y la aplicación incremental en C para dispositivos con memoria limitada (detools README). En el proyecto Agronode, el flujo de creación y aplicación delta se define junto con el SHA base, el SHA objetivo, el tamaño de imagen y el layout de MCUboot (documentación Agronode Delta OTA, código de aplicación delta).

Las mediciones actuales del proyecto informan de deltas entre releases consecutivas de aproximadamente 15–53 KB frente a una imagen completa de aproximadamente 944 KB (documentación Delta OTA del proyecto). Esta medida es específica de esas releases; no se debe esperar la misma proporción para cada par de versiones.

Con el mismo valor PHY aproximado de 5,47 kbit/s:

No es una duración FUOTA real, sino una comparación de tamaños. La fragmentación, la paridad, los reintentos y la gestión de sesión añaden tiempo.

10. ¿Se pueden actualizar dispositivos muy antiguos con pequeños pasos Delta?

Sí, si existe una cadena delta adecuada:

1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → ... → 1.8.0

Cada flecha es una sesión FUOTA y una barrera de seguridad independientes. El servidor solo debería iniciar el siguiente parche después de que el dispositivo haya:

1. completado la sesión de fragmentación,
2. verificado el SHA base,
3. creado la imagen objetivo y verificado el SHA objetivo,
4. superado el test boot de MCUboot,
5. confirmado el firmware nuevo con un control de salud,
6. comunicado la nueva versión y la identidad de la imagen.

El flujo test–confirm–revert de MCUboot puede volver a la imagen funcional anterior en el siguiente arranque cuando falla una imagen nueva; es un patrón fundamental para reducir el riesgo de brick en actualizaciones remotas (documentación de diseño de MCUboot, firma de imágenes y herramientas de MCUboot).

La desventaja de una cadena de varios pasos es que la configuración de sesión, el airtime, la energía, el reinicio y el riesgo de fallo se repiten en cada paso. Si cada hop tiene una probabilidad independiente de éxito del 98%, la probabilidad de completar diez hops sin reintentos es aproximadamente 0,98^10 = 81,7%. No es una predicción de éxito en campo: es un modelo de cómo el número de hops multiplica el riesgo.

11. El modelo correcto es un grafo delta, no una lista de archivos delta

Conservar solo las releases adyacentes es un modelo sencillo:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

En producción es mejor conservar juntas las imágenes completas y varios tipos de delta:

1.0 ──→ 1.1 ──→ 1.2 ──→ 1.3 ──→ 1.4
 │                  │                  ▲
 └──── checkpoint ──┴── direct patch ───┘

Política recomendada de artifacts:

• Conservar una imagen completa y firmada para cada release.
• Conservar los deltas consecutivos N→N+1 como artifacts inmutables de larga duración.
• Generar deltas directos desde las versiones base realmente presentes en campo hasta la release más reciente.
• Conservar deltas puente desde versiones LTS/checkpoint seleccionadas hasta la release más reciente.
• Guardar con cada delta los metadatos de SHA base, SHA objetivo, placa, revisión de hardware, variante y geometría de particiones.
• No eliminar imágenes completas: siguen siendo la fuente canónica para generar deltas, hacer análisis forense y recuperar dispositivos.

En Agronode, el script de artifacts existente muestra cómo generar deltas directos desde las versiones base de campo (ensure_field_deltas.py). La política actual del backend busca una coincidencia directa base–objetivo; también hace falta un graph/path planner para planificar automáticamente A→B→C cuando existen A→B y B→C (ota_policy.py).

El servidor puede elegir la ruta con esta función de coste:

coste de ruta =
bytes totales de los parches
+ airtime estimado
+ coste de sesión/reinicio por hop
+ riesgo de pérdida de paquetes y fallo
+ energía del dispositivo y coste de mantenimiento

Una primera política práctica es usar un parche directo cuando exista y tenga un tamaño razonable. Si es demasiado grande, probar una ruta checkpoint con un máximo de 2–3 hops controlados. La imagen completa debe conservarse como vía de recuperación, bootstrap o transporte alternativo, no como “último recurso” automático por LoRa.

12. Barreras de seguridad necesarias para Delta OTA

Delta OTA no elimina los controles de seguridad; hace aún más importante la identidad exacta de la imagen base.

Como mínimo, hay que verificar para cada parche:

• el SHA-256 del firmware base comunicado por el dispositivo,
• el SHA-256 base esperado por el parche,
• la placa y la revisión de hardware,
• la geometría de particiones/slots,
• el SHA-256 del firmware objetivo,
• la firma MCUboot y la clave de firma permitida,
• que la versión objetivo cumpla la política de downgrade.

MCUboot verifica la integridad y la firma de la imagen y puede proporcionar rollback cuando un test boot no se confirma de forma permanente (documentación oficial de MCUboot). El código de aplicación delta debe rechazar incompatibilidades de base y layout antes de crear la imagen objetivo (aplicación delta de Agronode).

Para dispositivos muy antiguos también hace falta definir una versión bootstrap FUOTA. Si el firmware anterior no tiene cliente de fragmentación, código delta-apply o el soporte de bootloader necesario, el dispositivo no puede entrar directamente en la cadena delta. Primero debe actualizarse mediante BLE, Wi-Fi, red celular o una imagen completa controlada.

13. Una hoja de ruta práctica para este proyecto

Fase 1 — Fijar las hipótesis RF

• Confirmar los modelos exactos de Dragino y E22.
• Seleccionar la región y el plan de frecuencias.
• Medir la potencia conducida o verificarla en la hoja de datos.
• Registrar la ganancia de antena, la pérdida del cable y la polarización.
• Medir en la misma ruta del huerto de mandarinos los escenarios de 50 cm, 1 m y gateway a 5 m.

Fase 2 — Crear un mapa de conectividad de campo

• Registrar RSSI y SNR en cada punto de medición.
• Medir la tasa de éxito de paquetes y la dependencia de la dirección.
• Comparar condiciones secas, regadas, lluviosas y con distinta densidad de follaje.
• Medir una ruta a lo largo de las hileras y otra transversal.
• Definir por separado el link margin mínimo requerido para FUOTA.

Fase 3 — Completar el transporte FUOTA LoRaWAN

• Implementar la sesión de fragmentación TS004.
• Implementar con TS005 el ciclo de vida temporal Class C/multicast.
• Conectar la gestión de versión de firmware/reinicio de TS006 y el package discovery de TS007.
• Probar pérdida de fragmentos, reintentos, interrupciones y reinicio del gateway.
• No prometer éxito Delta FUOTA de extremo a extremo sobre LoRa antes de completar esta fase.

Fase 4 — Añadir artifacts delta y gestión de rutas

• Guardar cada release completa firmada como artifact canónico.
• Generar deltas adyacentes y deltas directos desde las bases activas de campo hasta la release más reciente.
• Mantener inmutables los metadatos delta con SHA base/objetivo e identidad de hardware.
• Implementar en el servidor la selección de parches directos y rutas multi-hop limitadas.
• Después de cada hop, esperar señales de versión, SHA, salud del boot y salud de la aplicación.

Fase 5 — Definir la métrica de éxito FUOTA

El éxito no debe significar solo “llegaron todos los paquetes”. Hay que informar conjuntamente de:

• bytes del parche y airtime total,
• tasa de pérdida de fragmentos y número de reintentos,
• tiempo de finalización de la actualización,
• consumo de energía,
• tasa de éxito del test boot,
• tasa de confirmación permanente,
• tasa de rollback,
• éxito por hop y total cuando se necesitan varios hops.

Conclusión

El problema LoRa en un huerto de mandarinos no es solo “¿Cuántos kilómetros podemos cubrir?”. SF y BW crean un compromiso entre alcance y bit rate; el follaje modifica el enlace teórico en condiciones de campo; la altura de la antena y la orientación de las hileras cambian el resultado; y FUOTA necesita una capacidad downlink muy distinta a la de los pequeños paquetes de telemetría.

Por eso la referencia de 6 km de Semtech y la distancia de actualización fiable en un huerto denso de mandarinos no describen la misma métrica. La arquitectura correcta combina un link budget RF medido, una altura adecuada del gateway, transporte FUOTA estándar TS004/TS005, barreras de seguridad MCUboot y un grafo de artifacts Delta OTA.

Cuando Delta OTA reduce una imagen completa de 1 MB a parches de unos 15–53 KB, puede reducir drásticamente el airtime FUOTA. Pero el algoritmo delta por sí solo no convierte esa ventaja en un producto fiable. El servidor debe conocer el SHA base exacto del dispositivo, elegir una ruta directa o multi-hop limitada, verificar cada hop y conservar la imagen completa como fuente de recuperación.

En resumen, el objetivo no es el mayor alcance, sino un sistema LoRaWAN capaz de ejecutar una actualización de firmware medible, repetible y reversible en un huerto de mandarinos.

Fuentes

Estándares y documentos técnicos de fabricantes

1. Semtech — LoRa and LoRaWAN: A Technical Overview
2. Semtech — Understanding LoRa Adaptive Data Rate
3. LoRa Alliance — RP002 Regional Parameters
4. LoRa Alliance — TS004 Fragmented Data Block Transport
5. LoRa Alliance — TS005 Remote Multicast Setup
6. LoRa Alliance — TS006 Firmware Management Protocol
7. LoRa Alliance — TS007 Multi Package Access
8. LoRa Alliance — LoRaWAN Specification v1.0.3
9. MCUboot — official documentation
10. MCUboot — boot design and test/revert flow
11. detools — sequential and incremental delta patching

Estudios de propagación RF agrícola

12. Influence of foliage on radio path losses for WSN planning in orchards
13. Test of WSN RF signal propagation based on different node deployments in citrus orchards
14. Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling