Negli ultimi articoli abbiamo illustrato una nuova proposta tendente a fornire uno strumento di analisi dettagliata del traffico APRS in una certa zona geografica che fosse in grado di coesistere ed integrarsi con l’attuale architettura del sistema APRS e che fosse però in grado di fornire degli strumenti aggiuntivi utilizzabili nel caso di traffico LoRa-APRS,  allo scopo di poter effettuare degli studi più approfonditi sull’uso del protocollo LoRa con riferimento all’applicazione APRS.

In pratica l’utilizzo del protocollo LoRa per implementare le funzioni del sistema APRS consente molta più flessibilità che non il classico sistema basato sulla modulazione AFSK … negli articoli precedenti pubblicati su questo sito abbiamo più volte accennato a queste features aggiuntive che il protocollo LoRa possiede e che finora sono state completamente neglette riducendo l’applicazione LoRa ad una brutta copia del classico APRS.

Per sfruttare però a pieno tale flessibilità è necessario essere in grado di fare dello strudio allo scopo di individuare in maniera più precisa gli impatti di diverse impostazioni di utilizzo del protocollo LoRa: questo è possibile grazie alle features presenti nei chipset LoRa disponibili, ma questa possibilità non è sfruttata o sfruttabile con gli attuali metodi di valutazione del traffico APRS sostanzialmente vincolati all’uso della rete APRS-IS e del sito aprs.fi che fa da aggregatore unico e centralizzato di tutti i dati prodotti dai dispositivi APRS  in funzione.

Questa situazione ovviamente non è assolutamente un demerito dell’esistente ma è semplicemente un defacto storico per un sistema che è nato svariate decine di anni fa e che ha dato sempre ottimi risultati .

Quello che la nostra proposta cerca di fare è aggiungere all’esistente metodologia di collezionamento di spots APRS una nuova possibilità da sfruttare solo ed esclusivamente in un ambito “locale” e solo ed esclusivamente per il traffico LoRa  allo scopo di avere la possibilità di collezionare delle metriche ( quindi uno strumento quantitativo oltre che qualitativo) relative al comportamento del traffico LoRa per scopi di ottimizzazione dei suoi parametri  di setup e di uso.

Ovviamente il primo problema che ci siamo posti è stato: come integrare un nuovo sistema con l’esistente ?

La soluzione che abbiamo pensato è semplicemente quella di creare una possibilità molto semplice per consentire di accedere al nuovo sistema dall’esistente sistema centrico su aprs.fi… la strada che abbiamo pensato di utilizzare è descritta nell’articolo precedente destinato an introdurre  la funzionalità di “MagicTag“:  semplicemente inserendo un URL molto corto che punta ad un sito aggregatore locale nel campo commento dei pacchetti LoRa (e solo di quelli…) viene creata la possibilità di trasferirsi da un qualsiasi portale basato su aprs.fi ( ad es. anche dai portali che usano il SW aprsDirect)  al sistema dedicato a LoRa .. in questo modo si evita di creare qualsasi tipo di problema ai meccanismi di deduplicazione tipici della rete APRS-IS e si ottiene comunque la possibilità di collegare logicamente i due sistemi: quello tradizionale basato su aprs.fi e quello nuovo decentralizzato. L’impatto in termini di incremento del payload a livello LoRa è abbastanza limitato e la prassi di inserire un URL nel campo commento è consolidata da tempo ed usata già per gli scopi più disparati.

Il secondo problema che ci siamo posti è stato quello di che architettura utilizzare per il nuovo sistema di reporting: anche questo aspetto è già stato introdotto negli articoli precedenti ed è sostanzialmente basata sul concetto di “nodi monitor” e “nodi aggregatori”:  ovvero in una rete ( solo RF LoRa) si assume che ci possano essere una serie di nodi in grado di collezionare dati analitici di performance per il traffico LoRa che quel nodo è in grado di processare e trasferire questi dati a dei nodi aggregatori che siano in grado di raccogliere questi dati analitici e di aggregarli in modo da consentire di correlarli e di effettuare delle postelaborazioni sui dati collezionati.

E’ evidente che in pratica ogni nodo iGate LoRa possa, volendo, operare come nodo monitor, come pure è chiaro che un nodo aggregatore dovrà essere in grado di collegarsi alla rete LoRa e alla rete internet o più in generale TCP/IP allo scopo di poter consentire di accedere a tali nodi aggregatori dal lato internet sfruttando il meccanismo del MagicTag.

Un corollario del punto precedente è come organizzare il trasferimento dei dati analitici dai singoli nodi monitor al sito aggregatore, considerando che il nodo aggregatore deve essere collegato ad internet  e che i singoli nodi monitor potrebbero essere collegati ad internet MA NON NECESSARIAMENTE…  anzi l’obiettivo è proprio quello di analizzare reti in cui i nodi iGate NON siano necessariamente collegati ad internet, ma operino come nel tradizionale APRS ovvero usando la funzione di digipeating…..

Questo problema sottende l’analisi di due aspetti: il primo aspetto è il formato logico dei dati analitici che si devono scambiare un nodo monitor ed un nodo aggregatore, il secondo aspetto è il come questi dati analitici possano essere veicolati tra nodo monitor e nodo aggregatore, considerando che in questo aspetto bisogna considerare due situazioni, ovvero il caso in cui entrambi i nodi siano collegati ad internet, ed il secondo caso in cui il nodo monitor sia solo collegato alla rete LoRa.

E’ ovvio che i due casi di cui sopra sono molto diversi in quanto nel caso di un collegamento internet disponibile non esiste in pratica nessun problema di “compattezza” del protocollo di trasferimento per cui un qualasiasi formato anche che introduca una significativa ridondanza, è utilizzabile; nel secondo caso ovviamente se si pensa di utilizzare un “canale di ritorno” da un nodo LoRa verso un altro nodo LoRa via radio il discorso diventa estremamente difficoltoso…

Quindi l’elemento critico per tutto il discorso è chiaramente questo secondo caso, mentre il primo caso può essere visto come un caso particolare che sposi la struttura dei dati di dettaglio studiati per essere trasportati secondo le modalità del primo caso.

Un ulteriore elemento critico sempre del secondo caso è l’esigenza di avere un canale di ritorno.... ma in realtà questo non è un punto critico per il semplice motivo che uno degli argomenti a cui si vuole arrivare con tutta la nostra attività di studio è proprio quello vedere come rimuovere l’assenza di un canale di ritorno nella attuale standard de facto che consente solo ed esclusivamente, in pratica, l’utilizzo del canale LoRa in maniera monodirezionale ( a pena di un pesantissimo problema di congestione che emerge immediatamente qualora si pensasse di usare un canale di ritorno che non fosse su frequenza diversa dal canale primario … con l’effetto di raddoppiare in pratica la banda RF occupata , già enorme con l’attuale scelta di usare un BW=125 KHz).

Da questi ragionamenti allora penso emerga chiaramente che uno dei temi chiave per qualsiasi altro discorso sia come implementare un canale di ritorno senza ampliare la banda RF impegnata dal servizio LoRa APRS e facendo in modo che tale canale di ritorno sia di larghezza decisamente maggiore del canale primario a cui comunque si lascia la funzione di canale di default da utilizzare per il traffico LoRa, in modo da garantire la compatibilità con tutta la base installata esistente attualmente.

Se ci dovessimo basare sulle caratteristiche del classico protocollo APRS a cui tutti siamo abituati da decenni, l’unica  possibilità sarebbe quella di usare delle metodiche classiche per implementare un modem ad alta velocità… ovviamente è una strada già percorsa e che però ovviamente ha i suoi costi ed i suoi vincoli…

Siccome però il nostro tema è usare LoRa, ecco che allora tutto miracolosamente si semplifica e banalizza....  LoRa per come è stato definito ed implementato consente flessibilmente di utilizzare un canale radio in tante modalità diverse in modo da consentire di sfruttare un singolo canale per veicolare una molteplicità di diversi flussi informativi LoRa che NON si interferiscono mutuamente, grazie alla proprietà di ORTOGONALITA’ dei segnali LoRa...  questa proprietà consente, scegliendo opportunamente i parametri di trasmissione, di avere in pratica la possibilità di utilizzare lo stesso canale per tanti diversi flussi di comunicazione simultaneamente ed in modo indipendente.

Come ulteriore beneficio della flessibilità di cui sopra ci sta la possibilità di poter effettuare un tradeoff tra diversi aspetti della comunicazione: infatto usando valori diversi del parametro SF (Spreading Factor)  si può far in modo da avere un bitrate utile del canalae digitale maggiore a discapito di un giadagno di processo minore o viceversa… questo ovviamente rappresenta lo “scotto” da pagare se si vuole un canale veloce rispetto ad un canale di estrema “sensibilità”.

Esiste poi una ulteriore dimensione in cui eventualmente poter lavorare ed è quella della BW del canale LoRa: questa variabile in realtà è da considerare una estrema ratio da usare solo in caso di impossibilità di usare la classica BW=125KHz, in quanto ovviamente non consente di mantenere , qualora la si voglia utilizzare anche sul canale primario, la compatibilità con l’esistente.

Quindi ritornando al discorso del  “canale di ritorno” una soluzione che da qualche tempo stiamo  testando e che sembra dare un ottimo compromesso tra ampiezza della zona di copertura ( per il canale di ritorno) e altri aspetti collaterali è quello di associare ad una impostazione del canale principale da tracker a iGates con frequenza=433.775 MHz, BW=125 KHz e SF=12,  una impostazione del canale di ritorno con frequenza=433.775MHz, BW=125 KHz e SF=7 .

Una tale impostazione consente di lasciare l’attuale de facto setup del canale primario con i suoi teorici max 292 bit/sec di bit rate disponibile,  e di avere un canale di ritorno con un bitrate disponibile di 5340 bi/sec decisamente superiore al bitrate del canale primario.

La scelta di un SF=7 consente di implementare il canale di ritorno anche su tutti dispositivi che usano ancora chipset LoRa di prima generazione ( es. basati su sx127x) che non supportano valori di SF inferiori… usando infatti chipset di seconda generazione si potrebbe ulteriormente abbassare il valore di SF fino a 5 con un ulteriore significativo incrementoo del bitrate disponibile.

Sulla base di queste considerazioni, ovvero avendo trovato una soluzione per implementare un canale radio LoRa di ritorno, diventa agevole implementare la modalità di riporto dei dati analitici raccolti da un iGate, verso i nodi aggregatori fruttando in alternativa o simultaneamente la modalità via internet o la modalità via LoRa sfruttando il canale di ritorno.

Questa seconda opzione è in realtà forse quella che potremmo definire quella “preferred” per un motivo abbastanza semplice che ora andiamo ad illustrare:  finora un qualasiasi tracker è stato in effetti un dispositivo completamente “cieco” nel mondo LoRa locale nel senso che non è  stato in grado di aver alcun feedback dagli iGate eventualmente presenti sul territorio a causa della mancanza della funzione digipeater attivata sugli iGates LoRa… questo faceva si che l’unico modo per capire se si stava o meno in una certa “zona di copertura” mentre si navigava in macchina, era accendere il cellulare e andare su aprs.fi….

Grazie ora all’esistenza e alla utilizzabilità di un canale di ritorno diventa agevole e fattibile avere gli iGates (anche quelli tradizionali con leggere modifiche) in grado di effettuare la funzione di digipeater o almeno di inviare dei messaggi di ritorno in aria per dare evidenza della propria esistenza e soprattutto dare per es. feedback ai tracker in zona del fatto che l’iGate li sta ricevendo….  questo consente finalmente ai tracker di mostrare sul display locale anzicchè i soliti dati statici del dispositivo o al meglio la posizione dell’auto, anche e soprattutto lo stato della rete LoRa, ovvero la visibilità , come era classico nei vecchi APRS, degli altri dispositivi LoRa presenti nella zona…  certamente un dato simpatico che mancava rispetto al classico APRS…

Da queste considerazioni abbiamo tratto spunto per definire a questo punto una modalità di “formattazione” dei dati analitici che un nodo iGate  riesce ad estrarre da ogni singolo pacchetto processato e che tenta di trasferire ad uno o più nodi aggregatori via radio LoRa o via internet: il formato ovviamente conterrà come obbligatori i soli dati specifici di un certo pacchetto, mentre altri dati potranno essere presenti opzionalmente in quanto semmai non specifici di un certo singolo pacchetto, ma più genericamente caratteristici del nodo monitor che genera tali pacchetti.

Sulla base delle features disponibili sui chupset LoRa ttualmente disponibili i parametri misurabili per ogni pacchetto sono i seguenti:

• nodo che sta effettuando il reporting ( ovvero SSID del nodo che ha ricevuto il  pacchetto LoRa)
• valore  dell’intensità di segnale stimata dal chiset per il  pacchetto espresso in dbm
• valore del rapporto segnale/rumore SNR stimato per il pacchetto ricevuto espresso in db
• valore del “drift” di frequenza che l’algoritmo di decodifica ha stimato in Hz
• una indicazione di CRC error per il pacchetto ricevuto
• il payload completo ricevuto e parzialmente decodificato dal chipset a meno di errori dovuti alla presenza della indicazione di CRC errored packet

 

Oltre a questi dati che sono estraibili da ogni singolo pacchetto esistono altri dati di funzionamento utili a inquadrare lo stato operatovo del canale e che rppresentano dati di configurazione del nodo ricevente; in particolare:

• caratteristiche del nodo in termini di equipaggiamento ( es. chipset LoRa, modulo LoRa, presenza di TCXO, presenza di due radio LoRa, tipo di antenna,  etc)
• caratteristiche di funzionamento attuale del nodo in termini di parametri LoRa in uso ( in ricezione e in trasmissione) :
  • valore della frequenza di trasmissione in MHz
  • valore della larghezza di banda utilizzata BW in KHz
  • valore dello Spreading Factor SF in uso
  • valore del Coding Rate CR in uso
  • valore della lunghezza del preambolo LoRa in uso
  • stato di attivazione del CRC
  • valore del LoRa Sync in uso
  • valore della potenza di trasmissione in uso
• Parametri ambientali del nodo ( es. temperatura, pressione atmosferica, stato delle batterie, etc.)

 

Ovviamente non tutti questi dati ha senso che siano “trasmessi” da un nodo tramite la nuova modalità di reporting, anche perchè  molti di questi parametri hanno già una loro classica modalità di trasmissione quali ad es. le condizioni meteo  o i parametri tipo lo stato delle batterie che sfruttano le funzioni di telemetria.

In pratica il nuovo strumento dovrebbe essere limitato al solo reporting di parametri non già disponibili tramite le classiche modalità di reporting ben supportate dal sistema basato su aprs.fi….

La scelta quindi è caduta sul seguente formato di riporting per singolo pacchetto:

• un carattere delimitatore di tipo “(” (parentesi tonda aperta)
• valore del SSID completo del nodo riportante
• valore dell’intensità di segnale misurato in dbm per il pachetto privo di decimali
• valore del SNR misurato in db  per il paccheto privo dei decimali
• valore del frequency drift misurato in Hz privo di decimali
• un carattere letterale che indica il tipo e/o l’identità della radio che ha ricevuto il pacchetto ( codificato in modo da far capire eventualmente la presenza di TCXO e/o l’identità della radio per sistemi con più di una radio on board)
• un carattere di “)” ovvero parentesi chiusa per delimitare il gruppo di caratteri che compongono il record di report.

 

esempi potrebbero essere i seguenti

• • (IZ8QJS-10 -60 12 333A)     report per un pacchetto ricevuto da IZ8QJS-10  con una intensità di segnale di   -60dbm , un valore di SNR di 12 db e uno scostamento di frequenza di 333Hz; il ricevitore usa una radio dotata di TCXO ( A maiuscola)
  • (I8FUC-10 -132 -19 -542B)     report per un pacchetto ricevuto da I8FUC-10  con una intensità di segnale di   -132dbm , un valore di SNR di -19 db e uno scostamento di frequenza di -542Hz; il ricevitore usa una radio dotata di TCXO ( B maiuscola) che è una radio secondaria ( il nodo possiede due radio)

 

Questo formato è stato scelto in quanto facilmente “parsabile” e perchè ha un formato “parlante” ovvero agevolmente decifrabile senza consultare particolari tabelle di corrispondenza. Questo gruppo di caratteri costitusce il “report” che ogni nodo iGate aggiungerà in coda al campo commento del pacchetto ricevuto e che sta per essere ritrasmesso, se la funzione di digitepeating è abilitala, per tutti i pacchetti ripetuti verso il lato LoRa;  verso il lato APRS-IS NON verrà assolutamente aggiunto nessun addon al pacchetto come ricevuto a monte dai trackers.

Questa modalità consentirà ad un generico iGate di trasferire i suoi “dati analitici” ad un nodo aggregatore via rete LoRa semplicemente tenendo attiva la funzione di dipeating e senza altri impatti a parte l’allungamento del paylod trasmesso a causa dl gruppo di caratteri aggiunti.

Se un iGate che opera come nodo monitor non riesce a raggiungere il suo nodo aggregatore tramite rete LoRa, potrà utilizzare per trasferire l’esatto gruppo di caratteri verso il nodo aggregatore sfruttando la connettività internet.

In questo caso si pone il problema di quale formato utilizzare per il trasferimento dei dati analitici verso il server di aggregazione.

A questo proposito abbiamo cercato di evitare di re-inventare la ruota… e guardando la storia di APRS e dei SW più diffusi e consolidati, la nostra attenzione è caduta sul formato di logging dettagliato usato dal SW Direwolf già da anni a questa parte… tale formato fornisce una serie di interessanti opportunità e risulta agevolmente parsabile … a seguire riportiamo il formato dei pacchetti di logging estratta dallo user manual di Direwolf:

Nel caso specifico i dati dettagliati raccolti da un nodo vengono semplicemente aggiunti al campo Commento come avviene per i pacchetti ripetuti verso il lato LoRa del iGate che opera come nodo monitor.

Grazie a questo modo di effettuare il reporting diventa agevole per un nodo aggregatore affasciare i dati ricevuti da un qualasiasi iGate, siano essi dati relativi a pacchetti ricevuti direttamente da un tracker, sia che siano pacchetti transitati su altri iGates…  un esempio di records che il nodo aggregatore si troverà a ricevere è riportato nella figura seguente.

Come si può notare usando il formato di logging di Direwolf si hanno per ogni record una serie di dati relativi ad ogni pacchetto tra cui il time_stamp del pacchetto, le identità del nodo sorgente, le coordinate geografiche della sorgente dello spot,  alcuni campi caratteristici della componente APRS del pacchetto e l’intero campo commento che conterrà i dati dettagliati che ogni singolo pacchetto avrà raccolto nel suo peregrinare sulla rete LoRa…

Per quanto riguarda il formato di tramsissione dei dati su TCP/IP si utilizza la modalità UDP sfruttando la porta 44444:  sfruttando questa modalità è molto agevole creare un semplice server dal lato nodo aggregatore in grado di collezionare pacchetti provenienti da una molteplicità di nodi monitor; ovviamente una modalità UDP non protegge da possibili perdite di pacchetti, ma questo è certamente uno scotto accettabile alla luce della semplicità di implementazione del sistema di collezione dei pacchetti che può tollerare anche la perdita di alcuni pacchetti… In futuro si potranno eventualmente implementare ulteriori modalità qualora emergesse una esigenza stringente in merito a tale aspetto. 

Una menzione particolare meritano i pacchetti “CRC errored” identificati dai chips LoRa che processano i pacchetti…. il chip è in grado di restituire il payload del pacchetto compresi eventualmente dei caratteri errorati… questo purtroppo rende difficile il reporting di tali pacchetti in quanto sarebbe necessario implementare delle metodiche di incapsulamento che renderebbero inutilmente complesso il processo il reporting… quindi è stata fatta la scelta di NON propagare i pacchetti errorati ma introdurre la possibilità per l’ultimo nodo LoRa attraversato di riportare il numero di pacchetti errorati detezionati … questo indicatore per il momento non viene utilizzato e resta per usi futuri.

Come si può osservare dall’ultima figura un nodo aggregatore in pratica si ritroverà a ricevere una serie di records in ordine temporale ordinato e che potranno essere storicizzati a scelta eventualmente usando un qualsiai sistema di storage, per es. di tipo semplicemente testuale o anche usando un opportuno database…

Allo stato essendo il discorso ancora ad uno stato iniziale viene semplicemente usato un approccio testuale per lo storage degli spots raccolti ed il SW di analisi che provvede ad estrarre un primo insieme di elementi di presentazione è scritto in PHP con un sito web minimale che fa da frontend ai dati raccolti; in futuro è possibile espandere questa componente funzionale per implementare ulteriori funzionalità.

Le figure seguenti rappresentano un esempio di schermate disponibili sulla interfaccia WEB del sito aggregatore di prova…

 

Come si può osservare sulla sommità della pagina è presente una lista di links a diversi intervalli temporali sia del tipo “ultime ore” che del tipo “giorno”…   è poi possibile accedere alla lista testuale degli spots ricevuti come pure è possibile selezionare un diverso nodo monitor a cui la grafica fa riferimento…

La mappa presentata in particolare riporta tutti i pacchetti ricevuti da un preciso nodo monitor… i pacchetti sono referenziati con un pallino di colore verde con una linea tratteggiata verso il nodo monitor per indicare pacchetti direttamente ricevuti dal nodo monitor senza transitare su altri nodi, e da un pallino rosso per indicare un punto da cui è stato possibile ricevere un pacchetto LoRa ma transitando su altri iGates…

Analoghe considerazioni vengono usate per la lista testuale dei records accumulati dal sito aggregatore relativamente al nodo monitor e all’intervallo temporale indicati nell’attuale stato delle pagine.

Ovviamente ognuno dalla osservazione delle mappe disponibili potrà trarre sue considerazioni… volendo è possibile estrarre i records dalla base dati accumulata ed analizzarli da altri punti di vista alla ricerca di specifche indicazioni.

La disponibilità di dati quantitativi ed analitici associati alla geolocalizzazione e allo stamping temporale consente ovviamente di fare eventualmente anche dei confronti tra diverse situazioni o configurazioni di lavoro che si intendono confrontare.

Un altro esempio di dati estraibili da queste mappe è la stima dell livello di copertura di una certa zona da parte di uno o più iGates…  l’esempio delle  figure di cui sopra è  un caso in cui è evidente che la zona attraversata è ampiamente coperta da almeno due diversi iGates in quanto si notatno puntini verdi e rossi alternati ad indicare appunto che da quel percorso era possibile evidentemente per il nodo monitor ricevere degli spots sia direttamente che tramite altri iGates presenti nella zona.

Ovviamente tuttle le considerazioni fatte finora prescindono completamente dall’utilizzo della piattaforma aprs.fi e forniscono un tool completamente di tipo OFF-GRID in grado di funzionare autonomamente indipendentemente dalla presenza di connettività internet nella zona oggetto di analisi.

Giusto a completamento del discorso è nche interessante vedere come si possa arrivare a queste schermate di dettaglio analitico sfruttando i classici portali e SW basti su aprs.fi…

La figura seguente è un esempio di cosa si vede su aprs.fi per i pacchetti LoRa generati da un tracker che usa la strategia di reporting sopra descritta…

Cliccando sul URL indicato  da MagicTag si viene automaticamente addotti alle pagine dei dati analitici discussi finora.

 

analogamente usando  un tool basato sul SW aprsDirect ( che a sua volta sfrutta i dati raccolti via APRS-IS alla stregua di aprs.fi)  si ha un esempio come alla figura seguente

Attualmente le funzionalità indicate sono già supportate nella versione del SW Sarimesh Core vr. 5.2 di prossimo rilascio , mentre la componente del sito di aggregazione è attualmente ancora in fase di sviluppo allo scopo di fornire la possibilità ad un nuovo utente di registrare dei propri nodi Monitor sul sito di aggregazione in modo da poter sfruttare lo stesso sito aggregatore in maniera remota tramite internet ed evitare di dover creare un proprio sito di aggregazione ad hoc per le proprie sessioni di sperimentazione.

Siamo ovviamente disponibili a ricevere ogni possibile osservazione o proposta di modifica allo scopo di ulteriormente migliorare la proposta . Per ogni esigenza è possibile contattarci all’indirizzo  di mail    info@sarimesh.net