Dall’esempio LoRa da 6 km a una FUOTA affidabile: portata, airtime e Delta OTA in un agrumeto di mandarini

I valori di portata e i tempi FUOTA di questo articolo non sostituiscono le misure di laboratorio o sul campo. Ogni ipotesi deve essere ricalcolata dopo aver definito il modello reale del dispositivo, l’antenna, il piano di frequenza regionale e le condizioni del canale.

In sintesi

All’inizio il problema sembra semplice: un nodo sensore basato su LoRa può inviare dati da un agrumeto di mandarini a un gateway? Quando il prodotto arriva sul campo, emerge una domanda più difficile: come distribuire in modo affidabile centinaia di kilobyte di firmware sulla stessa connessione?

Questo studio parte dall’esempio di circa 6 km per SF9/125 kHz riportato nel riepilogo tecnico di Semtech. Spiega perché quel valore non può essere trasferito direttamente in un fitto agrumeto di mandarini, poi analizza il compromesso tra portata e velocità dati imposto da spreading factor (SF) e bandwidth (BW). Chiarisce inoltre perché un link budget non consiste nel sommare le potenze di uscita di due dispositivi: bisogna valutare insieme trasmettitore attivo, sensibilità del ricevitore opposto, guadagni d’antenna e perdite ambientali. Infine sceglie un agrumeto di mandarini tra diversi ambienti agricoli, discute l’altezza delle antenne e propone Delta OTA invece di un’immagine completa, aggiornamenti a più passaggi e selezione del percorso delta lato server.

Il risultato principale è chiaro: il successo FUOTA non consiste solo nel trovare la portata maggiore. Capacità downlink affidabile, airtime totale, duty cycle, perdita di pacchetti, posizione del gateway, verifica del bootloader e orchestrazione degli aggiornamenti devono essere progettati insieme.

1. Perché l’esempio di circa 6 km di Semtech non è una portata reale nell’agrumeto di mandarini

Il riepilogo tecnico LoRa di Semtech riporta un esempio di circa 6 km per SF9/125 kHz. Lo stesso documento precisa che questi valori dipendono dal terreno (Semtech, LoRa and LoRaWAN: A Technical Overview). I 6 km sono un riferimento per una specifica modulazione e condizioni idealizzate in area aperta, non una garanzia di portata bidirezionale affidabile in un agrumeto di mandarini.

Le ragioni principali sono:

1. La propagazione in linea di vista in terreno aperto non è uguale alla propagazione NLOS tra i filari.
2. Un’antenna del sensore vicina al terreno è diversa dall’antenna del gateway rialzata usata in un test di catalogo.
3. La portata dichiarata dal produttore dipende da SF/BW, dimensione del pacchetto, antenna e potenza specifici.
4. La portata utilizzabile deve includere la direzione più debole del collegamento bidirezionale e il tasso di successo dei pacchetti desiderato.
5. Umidità, pioggia, irrigazione, densità delle foglie e orientamento dei filari cambiano durante la stagione.

Studi sul campo in agrumeti e altri frutteti hanno analizzato l’effetto di foglie, rami, tronchi, geometria dei filari e altezza delle antenne sulla perdita di percorso (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards; citrus orchard RF deployment study). La tabella dei 6 km di Semtech può quindi essere un’ipotesi iniziale per le misure sul campo, ma non il risultato.

La domanda centrale cambia di conseguenza:

In quale link margin, tasso di successo dei pacchetti e airtime FUOTA si trasforma il riferimento di 6 km in area aperta di Semtech dentro un fitto agrumeto di mandarini?

2. Come cambiano la portata SF e BW?

Nel livello fisico LoRa, lo spreading factor stabilisce quanto i dati vengono distribuiti sui simboli chirp. Il riepilogo di Semtech spiega che, nell’intervallo SF7–SF12, un SF più alto migliora la sensibilità del ricevitore ma riduce bit rate e velocità di trasferimento (Semtech, LoRa and LoRaWAN: A Technical Overview).

Il rapporto può essere riassunto così:

Tabella numerica SF/BW–portata per un agrumeto di mandarini

La tabella seguente è una stima ingegneristica di pianificazione per un agrumeto di circa 2,5–4 m di altezza, con vegetazione densa, irrigata e presente tutto l’anno. Le celle sono nel formato portata (m) / bit rate PHY lordo (kbit/s); per una progettazione affidabile va considerato il limite inferiore dell’intervallo. Lo scenario di calcolo assume E22-900M22S/SX1262, 868 MHz, CR 4/5, guadagno d’antenna di 0 dBi, 2 dB di perdite tra cavo e connettori, 10 dB di margine aggiuntivo per fading e sicurezza e un’antenna non interrata (informazioni del produttore E22-900M22S).

Il bit rate PHY deriva dalla relazione R_b = SF × (BW / 2^SF) × 4/5 e non rappresenta il throughput reale dell’applicazione. Header LoRaWAN, duty cycle, tempi di attesa, ritrasmissioni, metadata dei fragment e perdita di pacchetti riducono ulteriormente la velocità utile. Le portate riportate sono stime di pianificazione basate sulle ipotesi RF indicate, non misure sul campo né valori garantiti per un agrumeto di mandarini. Le colonne SF5–SF6 e BW250/BW500 sono confronti LoRa grezzi; le combinazioni non comprese nei data rate LoRaWAN standard EU868 devono essere verificate rispetto ai parametri regionali.

I parametri regionali LoRaWAN definiscono piani dei canali, data rate consentiti, limiti di potenza e restrizioni regionali. Una tabella SF/BW deve quindi essere verificata rispetto ai parametri della regione e della banda utilizzata (LoRa Alliance RP002 Regional Parameters; per l’elenco aggiornato vedere le pubblicazioni del Technical Committee LoRa Alliance).

Perché ADR è importante?

LoRaWAN Adaptive Data Rate (ADR) consente al network server di regolare data rate e potenza di trasmissione in base alla qualità del collegamento. Semtech descrive l’obiettivo come il mantenimento del link margin richiesto usando un data rate maggiore per ridurre airtime e consumo di capacità di rete (Semtech, Understanding LoRa Adaptive Data Rate).

Per FUOTA l’implicazione è netta: un dispositivo dovrebbe passare a SF12 solo quando ne ha davvero bisogno. Se il collegamento è affidabile a SF9 o SF8, lo SF più basso può abbreviare l’aggiornamento.

3. Link budget: le potenze dei due dispositivi non si sommano

Le potenze di uscita di Dragino ed E22 non possono essere semplicemente sommate nello stesso calcolo. Ogni direzione RF deve essere calcolata separatamente:

potenza ricevuta =
potenza di uscita del trasmettitore attivo
+ guadagno dell'antenna trasmittente
+ guadagno dell'antenna ricevente
− perdite di cavi e connettori
− perdita di propagazione
− perdite ambientali di foglie, tronchi, terreno e altro

Per E22 → Dragino si usano la potenza di uscita di E22 e la sensibilità del ricevitore Dragino. Per Dragino → E22 si usano la potenza di Dragino e la sensibilità di E22. La portata bidirezionale utilizzabile è determinata dalla direzione più debole. Poiché la sensibilità varia con SF, BW, coding rate e condizioni di misura, un unico valore di “portata del dispositivo” è tecnicamente incompleto. Il riepilogo tecnico LoRa di Semtech descrive il rapporto tra parametri di modulazione, sensibilità e bit rate.

Per i calcoli sul campo di questo articolo, non assumere un valore nominale in dBm prima di aver definito i modelli esatti Dragino ed E22, il tipo di antenna, la potenza condotta e le autorizzazioni regionali. Le schede tecniche non sostituiscono le misure sul campo.

4. Perché trattare il tipo di coltura come un problema RF separato?

La stessa impostazione radio non produce lo stesso risultato in ogni ambiente agricolo. Foglie, rami, tronchi, umidità del terreno, geometria dei filari e pioggia possono influire su diffusione, assorbimento e fading multipath. Studi specifici analizzano perché negli arboreti la linea di vista spesso manca e perché la vegetazione modifica la perdita di percorso (Vougioukas et al., Influence of foliage on radio path losses for WSN planning in orchards).

Abbiamo quindi considerato inizialmente queste colture:

• mais,
• barbabietola da zucchero,
• pomodoro,
• patata,
• anguria,
• peperone,
• cipolla secca,
• uva,
• mela,
• mandarino.

Non è una classifica della produzione mondiale, ma un insieme di scenari ingegneristici che combina esigenze dei sensori, sensibilità a irrigazione/EC, valore economico e difficoltà RF. Per ogni coltura abbiamo creato prima una tabella portata–bit rate per le combinazioni SF/BW, poi una tabella di airtime FUOTA per le stesse combinazioni. Sono stime iniziali per guidare un piano di test, non garanzie sul campo.

5. Perché un agrumeto di mandarini?

Tra questi candidati, un agrumeto di mandarini è un buon test di stress:

• gli alberi sono perenni e hanno una chioma densa,
• foglie e rami possono occupare il percorso RF per gran parte dell’anno,
• i nodi sono spesso installati vicino al terreno o al tronco,
• tra gateway e nodo possono trovarsi diversi filari,
• la propagazione lungo un filare non è uguale a quella tra i filari.

L’esistenza di studi RF negli agrumeti che considerano insieme posizione del nodo, altezza dell’antenna, profondità della vegetazione e distanza dimostra che il posizionamento non può essere spiegato solo dalla distanza in metri (citrus orchard RF deployment study). Esperimenti di posizionamento in agrumeti hanno inoltre riportato livelli di segnale ricevuto diversi con altezze delle antenne e copertura arborea differenti (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

La domanda critica non è più “Quanti chilometri raggiunge LoRa?”, ma:

Ogni sensore nell’agrumeto di mandarini riesce a collegarsi con link margin sufficiente, e lo stesso downlink può completare un trasferimento firmware lungo?

6. Altezza dell’antenna: 1 metro, 5 metri e 50 centimetri

Gateway a 1 metro

Un palo di circa 1 metro può lasciare l’antenna dentro lo strato inferiore di tronchi e foglie. Filari, rami e foglie entrano così direttamente nel percorso di propagazione. Vedere l’altra antenna non significa che la zona di Fresnel sia libera: riflessioni del terreno e filari possono ancora dominare.

Gateway a 5 metri

Un’altezza di circa 5 metri può avvicinare l’antenna del gateway alla cima di molti alberi, o portarla sopra di essa. Non crea automaticamente la linea di vista in tutto l’agrumeto di mandarini, ma può ridurre l’ostruzione dal lato gateway, le perdite legate al terreno e l’effetto delle chiome sul percorso orizzontale. Le misure negli arboreti mostrano che l’effetto delle foglie dipende dal fatto che le antenne siano vicine al terreno o alla chioma (orchard foliage path-loss study).

Un palo da 5 metri non è quindi un “moltiplicatore di portata”. Il suo beneficio va misurato insieme a:

• gateway sul bordo, al centro o alla fine di un filare,
• antenna parallela o perpendicolare ai filari,
• guadagno e diagramma di radiazione verticale,
• perdita di cavo coassiale e connettori,
• pendenza del terreno e riflessioni.

Entrambe le antenne a 50 centimetri

Il vantaggio dei 50 cm è che l’antenna può restare sotto la chioma superiore e usare il corridoio tra i tronchi. Ma “non attraversa le foglie” non significa “c’è linea di vista”. A questa altezza:

• tronchi e rami bassi possono essere ostacoli diretti,
• riflessioni del terreno e perdite sul suolo bagnato possono aumentare,
• un collegamento trasversale può essere molto peggiore di uno lungo il filare.

Lo scenario a 50 cm va quindi misurato sullo stesso percorso degli scenari a 1 m e 5 m; non va considerato un miglioramento teorico della portata. In molti agrumeti, un’ipotesi ragionevole è orientare l’antenna del sensore verso il corridoio del filare, portare l’antenna del gateway sopra le chiome e aggiungere un secondo gateway se necessario. È un’ipotesi progettuale derivata dalla dipendenza da altezza e orientamento riportata negli studi RF sugli arboreti: va validata sul campo.

7. Un collegamento di telemetria non è un collegamento FUOTA

Il fatto che un sensore riesca a inviare regolarmente un piccolo pacchetto di misura non significa che possa scaricare un firmware da 1 MB sulla stessa rete. La telemetria è di solito un uplink sporadico; FUOTA è un’operazione lunga, prevalentemente downlink, che richiede la ritrasmissione dei frammenti persi.

I dispositivi LoRaWAN Class A aprono due brevi finestre di ricezione dopo un uplink. I dispositivi Class C mantengono il ricevitore disponibile più a lungo quando non trasmettono, rendendo utile un funzionamento temporaneo in Class C per un grande trasferimento downlink (LoRaWAN Specification).

FUOTA non è un solo comando “invia pacchetto firmware”. I blocchi LoRa Alliance separano le responsabilità:

• TS004 Fragmented Data Block Transport: frammentazione dei dati grandi e gestione della sessione (TS004-2.0.0).
• TS005 Remote Multicast Setup: pianificazione di multicast temporanei e finestre di distribuzione Class B/Class C (TS005-2.0.0).
• TS006 Firmware Management Protocol: gestione di versioni firmware e hardware, reboot e immagini di aggiornamento (TS006-1.0.0).
• TS007 Multi Package Access: comunicazione dei pacchetti e delle FPort del dispositivo, così più comandi possono usare meno downlink (TS007-1.0.0).

Usare insieme questi standard richiede ulteriore sviluppo e validazione HIL, indipendentemente dalla portata RF.

8. Il costo di un’immagine firmware completa da 1 MB

Un calcolo approssimativo del limite inferiore per un firmware completo da 1 MB è:

numero di bit da trasferire / bit rate teorico

Con 1 MB e 5,47 kbit/s, il solo tempo di trasferimento PHY è di circa 25,5 minuti. Applicando il 10% di utilizzo del canale come ipotesi di scenario, il limite teorico inferiore diventa circa 4,25 ore. Il calcolo esclude header LoRaWAN, metadati dei frammenti TS004, parità/ridondanza, perdita di pacchetti, ritrasmissioni e configurazione della sessione Class C. Le norme regionali e i limiti di utilizzo del canale vanno verificati per banda e paese (RP002 Regional Parameters).

Per questo scegliere le impostazioni FUOTA solo per “la portata maggiore” può essere l’obiettivo sbagliato. L’impostazione migliore minimizza l’airtime totale mantenendo un link margin affidabile.

9. Delta OTA: trasferire la differenza, non tutto il firmware

Con Delta OTA, il server invia la differenza tra l’immagine base dichiarata dal dispositivo e quella obiettivo. Il dispositivo applica la patch per ricostruire il firmware:

firmware base sul dispositivo
        +
delta patch
        ↓
firmware obiettivo
        ↓
verifica SHA-256 e firma
        ↓
MCUboot test boot e conferma dello stato

Il progetto open source detools è un esempio di approccio delta per sistemi embedded: documenta l’applicazione streaming di patch sequenziali e l’applicazione incrementale in C per dispositivi con memoria limitata (detools README). Nel progetto Agronode, il flusso di creazione e applicazione delta è definito insieme a SHA base, SHA obiettivo, dimensione dell’immagine e layout MCUboot (documentazione Agronode Delta OTA, codice di applicazione delta).

Le misure attuali del progetto riportano delta tra release consecutive di circa 15–53 KB rispetto a un’immagine completa di circa 944 KB (documentazione Delta OTA del progetto). Questa misura è specifica per quelle release; non ci si deve attendere lo stesso rapporto per ogni coppia di versioni.

Usando lo stesso valore PHY approssimativo di 5,47 kbit/s:

Non è una durata FUOTA reale, ma un confronto dimensionale. Frammentazione, parità, ritrasmissioni e gestione della sessione aggiungono tempo.

10. I dispositivi molto vecchi possono essere aggiornati con piccoli passaggi Delta?

Sì, se esiste una catena delta adatta:

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

Ogni freccia è una sessione FUOTA separata e un gate di sicurezza separato. Il server dovrebbe avviare la patch successiva solo dopo che il dispositivo ha:

1. completato la sessione di frammentazione,
2. verificato lo SHA base,
3. creato l’immagine obiettivo e verificato lo SHA obiettivo,
4. superato il test boot MCUboot,
5. confermato il nuovo firmware con un controllo di salute,
6. comunicato la nuova versione e l’identità dell’immagine.

Il flusso test–confirm–revert di MCUboot può tornare all’immagine funzionante precedente al boot successivo quando una nuova immagine fallisce; è un modello fondamentale per ridurre il rischio di brick negli aggiornamenti remoti (documentazione di progettazione MCUboot, firma immagini e strumenti MCUboot).

Lo svantaggio di una catena a più passaggi è che configurazione della sessione, airtime, energia, reboot e rischio di errore si ripetono a ogni passaggio. Se ogni hop ha una probabilità indipendente di successo del 98%, la probabilità di completare dieci hop senza ritrasmissioni è circa 0,98^10 = 81,7%. Non è una previsione di successo sul campo: è un modello che mostra come il numero di hop moltiplichi il rischio.

11. Il modello corretto è un grafo delta, non un elenco di file delta

Conservare solo le release adiacenti è un modello semplice:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

In produzione è preferibile conservare insieme immagini complete e diversi tipi di delta:

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

Politica degli artifact consigliata:

• Conservare un’immagine completa e firmata per ogni release.
• Conservare i delta consecutivi N→N+1 come artifact immutabili di lunga durata.
• Generare delta diretti dalle versioni base realmente presenti sul campo alla release più recente.
• Conservare delta bridge da versioni LTS/checkpoint selezionate alla release più recente.
• Conservare con ogni delta i metadati SHA base, SHA obiettivo, board, revisione hardware, variante e geometria delle partizioni.
• Non eliminare le immagini complete: restano la fonte canonica per generazione delta, analisi forense e recupero.

Nel lato Agronode, lo script artifact esistente mostra la generazione di delta diretti dalle versioni base sul campo (ensure_field_deltas.py). L’attuale policy backend cerca una corrispondenza diretta base–obiettivo; serve inoltre un graph/path planner per pianificare automaticamente A→B→C quando esistono A→B e B→C (ota_policy.py).

Il server può scegliere il percorso con questa funzione di costo:

costo del percorso =
byte totali delle patch
+ airtime stimato
+ costo di sessione/reboot per hop
+ rischio di perdita pacchetti e fallimento
+ energia del dispositivo e costo di manutenzione

Una prima policy pratica è usare una patch diretta quando esiste ed è di dimensione ragionevole. Se è troppo grande, provare un percorso checkpoint con al massimo 2–3 hop controllati. L’immagine completa va conservata come percorso di recupero, bootstrap o trasporto alternativo, non come “ultima risorsa” automatica su LoRa.

12. Gate di sicurezza necessari per Delta OTA

Delta OTA non elimina i controlli di sicurezza; rende ancora più importante l’identità esatta dell’immagine base.

Per ogni patch bisogna verificare almeno:

• SHA-256 del firmware base dichiarato dal dispositivo,
• SHA-256 base atteso dalla patch,
• board e revisione hardware,
• geometria di partizioni/slot,
• SHA-256 del firmware obiettivo,
• firma MCUboot e chiave di firma autorizzata,
• conformità della versione obiettivo alla policy di downgrade.

MCUboot verifica integrità e firma dell’immagine e può fornire rollback quando un test boot non viene confermato definitivamente (documentazione ufficiale MCUboot). Il codice di applicazione delta deve rifiutare incompatibilità di base e layout prima di creare l’immagine obiettivo (applicazione delta Agronode).

Per i dispositivi molto vecchi serve anche una versione bootstrap FUOTA definita. Se il firmware precedente non contiene un client di frammentazione, il codice delta-apply o il supporto bootloader necessario, il dispositivo non può entrare direttamente nella catena delta. Prima va aggiornato tramite BLE, Wi-Fi, rete cellulare o un’immagine completa controllata.

13. Una roadmap praticabile per questo progetto

Fase 1 — Fissare le ipotesi RF

• Confermare i modelli esatti di Dragino ed E22.
• Selezionare regione e piano di frequenza.
• Misurare la potenza condotta o verificarla sulla scheda tecnica.
• Registrare guadagno d’antenna, perdita del cavo e polarizzazione.
• Misurare sullo stesso percorso dell’agrumeto di mandarini gli scenari a 50 cm, 1 m e con gateway a 5 m.

Fase 2 — Creare una mappa di connettività sul campo

• Registrare RSSI e SNR in ogni punto di misura.
• Misurare tasso di successo dei pacchetti e dipendenza dalla direzione.
• Confrontare condizioni asciutte, irrigate, piovose e con diversa densità di foglie.
• Misurare un percorso lungo i filari e un altro trasversale.
• Definire separatamente il link margin minimo richiesto per FUOTA.

Fase 3 — Completare il trasporto FUOTA LoRaWAN

• Implementare la sessione di frammentazione TS004.
• Implementare con TS005 il ciclo di vita temporaneo Class C/multicast.
• Collegare gestione versione firmware/reboot di TS006 e package discovery di TS007.
• Testare perdita dei frammenti, ritrasmissioni, interruzioni e riavvio del gateway.
• Non promettere il successo end-to-end di Delta FUOTA su LoRa prima di completare questa fase.

Fase 4 — Aggiungere artifact delta e gestione dei percorsi

• Conservare ogni release completa firmata come artifact canonico.
• Generare delta adiacenti e delta diretti dalle basi attive sul campo alla release più recente.
• Rendere immutabili i metadati delta con SHA base/obiettivo e identità hardware.
• Implementare lato server la selezione di patch dirette e percorsi multi-hop limitati.
• Dopo ogni hop attendere segnali di versione, SHA, salute del boot e salute applicativa.

Fase 5 — Definire la metrica di successo FUOTA

Il successo non deve significare soltanto “sono arrivati tutti i pacchetti”. Vanno riportate insieme queste metriche:

• byte della patch e airtime totale,
• tasso di perdita dei frammenti e numero di ritrasmissioni,
• tempo di completamento dell’aggiornamento,
• consumo energetico,
• tasso di successo del test boot,
• tasso di conferma permanente,
• tasso di rollback,
• successo per hop e totale quando sono necessari più hop.

Conclusione

Il problema LoRa in un agrumeto di mandarini non è solo “Quanti chilometri possiamo coprire?”. SF e BW creano un compromesso tra portata e bit rate; la vegetazione modifica il collegamento teorico sul campo; altezza dell’antenna e orientamento dei filari cambiano il risultato; FUOTA richiede una capacità downlink molto diversa da quella necessaria per piccoli pacchetti di telemetria.

Per questo il riferimento di 6 km di Semtech e la distanza di aggiornamento affidabile in un fitto agrumeto di mandarini non descrivono la stessa metrica. L’architettura corretta unisce link budget RF misurato, altezza adeguata del gateway, trasporto FUOTA standard TS004/TS005, gate di sicurezza MCUboot e grafo degli artifact Delta OTA.

Quando Delta OTA riduce un’immagine completa da 1 MB a patch da circa 15–53 KB, può ridurre drasticamente l’airtime FUOTA. Ma l’algoritmo delta da solo non rende affidabile il prodotto. Il server deve conoscere lo SHA base esatto del dispositivo, scegliere un percorso diretto o multi-hop limitato, verificare ogni hop e conservare l’immagine completa come fonte di recupero.

In breve, l’obiettivo non è la portata massima, ma un sistema LoRaWAN capace di eseguire un aggiornamento firmware misurabile, ripetibile e reversibile in un agrumeto di mandarini.

Fonti

Standard e documenti tecnici dei produttori

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

Studi sulla propagazione RF in agricoltura

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