Il protocollo di trasmissione LoRa è nato sostanzialmente come una metodica per ottenere una soluzione ottimale per le applicazioni IoT (Internet of things):  in particolare la caratteristica chiave di questo protocollo è quello di sfruttare le proprietà matematiche insite nell’uso di una “tecnica di trasmissione a spettro disperso” per consentire di esaltare un certo tipo di segnale estraendolo dal rumore presente nel canale radio utilizzato … questo consente di migliorare ( attualmente fino a quasi 20 db) il rapporto segnale/rumore della trasmissione facendo emergere e rendendo decifrabili segnali anche completamente sepolti nel rumore e altrimenti assolutamente non detezionabili…

Da questa proprietà e caratteristica discendono una serie di “benefici”  come pure una serie di specificità e complessità implementative.

Il primo e principale beneficio è certamente quello di abbassare notevolmente la potenza di trasmissione richiesta per ottenere delle volute “aree di copertura radio”, ovvero delle aree di servizio in cui il sistema consenta cioè di ottenere opportuni livelli di qualità della trasmissione sostanzialmente in termini di bit-rate  e tasso di errori di trasmissione ottenibili: questo apre la strada per applicazioni che non richiedono lo scambio di grosse moli di dati a soluzioni prive di alimentazione esterna e con tempi di autonomia addirittura dell’ordine di anni… è il classico caso delle applicazioni IoT.

Un secondo grosso obiettivo è quello di migliorare notevolmente l’utilizzabilità di un certo “canale radio” (inteso come larghezza di banda occupata dalla trasmissiione) consentendo di utilizzare uno stesso canale simultaneamente per trasmettere una molteplicità di flussi informativi che pur condividendo lo stesso canale NON si disturbano reciprocamente: la chiave per questa caratteristica sta nella proprietà matematica della “ortogonalità” dei modi di trasmissione possibili…  questa proprietà consente cioè di sfruttare delle particolarità insite nella scelta di alcuni parametri del modo di trasmissione che associate alle proprietà di spettro disperso consentono di “oscurare” completamente tutte le trasmissioni presenti sul canale eccetto una ed una sola… nel caso specifico di LoRa si può arrivare ad avere fino ad 8 modalità contemporaneamente in uso su uno stesso canale radio .

Da questa proprietà deriva un ulteriore grosso vantaggio che è la “flessibilità” del sistema di trasmissione intesa come possibilità di ottenere il miglior compromesso tra estensione dell’area di copertura, consumo di energia e bit rate disponibile in base alle caratteristiche di una certa applicazione.

Questi indubbi vantaggi vanno ovviamente a discapito della “semplicità realizzativa”  se con tale locuzione si intende il voler realizzare un simile sistema usando componenti tipo transistor, resistenze e condensatori come il radioamatore tradizionale ha sempre fatto…  un simile sistema è realizzabile in pratica per un uso generalizzato esclusivamente utilizzando le più moderne tecniche di realizzazione di circuiti integrati a larga scala di integrazione (VLSI)  che si traducono ovviamente nell’utilizzo del paradigma oggi oramai ampiamente diffuso del lavorare non più con singoli componenti tradizionali, ma con “blocchi funzionali” resi disponibili da grosse società specializzate…  a sua volta questo paradigma ne induce uno ulteriore che è la “convivenza” con le tematiche di “proprietà intellettuale” che necessariamente si accompagna ai discorsi dei “blocchi funzionali”.

Un ulteriore effetto che la metodica LoRa fa emergere deriva dal fatto che un segnale LoRa essendo di tipo a spettro disperso NON consente di implementare parecchie delle classiche modalità di accesso ad un canale radio che siamo da sempre stati abituati a considerare ed utilizzare…  l’accesso  ad un canale radio utilizzabile da più trasmettitori tipicamente si è basato su diverse tecniche che possono essere classificate in base al loro modo di operare … ovvero in base alla differenziazione della frequenza utilizzata, del tempo di accesso al canale o semplicemente dal fatto che il “canale appare libero”…

Con il protocollo LoRa ovviamente alcune di queste metodiche ( tipo l’utilizzo di frequenze opportunamente scelte)  possono essere ancora tranquillamente utilizzate.. altre purtroppo lo possono ma a prezzo di una elevata complessità richiesta… in particolare ciò si applica alle techiche che fruttano il fatto che “un canale sembra libero” … infatti a causa del fatto che un segnale LoRa è detezionabile anche se completamente sepolto nel rumore del canale, per scoprire se un canale è libero bisogna…  provare a vedere se sia presente un segnale valido… ma questo è fattibile solo eseguendo tutti gli algoritmi di decodifica del protocollo LoRa nel “modo” che si vuole usare!!!   ovvero deve essere il chip LoRa stesso a dirci se il canale è o meno libero… questo aspetto viene indicato in pratica come CAD ( Channel Activity Detection )  e deve essere una funzione svolta direttamente dal chip LoRa senza altre possibilità alternative.

Questa forse lunga premessa serve per arrivare  ad una semplice considerazione pratica: pretendere di usare LoRa come si usavano i classici metodi finora impiegati per l’APRS è come dire che si vuole usare una roll-royce per andare al supermercato….

Orbene attualmente la quasi totalità dei SW  LoRa APRS opera esattamente in questo modo: sfrutta unicamente il fatto che con poca potenza si riescono (almeno teoricamente) a coprire grosse distanze , rinunciando a sfruttare tutte le altre caratteristiche che il nuovo  protocollo consente…

Il nostro filone di sperimentazione è nato oramai quasi 8 anni fa con l’obiettivo preciso di cercare di sfruttare , nell’uso radiomatoriale, il protocollo LoRa al meglio….

Questo ha implicato ovviamente di crearci la possibilità di sfruttare i dispositivi HW di ultima generazione e di avere un ambiente SW in cui poter creare diverse situazioni di lavoro anche innovative o di una certa complessità…

Qualunque sperimentazione si porta ovviamente dietro una tematica che è quella di poter avere delle “metriche” per la valutazione dei “risultati” di un qualsiasi esperimento…. poter effettuare dei confronti su una base “quantitativa” è indispensabile per qualsiasi tipo di attività di sperimentazione…   da questo punto di vista il protocollo LoRa ci aiuta notevolmente in quanto intrinsecamente è in grado di fornire all’utilizzatore dei blocchi funzionali necessari per usare il protocollo, anche delle metriche … in particolare tutti i chips LoRa oggi disponibili consentono di estrarre per ogni pacchetto ricevuto una serie di parametri utili per valutare quantitativamente il funzionamento del protocollo…  in  particolare per ogni pacchetto dati detezionato questi chips rendono disponibili i valori stimati di intensità del segnale ricevuto, del rapporto segnale/rumore con cui il pacchetto è stato ricevuto, il “drift” di frequenza con cui il pacchetto è stato recuperato e il “payload” anche affetto eventualmente da errori di CRC che è stato recuperato….

Inoltre per ogni pacchetto sono sempre disponibili i parametri del “modo” LoRa utilizzato per la decodifica ovvero oltre alla frequenza di trasmissione, il valore di BW (Bandwidth) utilizzato, il valore dello SF (Spreading Factor) utilizzato oltre ad altri parametri meno significativi .

Ovviamente tutte queste metriche rendono disponibili una mole di dati potenzialmente molto grossa e che nella loro singolarità non consentono di  capirci molto…   è dall’aggregazione e dalla “post elaborazione” di questi dati analitici che si possono trarre delle indicazioni o delle conclusioni… questo pone il grosso tema di “come raccogliere” e  “come aggregare” una mole di dati generata semmai da un insieme di “nodi” dispersi geograficamente e accessibili spesso solo direttamente tramite il canale radio sotto test….

L’approccio che viene  più immediato per chi proviene dal tradizionale mondo APRS è quello di sfruttare il classico sito aprs.fi per raccogliere quanti più dati è possibile dai nodi LoRa APRS che si vanno ad installare…  questo implica in particolare che un iGate LoRa “aggiunga” in genere in coda ai pacchetti che transitano, un proprio “addon” per es. per riportare verso il sito aggregatore (aprs.fi) i valori almeno di segnale e SNR…  questa prassi purtroppo ha un effetto collaterale non trascurabile, che è quello di  mettere in crisi le metodiche di “deduplicazione” implementate dal sito aprs.fi per evitare che uno stesso spot che arriva ad aprs.fi seguendo strade diverse venga riportato più volte nonostante che si tratti sempre dello stesso pacchetto originario…

Ovviamente se la mole di traffico LoRa APRS che usa questa metodica è limitata non ci sono grossi problemi… ma se tale mole di traffico aumenta ovviamente il discorso comincia ad essere impattante… se poi si considera che attualmente l’uso che si sta facendo di LoRa APRS è tale che ogni iGate si appoggia ad aprs.fi come punto esclusivo di raccolta e display degli spots LoRa diventa ancora più grande il problema… un ulteriore elemento che rischia di aggravare ulteriormente il problema è che i tracker LoRa sono dispositivi sempre di bassissima potenza, per cui per migliorare la copertura non si trova altro metodo pratico che non sia semplicemente la creazione di nuovi iGates che inviano spesso concorrentemente verso aprs.fi n-copie di uno stesso spot lora originata da un tracker… questo deriva a sua volta dal fatto che l’utilizzo di un parametro SF=12 fornisce un bit rate utile di scarsi 300 bit/sec che impedisce completamente di implementare tecniche di “digipeating” che tipicamente servivano per “allargare” con la metodica almeno di tipo WIDE1-1 l’area di raccolta di un generico iGate.

Tutto questo fa capire come la prassi di appoggiarsi ad aprs.fi nel tentativo di fare della sperimentazione sul protocollo LoRa che consenta di utilizzare lo stesso in modo migliore di come lo si fa attualmente , è ovviamente non sostenibile …

Inoltre il fatto che aprs.fi faccia della “deduplicazione” sugli spots ricevuti fa perdere e maschera quasi completamente le dinamiche di gestione del traffico LoRa APRS che invece rappresentano il principale filone di indagine per una ottimizzazione delle prestazioni di una rete LoRa APRS…

Fin dall’inizio dello sviluppo del HW/SW LoRa Sarimesh ci siamo posti il problema di come poter fare per ottenere il massimo delle informazioni generate da un nodo LoRa ( iGate in particolare) senza doversi appoggiare ad aprs.fi….

La soluzione che  fin dall’inizio abbiamo implementato è stata quella di rinunciare ad un approccio centralizzato quale è quello attualmente fornito da aprs.fi, in favore di un approccio completamente decentralizzato che si articolasse su due livelli: un primo livello che è quello di avere dei “nodi monitor” in grado di raccogliere tutti i dati importanti sul traffico osservato e riportare questi dati verso dei nodi di secondo livello in grado di effettuare delle funzioni di aggregazione.

Tipicamente ogni nodo iGate può operare come “Nodo Monitor”, mentre titpicamente un nodo integratore dovrà necessariamente essere in grado di avere una potenza di calcolo ovviamente adeguata ad implementare oltre alle funzioni di raccolta anche delle funzioni di aggregazione, e quindi dovrà essere dotato titpicamente oltre che del necessario per raccogliere i dati prodotti dai nodi monitor, anche una CPU abbastanza potente per implementare delle funzioni SW complesse.

Questo scenario propone due tematiche su cui ragionare: la prima tematica è sul come un nodo monitor possa fare a riportare i suoi dati ad un nodo aggregatore… la seconda tematica è sul come un utente che voglia seguire la sperimentazione possa accedere ad un generico nodo aggregatore per monitorane i dati o per effettuare delle osservazioni o postelaboorazioni dei dati raccolti dall’aggregatore…

Un corollario del secondo punto è come far sì da integrare questo nuovo sistema con l’esistente sistema centralizzato (su aprs.fi) in modo da consentire una agevole “attività di approfondimento  per passi successivi” di una certa tipologia di traffico…

La soluzione proposta per il primo tema, ovvero quello della trasmissione dei dati raccolti da un nodo monitor ( in genere corrispondentente ad un iGate) ad un nodo aggregatore ovviamente è il più complesso in quanto deve poter operare ovviamente in modo completamente OFF-GRID in quanto si propone di valutare situazioni anche complesse per cui non può basarsi esclusivamente sull’uso per es. della connettività internet, anche se ovviamente deve poter utilizzare altri tipi di connettività se disponibile ( per es. la connettività internet).

La soluzione a questo problema ci viene consentita direi naturalmente e senza quasi nessun impatto dalla proprietà di ortogonalità dei modi LoRa… infatti nessuno impedisce di usare per esempio lo stesso canale usato dai tracker per l’invio dei propri spots, anche per interconnettere un generico iGate ad altri iGates che per es, vogliano operare come “nodi monitor”…. è sufficiente scegliere per tale interconnessione un Modo LoRa ortogonale a quello usato dai trackers e caratterizzato possibilmente da un bi-rate molto più elevato per trasferire verso uno o più nodi monitor tutte le info rilevati oltre che per ripetere l’intero pacchetto ricevuto operando quindi come digipeater…

Ovviamente è opportuno scegliere questo modo aggiuntivo  per es. anche con la stessa BW, ma con un SF il più basso possibile in modo da avere un tradeoff tra area di copertura e bit rate disponibile che privilegi il bit rate disponibile … una tale scelta è perfettamente in linea con gli obiettivi che questo canale ausiliario si prefigge, ovvero di interconnettere tra loro dei nodi iGate… infatti mentre per un tracker è ottimale scegliere un valore di SF molto alto (per es. SF=12 con bit-rate disponibile di scarsi 300 bit/sec) per migliorare l’area raggiungibile, per l’interconnesisone di iGates è verosimile che tali dispositivi siano posti in siti  “ottimali” ovvero in siti che abbiano una collocazione che consenta per esempio di avere delle buone coperture e quindi normalmente in siti elevati o con buona visibilità radio… quindi la riduzione del range teorico raggiungibile insito nella scelta di valori di SF bassi (per es. SF=7 con bit-rate disponibile di oltre 5 Kbit/sec) non contrasta con l’obiettivo principale che ci si propone e consente di minimizzare il tempo di indisponibilità del canale radio consenguente al fatto che tipicamente essendo tutti i chips LoRa di tipo half-duplex, comunque utilizzando in un certo nodo un dispositivo che trasmette, necessariamente in questo stesso sito non sarà possibile operare anche uno o più ricevitori colocati con il trasmettetitore  simultaneamente ( per evitare ovviamente pesantissime complicazioni circuitali).

In pratica se si considera che nel modello di lavoro delineato il traffico originato dai tracker è nel caso migliore di non più di circa 300 bit ( con SF=12) anche considerando la presenza di un traffico inter i-Gates (per es. con SF=7) significativo è ben difficle ipotizzare che si creino situazioni di congestione sul canale ausiliario.

In agginuta a quanto sopra ovviamente è sempre possibile ipotizzare che un tracker possa utilizzare per inviare i sui spots un valore di SF pari a quello usato dal canale ausiliario… questo in quanto è evidente che nello scenario delineato in una certa zona oltre ad una serie di iGates “legacy” ovvero in grado di usare una singola radio LoRa, e quindi in grado per es. di ricevere solo traffico con SF=12,  e trasmettere solo con SF= 7 ( ad esempio…) , ci potrebbero essere anche uno o più nodi a doppia radio LoRa che per es. siano in grado di ricevere simultaneamente su due modi LoRa e quindi siano in grado di ricevere anche traffico con SF=7 dai tracker oltre che da altri iGates… in questo scenario ovviamente aumenterebbe il traffico generato dai trackers+iGate e questo potrebbe potenzialmente creare delle condizioni di congestione… è quindi evidente che con questo modello di operazione sarà importante che gli iGates includano eventualmente funzioni di “traffic engineering” atte a limitare tali situazioni…

Da tutte le argomentazioni su-esposte si intuisce il motivo per cui il nostro gruppo già da alcuni mesi ha reso disponibile dei circuiti HW (PCB)  in grado di operare con una doppia radio LoRa… proprio per poter supportare questa nuova modalità operativa…

Resta ovviamente a questo punto da affrontare e risolvere il problema di come collegare questo nuovo modo di monitorare il traffico LoRa  APRS con l’universo tradizionale APRS centrico sull ‘uso di aprs.fi:  la chiave è in una feature che nel nostro SW è stata anche questa già pensata fin dalle origini,  ma implementata solo recentissimamente… è la funzione di “Magic Tag”…  in pratica un nodo LoRa ( sia esso un tracker o un iGate) può inserire nel corpo del campo commento una brevissima stringa di caratteri alfanumerici che viene modellata come un URL, ovvero l’indicativo di un sito web, costruito in modo da contenere in modo semi-codificato una serie di informazioni destinate a far “atterrare” un visitatore che si trova ad osservare lo spot sui portali aprs.fi e collegati ( ad es. aprsdirect) su un certo sito che fa da interfaccia ad un nodo di aggregazione sopra descritto…  questo “Magic Tag” ha la proprietà di non essere modificato  ( almeno normalmente) dagli iGates che si trovano a processare e smistare i pacchetti LoRa per cui transitano senza produrre alcun tipo di problema ai meccanismo di “deduplicazione” usati da aprs.fi .

In realtà il meccanismo MagicTag è pensato per svolgere tutta una serie di funzioni, che a questo livello stiamo ancora studiando,  il cui obiettivo è di creare una relazione di tipo bidirezionale tra i peer coinvolti in una certa “zona di copertura” intendendo con tale locuzione indicare un insieme di dispositivi in grado di gestire il meccanismo dei “MagicTags”.

Nelle figure a seguire si illustrano alcuni esempi di quanto ora descritto, e si rimanda ad un futuro articolo per una descrizione più dettagliata della funzione MagicTag.

A brevissimo renderemo disponibile su questa pagina la possibilità di scaricare delle nuove immagini SW del SW Sarimesh vr. 5.1.3 che include il supporto di questo primo livello di funzionalità.

Una descrizione di come praticamente impostare un dispositivo LoRa su cui è installata la versione 5.1.3 del SW Sarimesh Core  è disponibile al seguente indirizzo:

“come-settare-la-modalita-magictag-nel-sw-sarimesh-core-vr-5-1-3”

 

Immagini SW Sarimesh LoRa Vr. 5.1.3

Di seguito le immagini SW Vr. 5.1.3 relative all’utilizzo su dispositivi TTGO Vr. 1.1 , Heltec Tracker  e su tutti i dispositivi HW Sarimesh sia a singola radio che a doppia radio.

full_flash_image_heltec_tracker_20240606_2249.bin

full_flash_image_LoRa_Tracker_Sarimesh_Mini_20240605_2059.bin

full_flash_image_ttgo_1_1_20240605_2057.bin

Istruzioni dettagliate sul come caricare le nuove immagini SW , sui classici schedini TTGO Vr. 1.1 in particolare, sono disponibili alla seguente pagina web

“sperimentazione-lora-familiarizziamo-con-la-nuova-release-sw-5-x”

Conclusioni

Questa proposta come è ben evidente non solo fornisce una metodica per raccogliere dati per scopi di testing e sperimentazione, ma fornisce un modo per aprire il protocollo LoRa APRS a tutta una nuova serie di applicazioni in quanto rende disponibile una modalità che mantiene la compatibilità con la base installata e nello stesso tempo consente di rendere praticamente utilizzabile in parallelo un nuovo canale con SF tale da consentire di avere dei bit-rate utili molto più alti del classico SF=12 e quindi consentire di implementare nuove applicazioni che richiedono di scambiare dati in quantità maggiore… inoltre consentendo questa modalità operativa di aggregare a livello di aree locali più iGates, consente di avere uno strumento per realizzare applicazioni completamente di tipo OFF-GRID utilissime soprattutto a fronte di situazioni emergenziali, ed infine consente di ridurre drasticamente il numero di iGates che inviano direttamente ad APRS-IS i loro dati in modo da ridurre l’entità del lavoro di deduplicazione a cui aprs.fi è costretto.

 

 

…