Come qualcuno di voi, assidui lettori di questo thread (…   sperabilmente un insieme non vuoto 🙂 … ) , saprà, è da un poco di tempo che stiamo lavorando su un progettino basato sulla tecnologia LoRa, declinata anzicchè per l’uso nell’IoT  propriamente detto, in ambito radioamatoriale, ovvero come modo di comunicazione per impiego generico eventualmente in ambiti legati alla protezione ambientale e all’ambito emergenziale.

La base per effettuare la nostra sperimentazione consiste in un insieme di dispositivi HW basati sulla tecnica di una piccola carrier-board predisposta per ospitare una serie di moduli scelti ad hoc per effettuare dei test mirati sull’uso della tecnologia LoRa.

L’HW di base è stato associato ad un SW modulare basato sul sistema operativo FreeRTOS su processore ESP32, e sviluppato in un ambiente arduino agevolmente approcciabile anche da parte di apprendisti stregoni della programmazione….

Per validare questa piattaforma HW/SW abbiamo deciso di implementare inizialmente una tipica aplicazione radioamatoriale, l’APRS,  sostituendo all’originario livello fisico dell’APRS , il livello fisico LoRa , in modo da avere dei dispositivi agevolmente integrabili nell’ambiente APRS sia fisico, che esteso ad internet (APRS-IS).

Con la release 2.x del SW di cui sopra abbiamo iniziato ad implementare ulteriori funzioni orientate alla reale sperimentazione per cui tutto il discorso era stato concepito:  la funzione chiave introdotta è stata il “packet scheduling”, ovvero la possibilità di gestire in maniera flessibile i tempi di emissione e di processo dei singoli pacchetti  oggetto della comunicazione.

Grazie all’introduzione di questa nuova funzionalità di base è ora possibile introdurre una serie di miglioramenti sia alla iniziale applicazione APRS, che sviluppare nuove applicazioni mirate a valutare specifici aspetti del protocollo LoRa.

Per quanto riguarda l’applicazione APRS la nuova funzionalità di packet scheduling consente di gestire flessibilimente i tempi di trasmissione dei pacchetti LoRa in base allo stato di occupazione del canale radio: in particolare se è da trasmettere un nuovo pacchetto ed il canale LoRa è già impegnato a trasmettere un pacchetto precedente, il nuovo pacchetto viene accodato per essere trasmesso non appena il canale diventa disponibile.

Una ulteriore funzione è quella di introdurre dei tempi di ritardo randomici nella emissione di nuovi pacchetti APRS in modo da consentire di evitare risposte simultanee da più ripetitori che si tradurrebbero nell’oscuramento di alcuni igates lontani, da parte di igates vicini pù forti…

Sul fronte delle nuove funzionalità introdotte è stata implementata una funzione di “Native Beacon”  tramite pacchetti in un formato “nativo” pensato per ridurre al minimo i tempi di trasmissione ( “onAirTime”):  in tale modalità vengono emessi, in dei timeslots appropriati, dei flussi di pacchetti LoRa con caratteristiche specificate in termini di Freq, BW, SF, CR, PrLen  con un formato binario che riporta in modo compresso una serie di dati relativi alla geolocalizzazione del nodo emittente, il suo tempo locale,  le caratteristiche di emissione ed un “sequenceNumber” in modo da avere dei pacchetti estremamente compatti, geolocalizzati e time sincronized, in modo da poter ricostruire in ricezione una serie di dati relativi al flusso di pacchetti.

La nuova funzionalità di “Native Beacon” è stata resa possibile dalla possibilità di gestire il ricetrasmettitore half duplex implementato dal protocollo LoRa  in maniera flessibile con possibilità di settare liberamente a livello di singolo pacchetto l’intero set di parametri del dispositivo; questa funzione, aggiunta alla possibilità di sincronizzare come tempo il ricevitore ed il trasmetitore remoto entro poche decine di millisecondi sfruttando un GPS o un NTP internet,  consente di intercalare flussi di pacchetti afferenti a differenti applicazioni in maniera tale da implementare un mix di applicazioni quasi-transparente per l’utente dei dispositivi.

Nal caso specifico è stata implementata una prima modalità di lavoro mista che consente di usare in due time slots differenti che si alternano all’interno di un intervallo di tempo di tre minuti, una applicazione APRS su una certa frequenza e con sue caratteristiche di emissione, ed una modalià “Native Beacon” sulla stessa o su una diversa frequenza con sue caratterictiche di emissione.

Questa configurazione consente quindi di supportare con uno stesso nodo due diverse modalità di comunicazione consentendo quindi di effettuare delle correlazioni tra due diversi servizi.

Nello specifico la modalità APRS implementata utilizza come parametri di lavoro  BW=31.25KHz, SF=7 , CR=7, prlen=15 che consente di realizzare un canale APRS con un bitrate di circa 1300 bit/sec abbastanza prossimo all’APRS tradizionale, mentre la modalità “Native Beacon”  utilizza come parametri di lavoro LoRa  BW=10.4KHz, SF=12, CR=8 e PrLen=10  che consentono di stimolare il protocollo LoRa quasi ai massimi livelli di “sensibilità” consentiti dal protocollo stesso.

La figura seguente rappresenta un esempio di output del sistema: 

come si può notare mentre il traffico “Native Beacon” a 10.4Khz/SF12  è presente quasi in continuazione per le 24 ore, il traffico APRS riesce ad essere presente solo nel piccolo intervallo tra le ore 24 e le ore 02 in corrispondenza del quale il diagramma del traffico nativo presenta un massimo. Ovviamente questo evidenzia la potenzialità della tecnologia LoRa che riesce a recuperare pacchetti anche se “letteralmente sepolti” nel rumore, anche se a scapito ovviamente del bitrate della comunicazione.

I dispositivi che vengono utilizzati sono in grado di effettuare un reporting dettagliato via internet di una serie di parametri relativi ad ogni pacchetto ricevuto, inviando degli opportuni “records” ad un server ad hoc accessibile su internet e destinato a collezionare i risultati raccolti dai vari nodi.

La figura seguente riporta un esempio dei records che vengono raccolti per una singola tratta radio:

Come si può notare i due tipi di traffico Native_Beacon e APRS sono intercalati e portano un diverso insieme di parametri; l’esempio di traffico Native illustrato in figura si riferisce ad una configurazione in grado di fornire una lunghezza di pacchetto minimale, per cui una serie di parametri ( ad es. freq, etc.) sono non valorizzati in quanto non trasmessi; volendo trasportare questi valori è sufficiente abilitare le relative voci nella pagina di configurazione del traffico beacon, ovviamente producendo delle lunghezze di pacchetto maggiori.

La figura a fianco riporta un esempio della pagina della GUI che consente di configurare la funzione beacon: si nota come sia possibile specificare i parametri del flusso di pacchetti e la configurazione del chipset da utilizzare.

Il server delle statistiche a sua volta è in grado di effettuare un  post-processo dei dati raccolti presentando i risultati oltre che su una mappa geolocalizzata, anche tramite degli opportuni diagrammi temporali dell’andamento delle connessioni sotto osservazione.

Una prima istanza dell’applicazione di questa nuova modalità è attualmente in corso di sperimentazione da alcune settimane sfruttando come test plant una connessione LoRa tra due nodi iGate situati rispettivamente in località Colli Prestige presso Sorrento (NA) e in localià Monte San Biagio presso Terracina (LT):  la tratta radio è caratterizzata dall’avere una distanza di circa 128 Km e dall’essere NLS (non in vista ottica)  per cui abbastanza significativa per valutare alcuni aspetti della propagazione radio.

 

E’ stata creata una pagina “LoRa Beacon Propagation Test Plant” su questo stesso sito dove sono dettagliatamente riportate le caratteristiche del test plant e i risultati che via via stiamo raccogliendo.

 

 Le figure a fianco illustrano la tratta radio sotto osservazione.

 

Nella pagina indicata sono riportati i diagrammi giornalieri relativi al traffico “Native Beacon” ed APRS (ove disponibile ) relativi ai pacchetti scambiati sulla tratta nella direzione ColliPrestige –> MonteSBiagio:  in particolare la modalità APRS viene stimolata con dei pacchetti APRS-Beacon a ritmo di tre minuti, come pure il traffico “Native Beacon” viene stimolato con dei pacchetti a ritmo di tre minuti.

 

L’osservazione e lo studio dei diagrammi è ovviamente l’oggetto su cui lavorare…. 🙂

 

 

 

Nella ultima versione dei diagrammi presentati in particolare per la componente “Native Beacon” , vengono riportati per ogni pacchetto raccolto con successo dal ricevitore, i valori di Intesità del segnale misurato ai morsetti di antenna del ricevitore LoRa (indicato come ENL in dbm in verde ),  il valore del rapporto segnale rumore SNR come riportato dal chip LoRa (in db in blue) e il valore del RSSI  (in dbm in rosso) ovvero dell’intensità di segnale utile stimato dal chip LoRa sulla base dei valori di intensità di segnale presente a morsetti di antenna e del guadagno di processo introdotto dal chipset LoRa.

Il valore di segnale ai morsetti di antenna ( ENL ) è un interessante indicatore del livello di rumore in cui il segnale utile risulta spesso “annegato”: infatti se ci si limita a considerare spots caratterizzati da un valore di SNR negativo, ovvero segnale annegato nel rumore,  è possibile abbastanza bene assimilare questo valore al livello di rumore locale tanto meglio quanto più basso è il valore di SNR.

La conoscenza di questo parametro (ENL) è importantissimo per capire quale sia la reale “sensibilità” del sistema nella specifica implementazione fisica, in quanto i valori relativi  pubblicati sulle specifiche sono teorici e riferiti a situazioni ideali in cui l’unico fattore di rumore presente e considerato sia la figura di rumore dello stadio di ingresso del ricevitore.

Un ulteriore  parametro estremamente importante che viene pure riportato sui diagrammi di cui sopra è l’andamento nel tempo del valore dei “CRC_Errored_Packets” ( in marrone ) rivelati dal ricevitore LoRa:  questo parametro è estremamente importante e significativo in quanto rappresenta e quantizza quelle situazioni in cui il ricevitore riesce a scoprire la presenza di un segnale LoRa probabilmente valido, ma con una probabilità di errore molto alta per cui il pacchetto non supera i controlli di correttezza implementati dal CRC e che sconta anche gli effetti delle funzionalità di FEC (Forward Error Correction ovvero del CR ) implementate dal chipset LoRa.

La presenza di pacchetti “CRC_Errored” suggerisce un interessante filone di ricerca e di approfondimento: infatti è evidente che essendoci comunque detezione di segnali LoRa, è potenzialmente implementabile qualche metodica di trattameno degli errori che consenta di recuperare i pacchetti errorati e quindi potenzialmente aumentare il guadagno di processo del sistema.

Come una prima conferma di queste considerazioni si può osservare la figura seguente:  si può notare che si hanno CRC_Errors in corrispondenza di valori sempre molto bassi del rapporto SNR… il fatto ovviamente suggerisce che se si potesse migliorare la parte di “error correction” verosimilmente almeno alcuni dei pacchetti errorati potrebbero essere recuperati correttamente.

Questi primi risultati ottenuti con la nuova versione di SW 2.x  sono di incoraggiamento a proseguire con l’attività di investigazione intrapresa.

Sarebbe in particolare molto interessante poter estendere la sperimentazione ad altre situazioni per es. attivando della tratte radio su diversi tipi di orografia, di cui la nostra penisola è ricca… ; la tratta radio considerata per es. si svolge quasi interamente su mare, per cui può servire ad evidenziare bene una serie di fenomeni di propagazione anomala, ma è forse poco significativa per caratterizzare l’uso della tecnologia LoRa su un diverso tipo di terreno, per es. in pianura o in un ambito collinare.

Un altro ambito in cui operare è per esempio utilizzare un diverso  tipo di frequenza di lavoro, sfruttando ad es. la banda dei 2.4GHz ove è già disponibile un chipset LoRa ad hoc, peraltro già utilizzabile sulla nostra piattaforma HW/SW con un minimo lavoro di adattamente.

Un ulteriore ambizioso filone riguarda l’introduzione di un ulteriore livello di “error correction” ai payload trasportati nel tentativo di estendere ulteriormente il guadagno di processo della tecnologia LoRa nativa.