L’estate appena conclusasi è stata l’occasione per far decantare una serie di idee e per cominciare a verificare la fattibilità concreta delle stesse… grazie alla collaborazione di alcuni nuovi OM che hanno fornito interessanti stimoli e suggerimenti abbiamo cercato di meglio definire alcuni aspetti tecnici nonchè introdurre nuove funzionalità  con l’obiettivo di arricchire gli strumenti a disposizione per supportare l’attività di sperimentazione e cominciare concretamente a rendere disponibile finalmente una modalità di migrazione “trasparente” dalla modalità di trasmissione LoRa tradizionale a 300 bit/sec , alla nuova modalità di trasmissione highSpeed a oltre 5300 bit/sec.

Tutte queste novità hanno portato a definire una nuova major release del SW Sarimesh ( vr. 6.0.x) che a breve sarà disponibile per gli interessati; questa nuova release introduce rispetto alle precedenti versioni alcune modifiche anche alla interfaccia grafica sul display fisico dei dispositivi, per meglio orientarla alle nuove funzionalità disponibili.

Grossolanamente possiamo dire che le nuove funzionalità investono le quattro seguenti aree funzionali:

1. Introduzione della metodologia di connessione remota tramite VPN (Virtual Private Network) per la gestione remota anche centralizzata dei dispositivi ( in particolare gli iGates) e di un sistema di controllo degli accessi  alla gestione dei nodi tramite credenziali.
2. Nuove funzionalità nel meccanismo di “MagicTag”
3. Introduzione della funzionalità di “Agile RTX” consistente in un meccanismo automatico di commutazione del modo di trasmissione da LowSpeed ad HighSpeed e viceversa in funzione delle risorse di rete (iGates) disponibili in un certa zona.
4. Ri-orientamento della interfaccia grafica locale (display) per adeguarsi alle nuove funzionalità.

 

Di seguito una breve descrizione delle suindicate funzionallità allo scopo di illustrane le caratteristiche e le possibili modalità di sfruttamento; in successivi articoli andremo poi ad approfondire le stesse funzioni entrando nei dettagli di configurazione e di utilizzazione delle stesse.

Connessione remota tramite VPN ad un generico nodo LoRa

Il SW LoRa Sarimesh fin dall’inizio ha reso disponibili come modalità di gestione e di configurazione due modalità entrambe basate sull’utilizzo della connettività TCP/IP: una interfaccia grafica basta sul protocollo HTTP ed  usabile tramite un qualsiasi browser WEB, ed una interfaccia a linea di comando usabile tramite protocollo Telnet usando un qualsiasi emulatore di terminale.

Entrambe le modalità erano pensate ovviamente per un utilizzo locale di configurazione e gestione dei nodi e quindi senza pensare a un sistema di accesso “pubblico” o tramite una rete TCP/IP non sicura.

Con il passare del tempo ed il progredire della sperimentazione è stato però subito evidente che si rendeva necessario spesso essere in grado di effettuare delle operazioni di gestione e manutenzione remota su nodi iGates o per questioni logistiche ( nodi installati in luoghi difficilmente raggiungibili), o per più banali problemi di aiuto alla configurazione e gestione remota  per  il gestore del nodo o per approfondimenti e diagnostica.

Una prima modalità che venne introdotta e che è ancora in realtà disponibile, consentiva di effettuare alcune limitate funzioni, quali ad esempio acquisite lo stato di un nodo o effettuarne il restart, sfruttando una metodica basata sull’uso del protocollo MQTT allo scopo di poter accedere da remoto ad un nodo senza richiedere alcun tipo di intervento sul tipo di interfacciamento del nodo verso la rete internet ( quali ad es. impostazioni ad hoc sul router presente presso il nodo remoto).

Quello che è stato implementato con la release 6.x del SW Sarimesh è ora un completo sistema di accesso remoto ad un generico nodo ( iGate in particolare) basato sulla implementazione di una funzionalità di VPN  che sfrutta il protocollo WIREGUARD:  questa modalità di realizzazione di un collegamento VPN è ad oggi la soluzione più interessante e potente per realizzare una VPN e presenta una serie di vantaggi che la rendono ottimale in particolare per sistemi “embedded” come sono i nostri nodi LoRa.

L’introduzione di questa funzionalità consente a questo punto di ottenere una serie di grossi di vantaggi che di seguito si elencano:

1. diventa possibile realizzare un canale TCP/IP criptato attraverso la rete internet su cui far transitare tutti i protocolli di gestione del generico nodo rendendo “sicuro” il modo di gestione anche continuando ad usare i tradizionali protocolli HTTP e Telnet senza dover ricorrere ai molto più esigenti (in termini di risorse di processo e di memoria richiesta) HTTPS o SSH.
2. Diventa possibile implementare la connessione VPN senza richiedere assolutamente nessun tipo di intervento sulle apparecchiature di connessione ad internet che si utilizzano per connettere il nodo alla rete.
3. Diventa possibile gestire un nodo remoto utilizzando un qualsiasi terminale fisico sia di tipo fisso (PC) che di tipo personale o portatile quali ad es. smartphone di praticamente qualsiasi marca,  e questo sia da postazione fissa che da apostazione mobile.
4. Diventa possibile operare in remoto su un qualasiasi terminale ( collegato ovviamente ad internet) sia per le normali operazioni di gestione tramite GUI o telnet, che per operazioni di aggiornamento del SW del nodo.
5. Diventa possibile organizzare un sistema di accesso remoto ad una molteplicità di dispositivi ovunque installati in modo da monitorarne e coordinarne l’operatività da un unico sistema di controllo , per es. un PC, potendo realizzare per es. operazioni remote multinodo anche di tipo automatizzato.

 

Ovviamente a questi vantaggi si associa immediatamente l’esigenza di introdurre un sistema di accesso condizionato alle interfaccie di gestione tramite credenziali : in particolare è stato introdotto allo stato  unicamente un sistema di accesso basato su un singolo utente con password associata e senza alcun sistema di privilegi; in futuro volendo potrà essere possibile espandere il sistema in qualcosa di più articolato.

Per supportare questa nuova modalità di connesisone è stato necessario introdurre in alcune schermate della GUI delle nuove informazioni necessarie per poter settare una connessione VPN; in particolare per come è organizzato il protocollo wireguard è necessario individuare tra le altre informazioni anche delle opportune “chiavi” che vengono sfruttate dal protocollo per crittografare la trasmissione e per autenticare i punti terminali del collegamento VPN.

In pratica ogni nodo terminale wireguard necessiterà per poter interagire con altri terminali di una coppia di chiavi:

1. una chiave “privata” costituita da una lunga stringa di caratteri alfanumerici  opportunamente generata tramite udegli appositi tools e che verrà tenuta “segreta” per quel terminale e non verrà mai trasmessa in linea.
2. una chiave “pubblica” anch’essa costituita da una lunga sequenza di caratteri alfanumerici e generata sempre tramite dei tool ad hoc a partire dalla chiave privata scelta: tale chiave come dice il nome stesso potrà essere resa disponibile a chiunque intenda connetersi al nostro terminale per realizzare una connessione VPN e consentirà automaticamente anche di “autenticare” il terminale.
3. la coppia di chiavi così organizzata  andrà generata per ogni terminale che si intende far collegare ; in pratica affinchè due terminali si possano collegare e possano mettere su un tunnel criptato dovrà essere verificato che le coppie di chiavi siano corrette nel senso che ogni nodo al setup del collegamente dovrà essere configurato con le proprie chiavi pubblica e privata e con la chiave pubblica del nodo a cui intende collegarsi. Analogamente dovrà fare il nodo corrispondente all’altro estremo.

 

Oltre alle chiavi di cui sopra, sarà necessario impostare una serie di altri dati che di seguito vengono descritti:

1. il nome del link a cui il nodo intende collegarsi: è uno mnemonico per  individuare l’altro estremo del collegamento; nella attuale implementazione viene previsto un unico link ; in futuro potranno essere eventualmente previsti diversi link con un opportuno metodo di attivazione /disattivazione.
2. l’indirizzo IP del nodo remoto a cui il link intende connettersi: in genere sarà un indirizzo pubblico di un server “Wireguard”  in grado di accettare una richiesta di collegamento; a seguire qualche ulteriore osservazione su questo punto.
3. un numero di “porta” UDP su cui il server è in ascolto per le richieste di connessione.
4. un indirizzo IP “locale” da assegnare all’estremità del tunnel criptato che verrà creato.

 

Tutte queste informazioni sono inseribili in un nodo LoRa tramite una aggiunta alla schermata già presente di “NETWORK SERVICES” come da figura a fianco.

Ovviamente la funzionalità di VPN potrà essere o non essere attivata a seconda delle esigenze: allo scopo è stato introdotto un  opportuno flag nella schermata di “OPERATION MODE SETTINGS“: se la funzione è disattivata non viene creata nessuna connessione VPN ed il nodo sarà gestibile tramite il  suo normale indirizzo di rete locale, se la VPN è attivata esso  potrà essere gestito ancora localmente tramite i suoi indirizzi di rete locale, o remotamente sfruttando l’indirizzo fornito al punto 4 sopra indicato.

Una nota importante riguarda la modalità di connesisone del nodo alla rete IP: sfruttando i classici schedini cinesi ovviamente sarà possibile usare esclusivamente la modalità WiFi; utilizzando l’HW Sarimesh ( in particolare il modello Maxi previsto per l’implementazione di nodi iGate avanzati) sarà possibile utilizzare sia la modalità WiFi che la modalità Ethernet 10/100: entrambe le modalità ( alternative) supportano pienamente la funzione VPN .

Una nota particolare va fatta a proposito di come collegarsi da remoto ad un proprio iGate installato per es. presso il proprio QTH o in una postazione remota….esistono svariate possibilità che sostanzialmente differiscono in base alla natura del nodo che intende collegarsi e al modo in cui tale nodo è connesso ad internet; in questa prima descrizione non intendiamo entrare nelle varie possibilità ma ci limitiamo ad illustrare una singola modalità scelta in quanto consente di svolgere una serie di funzioni complesse pur essendo possibile usarla per la semplice connesisone ad un singolo nodo remoto.

La modalità di collegamento suggerita in una fase di test consiste nella utilizzazione di un server Wireguard in cloud o fisicamente predisposto per es. presso una postazione internet dotata di un indirizzo di rete pubblico statico ( per es. il proprio router ADSL di casa dotato di funzionalità VPN Wireguard).

In pratica verranno creati almeno due link VPN come di seguito:

1. un link VPN per il nodo per es. iGate da controllare e che collegherà il nodo iGate remoto al server VPN in cloud
2. uno o più links VPN tra il server VPN in cloud ed i singoli terminali da cui si intende controllare l’iGate remoto

 

Ogni possibile terminale, oltre all’iGate andrà configurato appropriatamente dopo aver generato delle coppie di chiavi privata/pubblica diversa per ogni terminale, utilizzando degli indirizzi locali scelti in maniera che abbiano la stessa network IP ( /24 come netmask), ma valori diversi ed unici per ogni terminale.

Lo scenario di utilizzo sarà quindi caratterizzato da un tunnel che collega il nostro iGate al server in cloud ed un secondo tunnel tra lo stesso server e il terminale remoto da cui si intende effettuare la gestione.

E’ evidente che questo modo di lavoro consente immediatamente di estendere la gestione ad una molteplicità di iGates attivando per ogni iGate che si intende controllare un tunnel ad hoc tra l’iGate e il server ed usando indirizzi locali diversi ma sempre nella stessa network. Per collegarsi ad uno degli n iGates attivi sarà sufficiente aprire un collegamento GUI verso l’IP locale assegnato all’iGate che interessa controllare.

Allo scopo di agevolare la generazione delle chiavi necessarie per l’utilizzo del sistema, nella schermata di configurazione è presente un link che permette di accedere ad una pagina web che fornisce un tool di generazione delle chiavi necessarie.

In un futuro articolo descriveremo in dettaglio la procedura necessaria.

Il server VPN a cui appoggiarsi può essere un qualasiasi server Wireguard… per agevolare chi volesse cimentarsi ho reso disponibile un server ad hoc a cui ci si potrà appoggiare per effettuare dei test; gli interessati mi possono contattare tramite e-mail allo scopo di attivare delle proprie connessione wireguard di prova.

Come sopra precisato è opportuno in caso di utilizzo della funzione di VPN di abilitare la funzione di accesso tramite password alla gestione: allo scopo è presente nella pagina “GENERAL CONFIGURATION”  una nuova sezione che consente di settare una propria coppia di userid e password da tenere ovviamente segrete per evitare accessi indesiderati ai propri dispositivi.

La funzione di sicurezza di accesso alla gestione può essere abilitata o disabilitata da un opportuno flag presente nella pagina GUI ” OPERATION MODE SETTING“.

 

Le figure sopra indicano un esempio di utilizzo della funzione su un dispositivo android: è necessario installare dal “play store” una app ad hoc quale ad es. quella ufficiale “WireGuard” e impostare i parametri per il tunnel tra dispositivo android e server Wireguard in cloud. Per collegarsi ad un certo iGate sul quale preventivamente sia stata configurata ed attivata la funzione VPN basterà lanciare la connessione VPN sullo smartphone e puntare il browser all’indirizzo locale del iGate remoto: apparirà la schermata di ingresso dell’iGate remoto con il popup di richiesta delle credenziali … fornendo tali credenziali avverrà l’autenticazione per l’accesso alla GUI e si potrà operare in maniera completa sul iGate remoto, sia per la normale gestione che eventualmente per l’aggiornamento SW del nodo remoto.

 

Nuove funzionalità nel meccanismo di “MagicTag”

Il meccanismo di “MagicTag” introdotto con la rel. 5.x del SW Sarimesh è un metodo per consentire di implementare una serie di funzioni di “interattività” tra elementi di rete LoRa; in particolare questo meccanismo consiste nell’introdurre nei pacchetti APRS emessi da un generico nodo un piccolo “tag” ovvero una etichetta che consente di veicolare delle richieste agli elementi di rete LoRa che si troveranno a processare questo pacchetto inducendoli eventualmente ad effettuare delle opportune funzioni .

Il “tag” immesso da un generico nodo ed attaccato ad un certo pacchetto APRS viene gestito in maniera esclusiva dal nodo sorgente e non viene modificato in alcun modo lungo tutto il percorso che tale pacchetto effettua in rete…  quando un nodo intermedio che sia in grado di gestire il meccanismo di MagicTag, si trova a ricevere un pacchetto che sia taggato con l’etichetta “MagicTag”,  oltre ad effettuare le normali funzioni di routing sul pacchetto secondo le regole del protocollo APRS, provvede ad analizzare il valore del tag e a seconda di tale valore effettua eventualmente delle azioni conseguenti.

Le azioni implementate possono essere svariate e attualmente sono implementate solo un limitato numero di azioni finalizzate a consentire l’implementazione di altre funzioni complesse come per es. la funzione di “Agile RTX” descritta al paragrafo successivo di questo post.

Attualmente le azioni implementate sono finalizzate a consentire ad un nodo attraversato di generare dei pacchetti APRS di stato diretti al nodo sorgente del pacchetto e contenenti informazioni di vario genere; in particolare attualmente sono implementate le seguenti funzioni a cui si associa la generazione di un particolare “pezzetto” del pacchetto di stato:

1. RequestSignalsReport: viene richiesto al nodo che riceve il pacchetto LoRa di inviare indietro un pacchetto contenente le condizioni del segnale ricevuto in termini di RSSI,SNR,drift di frequenza, radio utilizzata per la ricezione e distanza di trasmissione relativa al pacchetto ricevuto a livello radio LoRa; ad esempio (I8XYZ-7 -56 13 550A 6 )
2. RequestWorkingConditions: viene richiesto al nodo che riceve il pacchetto LoRa di inviare indietro un pacchetto di stato contenente le condizioni di lavoro complete del nodo attraversato in termini di valori di Bandwidth,  SpredingFactor, CodingRate, PreambleLength, RF power, TCXO eventualmente usato per stabilizzare la frequenza del nodo; ad es.  (I8XYZ-10 B=125.00 S=7 C=5 P=10 W=22 X=Y)
3. RequestNodeStatus: viene richiesto al nodo che riceve il pacchetto LoRa di inviare indietro un pacchetto contenente lo stato operativo e alcuni dettagli funzionali del nodo; in particolare le informazioni contenute sono attualmente le seguenti:   Temperatura della CPU, EquivalentNoiseLevel del nodo, Radio LoRa in uso e loro numero e tipo: ad es.  (I8XYZ-10 T=34.62 N=-91.65 A=E22_400M30S B=E22_400M30S)

E’ possibile settare sul nodo sorgente su base singolo pacchetto emesso quali di queste funzioni richiedere , eventualmente richiedendo anche più componenti simultaneamente: lo scopo è quello di consentire ad un nodo LoRa che emette un pacchetto di richiedere ai nodi che lo ascoltano di mandare indietro un insieme di informazioni tale da consentire al nodo emittente di operare in maniera appropriata per realizzare funzioni aggiuntive come ad es. impostare i propri parametri di trasmissione o effettuare delle operazioni di tuning sulla propria frequenza di trasmissione. etc. etc.

Per supportare queste funzionalità è stata modificata la pagina di “APRS FEATURES”  inserendo delle nuove voci allo scopo; la figura a fianco mostra un esempio di impostazione di questa pagina per es. per un dispositivo che opera come tracker.

 

 

Tutti i pacchetti di stato vengono generati esclusivamente sul lato LoRa del iGate che li invia e sono generati con un path APRS che punta al solo nodo LoRa che ha richiesto l’invio, senza alcun attributo di tipo WIDEx-y;  tutti i pacchetti di stato verranno trasmessi sempre usando il modo LoRa HighSpeed ovvero con SF=7 di default e quindi non genereranno alcun tipo di impatto sul traffico LoRa tradizionale con SF=12.

Allo scopo di consentire l’invio manuale di una richiesta di Stato da parte di un dispositivoi ( per es. che opera come tracker…) è stata anche inserita una nuova voce nella schermata di “SPOT DISPLAY” del nodo in modo da poter esplorare manualmente la situazione di rete al momento in una certa zona.

L’utilizzo di questa funzionalità in realtà è principlamnete pensata per essere utilizzata dal SW del nodo emittente in maniera mirata allo scopo per es. di passare dalla modilità di trasmissione standard con SF=12, alla nuova modalità HighSpeed con SF=7 qualora si scopra in zona la presenza di nodi iGate in grado di ricevere il modo LoRa con SF=7. ( vedere la feature di “Agile RTX” al paragrafo successivo).

 

Introduzione della funzionalità di “Agile RTX”

Come ritengo sia oramai noto, uno degli obiettivi che la nostra sperimentazione LoRa si prefigge è quello di implementare un percorso di migrazione il più possibile “trasparente” dalle attuali modalità di trasmisisone LoRa standard de facto con SF=12, ad una nuova modalità di trasmissione con per es. SF=7 in grado di fornire una velocità di comunicazione decisamente superiore ai famosi scarsi 300 bit/sec.

La funzione “Agile RTX” rappresenta un primo tentativo di implementazione di una modalità operativa che consente automaticamente ad un tracker di passare dalla classica modalità di trasmissione con SF=12 alla nuova con SF=7 qualora si renda conto che la zona è servita da un iGate in grado di operare con tale modalità, e che le caratteristiche del link in termini qualitativi siano abbastanza buoni da consentire una comunicazione stabile.

In pratica si sfrutta il canale di ritorno dagli iGates in grado di usarlo , per scoprire se in zona siano presenti iGates in grado di svolgere appropriatamente la comunicazione con SF=7: se il responso è positivo il tracker passa ad usare la nuova modalità dopo un certo numero di tentativi di verifica della stabilità della connessione.

Durante l’uso della nuova modalità il tracker continuerà a monitorare la qualità della comunicazione in maniera appropriata e qualora si accorga che la connessione non sia più di qualità accettabile o sia impossibile, passa nuovamente ad usare la modalità con SF=12 in modo  da sfruttare eventualmente iGate legacy presenti in zona ovvero continuare ad usare un iGate a doppia radio ma usando il modo LoRa con SF=12 che offre una maggiore sensibilità.

Ovviamente questa modalità operativa richiede per poter essere utilizzata che in una certa zona siano presenti iGates in grado di usare la nuova modalità con SF=7: ciò è possibile certamente utilizzando degli iGates a doppia radio LoRa come il modello Maxi Sarimesh, o anche installando degli iGates legacy a singola radio  impostati per funzionare con la nuova modalità con SF=7 in ricezione.

Le figure a fianco mostrano i risultati di alcuni test in campo che evidenziano la dinamica ora descritta…

La prima figura si riferisce ad una prova effettuata su un link di circa 80 Km di lunghezza e relativa ad un percorso di prova su una zona di montagna…  i punti in colore arancio sono spots che utilizzano la modalità SF=12 mentre i punti in verde si riferiscono a spots ottenuti con SF=7; come si può notare il passaggio dall’una all’altra modalità avviene automaticamente anche a distanza di pochi metri… Il collegamento è stato ottenuto usando un iGate a doppia radio situato alla distanza di circa 80 Km ad una quota di circa 200 m slm.

 

 

la seconda figura si riferisce ad una situazione di test in cui si è in presenza di due iGates a doppia radio posizionati in due punti diversi del territorio a circa 3 Km di distanza; il percorso è stato scelto in una zona caratterizzata dalla presenza di colline di circa 500 m di altezza a cavallo della penisola sorrentina ed è un percorso di prova utilizzato in genere per evidenziare la presenza di zone di “ombra” note.

Anche in questo caso i punti in arancio e verde evidenziano spots con SF=12 e SF=7 rispettivamente, mentre gli spots in rosso rappresentano punti da cui NON è stato possibile il collegamento diretto verso l’iGate di prova IZ8QJS-10, ma che sono stati comunque ricevuti dal nodo tramite ripetizione sul secondo nodo iGate presente in zona; entrambi gli iGates sono dispositivi a doppia radio.

Da queste prime prove emerge che il sistema già in questa prima implementazione definita “Modo Passivo” fornisce dei buoni risultati; il prosieguo della sperimentazione prevede di approfondire il funzionamento di questa modalità generando delle opportune “metriche” atte a misurare in maniera quantitativa l’effetto di “agile” ovvero il guadagno che l’uso di questa modalità consente di ottenere non tanto e non solo in termini di maggiore velocità della comunicazione, ma anche in termini di riduzione della “congestione” sul canale tradizionale a SF=12.

Infatti in una zona in cui siano presenti tanti dispositivi che usano il sistema, a causa della bassissima velocità di trasmissione e della assenza quasi certa della utilizzazione di qualsiasi metodica di CAD ( Channel Activity Detection) insita nell’uso di chips LoRa di prima generazione, esiste una concreta probabilità di collisione a livello radio che si traduce in una situazione di congestione che fa ulteriormente crollare la velocità reale della comunicazione…. avendo la possibilità di “deviare” i tracker ad usare la modalità veloce ad SF=7 equivale a ridurre drasticamente la probabilità di collisione sul modo ad SF=12 e quindi a preservare la sua utilizzabilità per il traffico per così dire “DX”.

Un parametro che si pensa di utilizzare come metrica è il tempo on-air  misurato dai vari dispositivi e associato rispettivamente ai periodi di occupazione del canale radio distinto tra modalità SF=12 ed SF=7, inclusivo o meno dei tempi di ricerca del canale libero utilizzando la funzione di CAD presente nei chipset LoRa di seconda generazione.

Per abilitare questa modalità operativa è stata introdotta una nuova chiave nella schermata delle “APRS FEATURES”.

 

Ri-orientamento della interfaccia grafica locale (display)

L’introduzione delle nuove features finora esposte rende abbastanza evidente che si sia resa necessaria una revisione del contenuto mostrato dal display locale dei dispositivi…

Diversamente da altri SW che usano il display locale come punto principale di interazione  con i dispositivi in particolare nel caso di utilizzo come tracker, fin dall’inizio il SW Sarimesh ha privilegiato come punto principale di interazione con il sistema APRS l’interfaccia grafica tramite WiFi utilizzata o da un PC nell’uso fisso o da uno smarthphone nell’uso in mobile o portatile.

Ne è derivato che il display locale ed il tastino funzione ad esso associato funzionalmente, sono sempre stati concepiti per un uso “emergenziale” o per un uso di verifica veloce della situazione di rete APRS corrente…  quindi più che displayare il “trasmesso”  lo scopo era displayare il “ricevuto”…  il che ovviamente ha senso solo se si utilizza un canale di ritorno o si sia in una realtà di iGates “NON MUTI”….

Questo approccio continua ad essere quello privilegiato, solo che con le nuove funzioni diventa agevole e conveniente modificare i vecchi contenuti per allinearli alle nuove funzioni… inoltre diventa possibile rendere ancora più pratico individuare la situazione corrente di un dispositivo tracker in particolare, mostrando in una schermata di base un piccolo insieme di dati sintetici, e implementando una modalità di display ad eventi per i principali “eventi radio” che il tracker in particolare si trova ad evidenziare.

La figura seguente illustra un esempio di schermata base ed alcune schermate di evento…

La schermata base include i principali dati utili a giudicare della corretta operatività del tracker , ed include anche alcuni dati di possibile interesse quale ad es. la velocità e l’altezza del tracker, lo stato di fixing del GPS, il numero di satelliti in vista ed i valori dell parametro HDOP che fornisce una indicazione della bontà del fix, l’orario locale, il numero di pacchetti trasmessi ed il tempo trascorso dall’ultimo pacchetto ricevuto.

Poi si ha come ultima riga del display in colore giallo/arancio lo stato dell’ultimo pacchetto di stato ricevuto dal tracker che contiene l’identificazione del nodo su cui il pacchetto emesso dal tracker è transitato, i valori RSSI, SNR e drift di frequenza con cui quel iGate ha ricevuto il pacchetto generato dal tracker ed i nfine la distanza corrispondente alla tratta radio tra tracker e iGate di accesso.

In caso di mancanza di pacchetti ricevuti per un tempo elevato viene mostrata una schermata di evento che segnale la situazione di “Attesa spots”  in modo da dare dei segni di vita anche in caso di assenza di spots ricevuti;

In corrispondenza della ricezione di un pacchetto APRS di tipo diverso da pacchetto di stato, viene generata una schermata di evento che indica l’identità del tracker sorgente del pacchetto e del eventuale via di ricezione, ovvero se direttamente dal dispositivo originatore del pacchetto o tramite ripetizione su un iGate intermedio.

Le schermate di evento vengono presentate per un tempo di circa 5 secondi; in assenza di nuovi eventi la schermata base viene aggiornata ogni minuto.

 

 

Strettamente correlato con il display fisico presente sul dispositivo abbiamo poi un “display virtuale” accessibile tramite l’interfaccia WEB e che si può vedere ad es. nella figura seguente… il display virtuale ripropone in una prima parte della schermata l’esatto contenuto del display fisico, mentre in una seconda parte propone una serie di dati aggiuntivi atti ad inquadrare la situazione di funzionamento del dispositivo.

 

 

Il display virtuale è pensato per essere fruibile per es. in macchina utilizzando il proprio smartphone come display posizionato in posizione opportuna tipo a fianco del navigatore o addirittura sullo schermo del navigatore se questo è possibile.

Volendo è possibile poi accedere a tutte le schermate di dettaglio presenti sulla GUI per ulteriori approfondimenti.

 

Disponibilità del SW 

A breve verrà resa disponibile a seguire su questa pagina la lista delle immagini binarie scaricabili della nuova versione del SW Sarimesh vr. 6.0.0 per alcuni dei dispositivi HW supportati; attualmente questa nuova versione del SW potrà girare tranquillamente su tutte le varianti di HW Sarimesh attualmente disponibili , sulle piattaforme HW TTGO Vr. 1.1 e 1.2 e sulla piattaforma Heltec Tracker vr. 1.1

Le immagini fornite sono caricabili sui vari dispositivi come descritto negli articoli precedenti reperibili su questo sito.

Per chi fosse interessato alla versione SW sorgente sviluppata in ambiente Platform IO è sufficiente che mi contatti per e-mail.