Una delle caratteristiche , fin dalla sua concezione, del SW LoRa SARIMESH è quella di essere un  unico paccchetto SW  per tutti gli usi attualmente supportati, contrariamente alla quasi totatlità degli altri SW che in genere hanno pacchetti SW ed immagini da caricare sulle schede diverse per i diversi usi.

Attualmente il pacchetto SW LoRa Sarimesh più recente è la release 7.x ; questo pacchetto è strutturato per poter implementare varie funzionalità, alcune delle quali molto sperimentali, ed altre più tradizionali.

Le modalità di lavoro “tradizionali” che tutti conoscono sono le seguenti:

• comportamento tipo “tracker”
• comportamento tipo iGate/Digipeater
• comportamento tipo TCP_KISS modem

Tutte e tre le modalità di lavoro implementano le funzioni di modulazione/demodulazione dei segnali radio per sfruttare come protocollo di trasporto a livello fisico il protocollo radio LoRa; le prime due in aggiunta implementano anche le classiche funzioni richieste dalla specifica APRS ovvero l’invio e la ricezione di  messaggi  testuali sotto forma di “pacchetti” dotati di un indirizzo conforme appunto alle specifiche APRS.

Le due modalità tracker ed iGate/Digipeater sfruttano un insieme di componenti funzionali molto simili per implementare i due tipi di comportamenti: questo spiega come sia abbastanza agevole implementare entrambe le modalità di lavoro senza aumentare in  maniera particolarmente pesante le dimensioni del pacchetto SW complessivo.

Ovviamente è richiesta una opportuna “programmazione” di un certo dispositivo a seconda del comportamento desiderato;  le operazioni richieste sono abbastanza semplici in quanto si riducono ad abilitare o disabilitare alcune caselle a livello della interfaccia grafica del dispositivo.

Una nota importante che è opportuno fare  riguarda la “modellazione”  funzionale del SW: contrariamente ad altri SW che vedono come un tutt’uno le funzionalità di tracker o iGate, il nostro SW preferisce definire dei blocchi   funzionali che “assemblati” consentono di sintetizzare i comportamenti classici… questo approccio serve a poter effettuare delle “sperimentazioni” agendo individualmente su alcuni di questi blocchi funzionali allo scopo di verificare come eventualmente ottimizzare certi comportamenti … La consequenza di questo approccio è che è possibile sia operare in maniera “standard”, sia operare in maniera personalizzata allo scopo di ottenere particolari comportamenti: tutto sta nei settaggi della interfaccia grafica di un certo dispositivo.

Per un uso completamente “standard” è in genere sufficiente accettare i parametri di default ottenibili tramite una particolare schermata detta di “Quick Setup” : questa pagina , se riempita con pochi semplici dati, consente di “dimenticare completamente” tutta la flessibilità del SW e consente di implementare le classiche modalità operative senza particolari smanettamenti su altre schermate.

Volendo è possibile quindi partire da una configurazione base ottenuta tramite la funzione di “quick setup”, apportando semmai qualche piccola customizzazione qualora si voglia sperimentare qualcosa di particolare.

In particolarte usando la pagina di “LoRa Configuration”  è possibile introdurre delle varianti sul livello fisico del funzionamento ovvero sulla parte propriamente “LoRa” del dispositivo, mentre usando la pagina “APRS Configuration”  ed “APRS Features” è possibile introdurre delle varianti sulla parte di livello più alto del modello funzionale ovvero sulla parte APRS.

In particolare si tratta di agire sulla componente APRS del SW, in modo da abilitare a seconda dei casi la modalità operativa scegliendo  tra iGate e tracker,  e poi abilitando o disabilitando l’interfaccia verso la rete mondiale APRS-IS e/o la funzione di digipeating.

Nel caso specifico del SW LoRa Sarimesh è possibile utilizzare oltre a queste funzioni classiche, anche delle altre funzioni che definiamo “sperimentali”  e che rappresentano delle funzioni attualmente oggetto di sperimentazione avanzata allo scopo di ottimizzare alcuni aspetti dell’utilizzo di LoRa come trasporto fisico in sostituzione del classico modo AFSK usato in genere per implementare le classiche reti APRS.

Queste funzionalità avanzate si consiglia di NON utilizzarle inizialmente senza aver preso sufficiente familiarità con i temi  su cui tali funzioni si basano.

A seguire si descrivono quindi le sequenze operative tipiche richieste per configurare un certo dispositivo su cui sia sta caricata una immagine SW LoRa Sarimesh Vr. 7.x in modo da poter operare come Tracker o come iGate/Digipeater.

Si assume che il dispositivo sia stato “flashato” con una immagine “full” ovvero completa di tutte le componenti SW necessarie e che sia stato effettuato , se già utilizzato in precedenza per fare altre prove,  un “Factory Default” in  modo da riportare il dispositivo ad uno stato “noto” di partenza.

 

1) Impostazione del SW LoRa Sarimesh per operare come “Tracker”

1.1) Collegarsi al dispositivo via interfaccia grafica e accedere alla GUI loggandosi con le credenziali precedentemente settate o con i default userid: admin e password: admin123

1.2) Accedere alla pagina “QUICK SETUP” 

 

1.3) Compilare TUTTI i campi della pagina  “QUICK SETUP”  senza tralasciarne nessuno;

• settare un nome anche di fantasia per il dispositivo
• settare una posizione di default senza la quale il dispositivo NON funzionerà; si consiglia di indicare per es. una posizione home determinabile seguendo il link presente sulla destra della casella relativa alla posizione
• settare una altezza slm in metri per la posizione di default
• settare la APRS-ID che si vuole associare al dispositivo (es. I1XYZ-9 nell’esempio)
• settare il Passcode di accesso ad APRSIS relatvo al APRS-IS SENZA il  “-numero del SSID”  ( importante… ad es. I1XYZ senza il -9 nell’esempio); usare il link alla destra della casella per calcolare tale Passcode di accesso
• Settare il “Modo di operazione” al valore “Tracker Mode“
• le due caselle successive possono essere valorizzate inizialmente ai valori “Lora Node Monitor” ==> Z   e LoRa APRS Logger ==> mtg3.eu
• Premere il tasto “GO!”   per impostare il dispositivo …..

Le figure a seguire illustrano le operazioni indicate:

 

 

1.4) Verificare la correttezza dell’operazione di “Quick Setup”;

Essendo il nostro SW sempre in sviluppo e mai stabile per definizione, suggeriamo, anche per prendere un poco di dimestichezza con la GUI, di effettuare una verifica puntuale della corretta impostazione delle schermate di dettagli funzionali, anche per prendere conoscenza delle possibili personalizzazioni che potranno essere apportate just-in-case per fare della sperimentazione….

• Verificare che la pagina di “Operation and Debug Functions” sia impostata come in figura almeno per le caselle puntate dalle frecce rosse

• Se è necessario modificare qualche casella premurarsi di salvare le modifiche premendo il tasto “SAVE” presente a fondo pagina.
• Verificare il livello fisico LoRa accedendo alla pagina “LoRa Radio Configuration” e verificando che sia impostato come nella figura seguente:

• Il settaggio indicato è quello da usare per la compatibilità con i default di altri SW attualmente in uso. Volendo fare delle personalizzazioni è consigliabile prendere confidenza con gli aspetti di uso dei vari parametri  presenti nella schermata.
• Verificare le impostazioni del Livello APRS accedendo alla pagina “Aprs Configuration”  e verificando che le varie finestrelle siano coerenti con i dati  inseriti nella pagina di quick setup come nella figura a seguire:

• Anche per questa schermata è possibile fare delle personalizzazioni ….
• Verificare a seguire i settaggi della ulteriore pagina “APRS Additional Features”  verificando che siano coerenti con la figura a seguire:

• Il settaggio di questa pagina è forse quello che contiene più dettagli importanti per “distinguere” il comportamento di un dispositivo dal punto di vista delle funzionalità APRS… si consiglia di partire con i settaggi indicati in figura rimandando ad approfondimenti successivi l’utilizzo delle funzioni indicate nella pagina.
• Per tutte le pagine vale la regola di salvare con il tasto “SAVE” presente alla fine di ognipagina per salvare le modifiche fatte eventualmente…
• Tutte le modifiche fatte nel modo indicato sono modifiche “TEMPORANEE”  che scompaiono in caso di reboot del dispositivo; per rendere “PERMANENTI” le modifiche fatte compreso quelle indotte dal “QUICK SETUP” iniziale è necessario effettuare l’operazione di “Commit” come chiaramente ricordato in fondo ad ognuna delle pagine della GUI…
• Per effettuare il “COMMIT” della configurazione accedere alla pagina di ” Operation and Debug Functions”  e andare verso la fine della pagina… mettere una marca sulla voce “Commit Configuration”   e premere il tasto “SAVE” verificando sullo schermo che non vengano riportati degli errori.

• Finito il Commit la configurazione è stata salvata come configurazione attiva al prossimo Boot del dispositivo…. quindi per attivarte la nuova configurazione effettuare il reboot e iniziare a provare il dispositivo…
• Si consiglia innazitutto di verificare sul display del dispositivo i dati presenti in modo da rendersi conto:

1.  dello stato operativo (tracker)
2. dello stato del GPS (satelliti, hdop)  … fino ad avere un FIX 3D…  senza un fix il dispositivo NON trasmetterà nessun beacon!
3. dello stato della data/trempo
4. della possibilità di trasmettere un beacon premendo il tastino funzione per un attimo
5. della possibilità di ricevere un beacon appoggiandosi per es. ad una stazione esterna

• Se non si riesce a trasmettere la prima cosa da verificare è che sia stata impostata una posizione di default e che ci sia un Fix 3D del GPS.

 

2) Impostazione del SW LoRa Sarimesh per operare come “iGate/Digipeater”

Le azioni richieste sono sostanzialmente identiche al caso del settaggio come tracker con delle minime differenze che si illustrano a seguire.

2.1) identica ad 1.1)

2.2) identica ad 1.2)

2.3) identica alla 1.3) eccetto per il campo “Modo di operazione” per il quale:

• Settare il “Modo di operazione” al valore “iGate Mode“

2.4)

Per la parte di verifiche analogamente si noteranno piccolizssme differenze che si vanno ad illustrare a seguire evidenziando esclusivamente le differenze rispetto al caso “Tracker Mode”

• pagina “Operation and Debug Functions”  per il caso iGate/Digipeater

• pagina “APRS Additional Features” per il caso iGate/Digipeater

• Con le impostazioni presenti nella figura precedente il dispositivo opererà sia come iGate che come digipeater; volendo operare esclusivamente come iGate è sufficiente rimuovere la tacca dalla casella Repeater Operation; analogamente volendo operare solo come Digipeater è sufficiente rimuovere la tacca dalla casella APRS-IS  Operation.
• Ricordare di salvare sempre le schermate modificate e di effettuare il commit finale dopo che tutte le modifiche sono state effettuate.

3) Raccomandazioni nell’uso come iGate/Digipeater

Mi preme richiamare la vostra attenzione su un fatto forse banale ma che vale sempre la pena di ricordare: nell’uso come iGate/Digipeater con le modalità di trasmissione LoRa di uso comune e che noi usiamo come default è estremamente importante sincerarsi che nella zona NON siano presenti troppi dispositivi che operano come digipeater in quanto con i parametri LoRa di default ovvero SF=12 e BW=125 KHz si ha a disposizione una banda radio di soli 293 bit/sec il che significa che un classico pacchetto APRS neanche troppo “verboso” occcuperà il canale radio per almeno 4-5 secondi IN ASSENZA di altri repeater… per ogni repeater attivo nell’area di copertura radio l’occupazione di canale aumenta di almeno altrettanti secondi… e se ci sono tanti repeataer un singolo pacchetto può addirittura portare a congestione completa il canale se il suo ritmo di emissione diventa troppo rapido….

Quindi la raccomandazione è di NON usare la funzione digipeater in aree congestionate e di non impostare un tempo di emissione dei propri beacons troppo breve.

4) Raccomandazioni nell’uso come Tracker

Per ragioni simili a quanto descritto a proposito dell’uso come iGate nel paragrafo precedenze si raccomanda di non settare il tempo di invio dei pacchetti con intervalli temporali troppo piccoli.

Una impostazione “saggia” è quella riportata prima come default consigliato: ovvero invio dei beacon con la modalità “ad eventi”, altrimenti chiamato “smart beaconing”… è una modalità ottimale di invio dei beacons per l’uso normale in città/paese ed in autostrada o statale … senza consumare troppa benzina!