Abbiamo avviato qualche test per valutare le caratteristiche del sistema LoRa ai limiti del suo campo di usabilità nell’ambito delle applicazioni radio-amatoriali…

Come riferimento è possibile consultare la seguente tabella estratta dalla documentazione del chipset LoRa utilizzato.

La tabella  riporta i valori di “Sensibilità” e di “Data Rate” in funzione dei valori dei parametri BW (Larghezza di banda utilizzata) e SF (Spreading Factor).

Il valore di sensibilità va inteso come il minimo segnale decodificabile correttamente.

Esiste una formula che consente di determinare questo valore sulla base dei parametri di funzionamento e della figura di rumore del sistema di antenna e del frontend del ricevitore; esiste anche un tool online accessibile all’indirizzo seguente: “LoRa Sensitivity Calculator”  che fornisce i valori in questione.

Un altro parametro interessante per valutare le prestazioni è il “Guadagno di Processo” che fornisce una indicazione di quanto gli algoritmi impiegati dal sistema loRa per estrarre il segnale dal rumore siano efficienti ; i valori di guadano di processo indicati sono definiti come tipici nella documentazione dei chips; esistono una serie di lavori in letteratura che approfondiscono questo tema; da tali lavori si ricava che il reale valore di guadagno di processo ottenibile dipende in maniera determinante dalle caratteristiche del rumore presente e dal tipo di FEC (Forward Error Correction) impiegato per la trasmissione.

 

A proposito dei valori di  “sensibilità” va fatta però una considerazione spesso completamente tralasciata: i dati forniti sui datasheet e nella documentazione ufficiale della Semtech non rendono molto decifrabile la relazione che esiste tra questo parametro ed i valori del guadagno di processo ottenibili, in quanto si basano sul parametro “Figura di Rumore del ricevitore” in genere abbastanza ostico come comprensione da parte dei non specialisti;  dalla lettura della abbondante produzione scientifica disponibile sul web emerge che  in realtà i valori realmente ottenibili in pratica per il sistema sono abbastanza diversi da quelli indicati nella tabella su riportata per un motivo abbastanza banale e forse un poco sottaciuto: il livello di rumore assoluto in cui il segnale da scoprire si trova immerso… 

Questo aspetto viene in genere modellato matematicamente con il parametro “Figura di Rumore” e alla sua determinazione contribuiscono una serie di componenti  tra loro abbastanza diverse e che pesano diversamente a seconda del campo di frequenze che si vanno a considerare. Un esempio può servire a chiarire il discorso senza scomodare troppa matematica…

Se consideriamo come esempio il caso di BW=7.8KHz e SF=12  e consideriamo per es. un segnale S immerso nel rumore N=-110 dbm (come potrebbe essere mostrato da un ricevitore SDR sintonizzato nei dintorni del canale radio in uso)  ed assumiamo un valore massimo del guadagno di processo per es. di -20 db, è facile concludere che S deve essere almeno maggiore di  -130 dbm  anche se la tabella darebbe come valore -149 dbm….  In effetti la tabella fa riferimento a condizioni abbastanza ideali considerando che il rumore “esterno” all’antenna sia nullo o quasi nullo… (in concreto viene considerato un valore equivalente alla rumorosità dello stadio di ingresso del ricevitore).

Quanto sopra osservato è stato confermato da numerose esperienze di campo nell’ambito dell’IoT , per cui è un tema sicuramente degno di ulteriore esplorazione in quanto  da esso scaturisce uno dei reali limiti della tecnologia.

Strettamente legato al discorso accennato è quindi il tema del “livello di rumore radio” presente in un certo sito: infatti il rumore presente può avere diverse genesi, sia di natura “remota” ovvero rumore che arriva grazie allo stato della propagazione radio, sia di natura “locale” per es. dovuto ad apparecchiature colocate con il nodo LoRa o presenti nei paraggi sia infine di natura fisica legata al rumore intrinseco dei dispositivi elettronici che costituiscono gli stadi in ingresso del ricevitore.

La prima componente ovviamente è intrinseca del segnale nel senso che segue all’incirca le stesse sorti del segnale salvo ad essere equiparabile ad una molteplicità di sorgenti distribuite intorno al sito di ricezione, contrariamente al segnale che ha una unica precisa origine ( tralasciando per semplicità eventuali discorsi di riflessioni…);  quindi essendo la propagazione radio un meccanismo tipicamente anisotropico ( cioè funzione della direzione di provenienza del segnale per es…)  per questa componente si può assumere che sia grossolanamente legata all’intensità del segnale utile anche se con dei fattori di scala.

La seconda componente invece rappresenta un fattore completamente indipendente dalo stato della propagazione e legato a fattori locali quali la presenza di altre apparecchiature, o cose similari.

La terza componente dipende da come sono realizzati i circuiti di ingresso del ricevitore e dal tipo di antenna; in pratica questa componente alle frequenze di nostro interesse è abbastanza poco significativa  come contributo al rumore totale.

Un ulteriore discorso che andrebbe considerato è legato ai fenomeni di “desensibilizzazione” o di “saturazione”  a cui può andare incontro il ricevitore a causa di fortissimi segnali anche se leggermente fuori banda del segnale utile: è un problema difficilmente modellabile ma che si traduce in una riduzione della sensibilità del ricevitore o in un aumento di prodotti spuri che a tutti gli effetti si comportano come un rumore. Questa tipologia di problema è molto comune soprattutto se nel sito interessato sono colocate altre apparecchiature che operano su frequenze vicine a quella di nostro interesse.

Volendo quindi provare a trovare delle regole per la scelta di un sito ove installare un nodo LoRa  appare evidente che assume molta importanza la conoscenza e/o la valutazione della seconda componente che rappresenta in un certo senso lo zoccolo duro che può limitare la reale “sensibilità” ottenibile per una rete LoRa installata in quella zona….

La valutazione quindi dei livelli di “rumore intrinseco” di un sito è un argomento certamente da approfondire in questa indagine…

Allo stato, per le nostre prove stiamo usando come test bed una tratta radio di 120 Km  tra Monte San Biagio ( Latina) e Colli_Prestige (Sorrento-Napoli).

Per raccogliere i dati sfruttiamo una coppia di iGate APRS SARIMESH con SW Vr. 2.0.9  che implementano una modalità mista APRS + NativeBeacon che consente di creare una modalità operativa in cui il dispositivo si comporta come un normale iGate APRS, riservando però una parte del suo tempo ad una nuova funzionalità che abbiamo definito “Native Beacon”  consistente nell’inviare dei pacchetti LoRa di lunghezza minimale con delle condizioni di lavoro particolarmente “spinte” allo scopo di sondare lo stato della propagazione su di una prefissata tratta radio.

In questo modo è possibilile raccogliere dati quantitativi dei segnali ricevuti sia utilizzando la normale modalità APRS con le sue caratteristiche operative, e la modalità beacon come base di riferimento del “top” ottenibile dalla tratta sfruttando la tecnologia LoRa quasi ai suoi limiti.

Come traffico di test APRS, sfruttiamo attualmente pacchetti APRS in un formato particolare atto a trasportare i dati di RSSI e SNR misurati dai nodi attraversati e relativi ad ogni pacchetto ricevuto correttamente.

Per la modalità NativeBeacon invece utilizziamo un formato binario pensato per trasportare in maniera compressa una serie di parametri relativi al flusso di pacchetti; in particolare è possibile includere tutti o parte dei seguenti elementi: ID nodo, SequenceNumber pacchetto, emissionTime, GPS_Location, Freq, Pwr,  BW, SF, CR, PrLen; la lunghezza di pacchetto relativa può andare da un minimo di 3 ad un massimo di 22 bytes a pacchetto.

Le condizioni di lavoro attualmente utilizzate a livello radio per il traffico APRS sono:

• Freq. 433,725MHz
• BW=31.25 KHz
• SF=7
• CR=4:7
• PrLen=15

 

Come alternativa potranno anche essere utilizzate le seguenti condizioni  a livello radio relative al traffico in standard APRS-OE :

• Freq. 433,775MHz
• BW=125 KHz
• SF=12
• CR=4:8
• PrLen=10

 

Le condizioni di lavoro attualmente utilizzate a livello radio per il traffico NativeBeacon sono:

• Freq. 433,725MHz
• BW=10.4 KHz
• SF=12
• CR=4:8
• PrLen=10

 

Per entrambe le modalità le condizioni di trasmissione/ricezione sono:

• potenza RF 30dbm
• antenne verticali collineari Diamond X50 e X500 

 

Il tempo di trasmissione dei pacchetti (OnAirTime) è di circa 4.1 sec. per i pacchetti NativeBeacon e  0,8 sec per i pacchetti APRS o 4,2 sec per quelli in APRS-OE mentre il ciclo di raccolta del traffico ha una periodicità di 3 minuti.

I pacchetti ricevuti vengono raccolti ed analizzati per estrarre i valori relativi ai seguenti tre parametri:

• ENL (Estimated Noise Level): rappresenta il valore di potenza misurato dal chip LoRa ai morsetti di antenna; se riferito  a spots con valore di SNR  negativi, fornisce una indicazione, anche se approssimativa, del livello di rumore presente sul canale in quel sito ;  tracciato verde dei diagrammi
• SNR rappresenta i valori di SNR restituiti dall’algoritmo di estrazione dei pacchetti utilizzato dal protocollo LoRa, inclusivo della funzione di FEC (Forward Error Correction) e  rappresenta all’incirca il guadagno di processo LoRa; tracciato colore blu
• RSSI rappresenta il valore di intensità del segnale radio restituito dal RX LoRa e comprensivo del guadagno di processo: rappresenta una stima del valore di segnale anche in condizioni di SNR negativi ( segnale sepolto nel rumore); tracciato colore rosso.

La tratta radio sotto osservazione si svolge parzialmente su mare e include un ostacolo che rende il path non LOS sulla base delle altezze dei siti.

Le immagini a fianco sono i risultati di una simulazione del link effettuata con il tool “Radio Mobile” e relativa alla tratta radio utilizzata; i parametri impostati per la simulazione sono quelli in uso attualmente.

    

I dati raccolti sono presentati allo stato (provvisoriamente) sotto forma di diagrammi giornalieri reperibili ai links riportati a seguire;   i valori relativi alla giornata corrente sono visualizzabili in tempo reale (quando disponibili)  ai seguenti URL: 

• “LORa Trasmission Test Bed: BeaconNative PDU daily diagram”  
• “LORa Trasmission Test Bed: APRS or APRS-OE PDU daily diagram” 
• “LoRa Trasmission Test Bed: detailed spots data”

 

E’ Stata anche recentemente aggiunta una ulteriore presentazione dei risultati giornalieri sotto forma di una tabella che riporta, per ogni timeslot di durata 3 minuti ( quindi 480 ts per una giornata)  i valori numerici degli spots ricevuti organizzati in modo da poter confrontare agevolmente i valori relativi ai due tipi di traffico sotto osservazione. Per cecare di rendee omogeneo al massimo il confronto è stato ridotto notevolmente il numero di bytes che compongono il pacchetto BeaconNative in modo da avere un tempo OnAir molto vicino tra i due tipi di traffico sotto osservazione ( circa 4 sec/pacchetto).

Come si potrà notare vengono riportati solo gli spot ricevuti correttamente, anche se il rate di invio dei pacchetti non subisce interruzioni; evidentemente i punti mancanti rappresentano pacchetti persi in quanto affetti da errori non correggibili dal FEC e questo equivale a evidenziare dei valori SNR troppo bassi per poter essere il segnale correttamente decodificato.

I due diagrammi riportano i dati raccolti in tempo reale utilizzando i due diversi tipi di flussi di pacchetti LoRa:  

• Pacchetti in formato nativo molto corti trasmessi con parametri BW=10.4 KHz SF=12 CR=8 PL=10
• Pacchetti in formato APRS trasmessi con parametri BW=31.25 KHz SF=7 CR=7 PL=15 o in alternativa
• Pacchetti in formato APRS-OE trasmessi con parametri BW=125 KHz SF=12 CR=8 PL=10

 

Il raffronto tra i due tipi di diagrammi consente di avere una idea di quanto le condizioni di trasmissione LoRa siano determinanti per le performancies di un collegamento.

Come elemento di raffronto delle condizioni meteo riportiamo a fianco di alcuni dei grafici uno snapshot estratto dal sito “William Hepburn’s DX Info Center”  riferito alla giornata del diagramma…  (punto attualmente sospeso…)

 

2021-12-31 Native Beacon PDU	2021-12-31 APRS-OE PDU
2021-12-30 Native Beacon PDU	2021-12-30 APRS-OE PDU
2021-12-29 Native Beacon PDU	2021-12-29 APRS-OE PDU
2021-12-28 Native Beacon PDU	2021-12-28 APRS-OE PDU
2021-12-27 Native Beacon PDU	2021-12-27 APRS-OE PDU
2021-12-26 Native Beacon PDU	2021-12-26 APRS-OE PDU
2021-12-25 Native Beacon PDU	2021-12-25 APRS-OE PDU
2021-12-24 Native Beacon PDU	2021-12-24 APRS-OE PDU
2021-12-23 Native Beacon PDU	2021-12-23 APRS-OE PDU
2021-12-22 Native Beacon PDU	2021-12-22 APRS-OE PDU
2021-12-21 Native Beacon PDU	2021-12-21 APRS-OE PDU
2021-12-20 Native Beacon PDU	2021-12-20 APRS-OE PDU
2021-12-19 Native Beacon PDU	2021-12-19 APRS-OE PDU
2021-12-17 Native Beacon PDU	2021-12-17 APRS-OE PDU
2021-12-16 Native Beacon PDU	2021-12-16 APRS-OE PDU
2021-12-15 Native Beacon PDU	2021-12-15 APRS-OE PDU
2021-12-14 Native Beacon PDU	2021-12-14 Native Beacon PDU
2021-12-13 Native Beacon PDU	2021-12-13 APRS-OE PDU	sig_compare_20211213
2021-12-12 Native Beacon PDU	2021-12-12 APRS-OE PDU	sig_compare_20211212
2021-12-11 Native Beacon PDU	2021-12-11 APRS-OE PDU	sig_compare_20211211
2021-12-10 Native Beacon PDU	2021-12-10 APRS-OE PDU
2021-12-09 Native Beacon PDU	2021-12-09 APRS-OE PDU
2021-12-07 Native Beacon PDU
2021-12-06 Native Beacon PDU	NO SPOTS RECEIVED
2021-12-05 Native Beacon PDU	NO SPOTS RECEIVED
2021-12-04 Native Beacon PDU	NO SPOTS RECEIVED
2021-12-03 Native Beacon PDU	NO SPOTS RECEIVED
2021-12-02 Native Beacon PDU	2021-12-02 APRS-OE PDU
2021-12-01 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-30 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-29 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-28 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-27 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-26 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-25 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-24 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-23 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-22 Native Beacon PDU	NO SPOTS RECEIVED
2021-11-21 Native Beacon PDU	2021-11-21 APRS PDU
2021-11-20 NativeBeacon PDU	2021-11-20 APRS PDU
2021-11-19	NO SPOTS RECEIVED
2021-11-09	2021-11-10 Tropo Propagation Forecat
2021-11-08	2021-11-08 Tropo Propagation Map
2021-11-07	2021-11-07 Tropo Propagation Forecast
2021-11-06
2021-11-05
2021-11-04
2021-11-03
2021-11-02