Per chi segue (????) queste mie chiacchierate sicuramente sarà passato non inosservata una parentesi silente…. 🙂   è stato certamente per il troppo caldo, per qualche giorno al mare… ma soprattutto perchè sperimentare significa osservare e reagire con eventuali adattamenti a quello che si va ad osservare.

In questi ultimi mesi è stato possibile con l’aiuto di vari volenterosi cominciare a fare delle prove relative alle funzioni di cui abbiamo parlato nel recente passato e questo ha consentito di raccogliere delle interessanti considerazioni e anche qualche significativo risultato.

Mi riferisco in particolare  a due o tre  funzionalità che sono sostanzialmente legate a doppio filo all’obiettivo di rendere LoRa una soluzione almeno equivalente al buon vecchio APRS:

• la modalità di lavoro “Dual Mode”, ovvero ricezione e trasmissione usando Modi LoRa differenti ed ortogonali sulla stessa frequenza di lavoro
• la funzione “MagicTag” per implementare una forma di interattività tra trackers ed iGates
• l’utilizzo di dispositivi a “Doppia Radio LoRa” a livello di “backbone”

 

Giusto per ricapitolare per chi non ricorda le puntate precedenti, il problema principale di LoRa APRS allo stato attuale è l’utilizzo di una modalità di trasmissione con SF=12 ovvero con Spreading Factor molto alto: questa scelta, fatta oramai svariati anni fa, serviva a cercare di avere la massima “sensibilità” del sistema di trasmissione LoRa, ma a scapito del bitrate utilizzabile per la trasmissione: meno di 300 bit/sec…

Questa situazione in pratica impedisce una serie di modalità operative e rende LoRa solo una brutta copia del classico vecchio APRS… ma sta di fatto che questa è la situazione attuale, e sempre più numerosi iGates stanno spuntando con l’obiettivo di migliorare la copertura del territorio, senza pensare minimamente a come “ottimizzare” il tutto…

Ovviamente tutto questo non è strano: indubbiamente aggiungere un nuovo iGate è il modo più veloce per sentirsi “attivi” ed è un passo avanti … il nostro obiettivo è quello di cercare di dare un contributo alla diffusione di LoRa  contribuendo non con la quantità  ( ovvero vedendo crescere  il numero di attivazioni ) … ma con la qualità,  alla diffusione di LoRa, portando avanti , anche se forse un poco controcorrente, un filone di sperimentazione che mira a migliorare le performances del sistema.

E  oramai il punto chiave su cui incidere è estremamente chiaro: trovare una alternativa al famoso SF=12:  capite bene che è un obiettivo titanico di fronte all’evidenza che migliaia di iGates sono oramai installati ed usano questa impostazione…

La strada a cui abbiamo pensato nel nostro filone di sperimentazione è quello di proporre una forma di “migrazione  indolore”  verso parametri diversi, sfruttando la flessibilità del protocollo LoRa e cercando di incidere non a livello dei trackers, ma principalmente a livello degli iGates, limitando al minimo e solo al SW, gli impatti a livello di trackes.

La chiave per questa strategia è l’introduzione della modalità di lavoro che abbiamo chiamato “Dual Mode”: ovvero anzicchè implementare una rete di iGates “muti”, che vedono esclusivamente internet direttamente e quasi mai  interagiscono tra loro direttamente,  introdurre la possibilità per gli iGates di “ascoltare” sul classico Modo LoRa con SF=12 in modo da mantenere la compatibilità con l’universo di trackers esistenti, e di “parlare” tra loro utilizzando un Modo di trasmissione LoRa ortogonale con SF=7 ed isofrequenziale con il modo a SF=12, per esempio,  che consente di avere un bit rate fino a oltre 5000 bit/sec contro i classici 300 bit/sec.

Il secondo punto strettamente legato al primo ora indicato è quello di come fare in modo che gli iGates che ascoltano su un Modo LoRa e parlano su un Modo LoRa diverso, possano comunicare….  ovviamente se ascoltano solo su SF=12 come fare ad ascoltare gli altri iGates  che trasmettono su SF=7 ?     Senza ripetere cose già ampiamente illustrate , la soluzione è creare degli iGates che siano equipaggiati con due radio LoRa diverse in modo che una radio riceva e trasmetta su SF=7 e l’altra riceva solo su SF=12:  ovviamente un tale circuito non esiste attualmente su Aliexpress, motivo per cui ci siamo attivati per creare dei semplici PCB di costo peraltro molto limitato che possano fare allo scopo: parlo dela PCB Sarimesh Maxi Dual Radio… costo sui circa 30-40€ comprando i componenti sui soliti portali cinesi.

A questo punto abbiamo già ottenuto un primo risultato:  non è più strettamente necessario che un nuovo iGate debba avere la connettività internet per operare come iGate, e inoltre si riesce ad operare in maniera “OFF GRID”  come il buon vecchio APRS tradizionale su aree geografiche anche semmai abbastanza ampie….

Ovviamente una volta upgradata la parte “rete” sorge l’enorme problema delle migliaia di tracker che già esistono e sanno lavorare solo come oggi lavorano: su questo tema già in passato ho avuto modo di esprimere qualche timido punto di vista sul come operare per “aggiornare” tali dispositivi che oggi usano svariati tipi di SW…  la base per le mie valutazioni passate che sottolineavano un “agevole” lavoro di aggiornamento di tali SW era basata sostanzialmente sulle mie pregresse conoscenze dei SW in uso qualche anno fa in quanto all’inizio della sperimentazione Sarimesh LoRa mi ero premurato di studiare quei SW… non  avevo però una visione aggiornata ad oggi… quest’estate mentre mi crogiolavo sotto l’ombrellone in spiaggia mi è venuta in mente la famosa storia di Maometto e della montagna…  “se Maometto non va alla montagna, la montagna va a Maometto….”

E cosi’ mi sono messo a studiare uno dei SW oggi più diffuso, quello di Riccardo, allo scopo di implementarci sopra le modifiche che consentivano di usare i dispositivi che montano quel SW in maniera coordinata con il SW Sarimesh, in particolare implementando le funzioni di “Dual Mode” e di supporto della strategia “Magic Tag” ….

Tornato dalle vacanze mi sono innanzitutto applicato a portare il SW di Riccardo sui miei PCB che conoscete, e successivamente ad implementare le funzioni di cui sopra… nel giro di scarsa una settimana di lavoro a tempo parziale ho messo insieme una versione patchata dei SW iGate e Tracker di Riccardo che girano oltre che sulle schede commerciali che conoscete anche sul mio HW Sarimesh…  era la “proof of concept” che mi mancava per sostanziare il discorso degli impatti richiesti sui SW tracker ed iGate esistenti per supportare le funzioni di cui sopra.

Per inciso attualmente ci sono 5 o 6 OM che hanno in operation la mia versione patchata del SW di Riccardo e sembra funzionare tutto tranquillamnete… se questa versione interessa a qualcuno basta che mi scrivete e ve la passo ; Riccardo è al corrente delle mie prove ( ci siamo scambiati messaggi privati) e gli mandai ad agosto uno snapshot della mia versione.

Ovviamente implementando quindi delle piccole modifiche sui SW tracker ed iGate esistenti è possibile già avere qualche interessante risultato, tipo per esempio quello di poter integrare degli iGate tradizionali a singola radio con degli iGate a doppia radio, o anche di poter fare in modo da attivare le funzioni di digipeating anche sugli iGate tradizionali in modo che i tracker in zona di copertura radio possano avere  visione delle stazioni presenti in zona senza dover guardare necessariamente il sito aprs.fi…

In realtà diventa anche possibile usare da parte dei tracker direttamente il modo veloce a SF=7 per connettersi verso la rete LoRa in modo da avere i vantaggi di una velocità di trasmissione molto più elevata dei classici 300 bit/sec e quindi diventa possibile usare concretamente per es. il messaging  o le funzioni di telemetria senza congestionare il canale…. (ovviamente questo se sono presenti iGates a doppia radio in zona).

Resta il problema di come riuscire concretamente a far sì che un tracker possa automaticamente scoprire che in una certa zona è possibile contattare la rete con SF=7 anzicchè dover usare il classico SF=12….

Ed è proprio quello che cerca di fare il famoso meccanismo di “Magic Tag” di cui da qualche tempo sto parlando….

Il problema grosso per un tracker è rendersi conto di cosa è disponibile in una certa zona come risorse di rete LoRa:   della serie che iGate sono in grado di collegare ?  che modi di trasmissione posso usare ? fino a quando riesco ad essere agganciato ad  un certo iGate e quindi ad usarne le caratteristiche ? quale è il livello di qualità del mio collegamento LoRa verso la rete ?

A tutte queste domande attualmente non esiste come noto nessuna risposta a parte le chiacchiere ed i sentito dire…

Il meccanismo Magic Tag è pensato per “chiedere” ai possibili iGates presenti in una certa zona ed in grado di comprendere il meccanismo di “Magic Tag” di recitare cosa sanno fare, e come sono attualmente in grado di ricevere i miei segnali… grazie a questa funzionalità un tracker si può fare una idea di “cosa offre il mercato in zona” e operare di conseguenza.

A questo punto spero di essere riuscito a far capire cosa può accadere dal punto di vista operativo ad un tracker…  se per caso scopre che ci sta un igate in grado di ricevere il Modo SF=7, e che arriva con un bel segnale come qualità, allora il tracker può tranquillamente passare ad operare in modo SF=7 veloce accedendo così a tutti i nuovi servizi possibili con la maggior velocità di connessione… salvo ovviamente a ritornare sul vecchio SF=12 qualora nel seguito scopra che le cose sono cambiate…

Scusatemi se per illustrare queste idee uso un linguaggio non aulico e non da scienziato che vuole impressionare… il mio obiettivo è farmi capire anche da chi non mastica particolarmente scienza ma vede le cose pratiche.

Nel corso dell’ultimo mese mi sono quindi applicato a riworkare il meccanismo del Magic Tag per cominciare ad implementare un primo minimo livello di interattività tra tracker e iGates, che consentisse di operare delle prime prove dello scenario che vi ho descritto sopra… in particolare ho implementato le funzioni per interrogare da parte di un tracker o anche di un altro iGate, gli iGates per farsi riportare tramite dei messaggi di stato le condizioni di lavoro, di equipaggiamento e di ricezione da parte degli igates… queste funzioni sono ad oggi usabili “manualmente” tramite l’interfaccia GUI dei dispositivi che montano il SW Sarimesh vr. 5.3.3 che renderò disponibile a brevissimo con dei puntatori in coda a questo post.

In particolare quello che nella rel. SW in questione è disponibile è la possibilità di  abilitare/disabilitare diverse “opzioni” di funzionamento del meccanismo “Magic Tag” a livello di iGate e/o di tracker in modo da valutare l’effetto delle varie opzioni…

Innanzitutto è possibile abilitare o disabilitare del tutto il supporto e l’utilizzo da parte del diapositivo del meccanismo di “Magic Tag”:  quando il meccanismo è disabilitato il dispositivo opererà come un classico tracker o iGate e non produrra’ alcun messaggio di stato aggiuntivo, ne’ implementerà ancuna modifica sul traffico APRS passante nel caso di iGate .

Abilitando il meccanismo di MagicTag saranno possibili diverse modalità di funzionamento: tutte le modalità di funzionamento utilizzabili NON introdurranno mai nessuna modifica al traffico passante, ma consentiranno di richiedere ai peers che ascoltano il traffico di operare eventualmente generando dei messaggi di stato diretti al peer che origina il traffico ( quindi con un path contenente esclusivamente il valore di SSID dell’originante il traffico senza alcun  WIDE aggiunto): questi messaggi di stato saranno ovviamente emessi dai soli iGate attivi e che hanno il magic tag abilitato ed utilizzeranno ovviamente il modo SF=7  veloce senza quindi introdurre alcun carico sul canale ad SF=12 .

Riguardo alla natura dei messaggi di stato che un iGate potrà emettere , ad oggi ho implementato tre gruppi di valori:

• dati di configurazione di lavoro contenente i valori di freq, BW,SF,CR,preamblelength
• dati di stato contenenti valori relativi all’equipaggiamento quali as ed numero e tipo di radio LoRa, presenza di TCXO, etc e valori di stato quali ad es. temperatuta di lavoro, tensione di lavoro, e , importante, valore di ENL ( Estimated Noise Level) del sito.
• rapporti di ricezione ovvero valori di RSSI, SNR, drift di frequenza, e spot reference ( ovvero SSDI, tempo di ricezione e coordinate ricevute) degli spots ricevuti

 

Un dispositivo remoto (per es un tracker) potrà quindi scoprire su base iGate che emette tali dati le caratteristiche dell’iGate e la qualità della ricezione che tale iGate ha per i segnali emessi dal dispositivo.

Il passo successivo, non ancora implementato , sarà quello di cominciare ad automatizzare un meccanismo di “Mode Switching” come sopra descritto.

Un ulteriore piccolo aggiornamento sul fronte dei dispositivi HW Sarimesh disponibili: ho finalmente messo insieme un piccolo documento che descrive i due PCB principali disponibili che sono il Maxi ed il Mini; il documento contiene la documentazione completa dei PCB ( compresi schemi elettrici e files gerber) scaricabile da internet, nonchè una serie di note di montaggio e testing dei PCB.

E’ disponibile una piccola campionatura dei suddetti PCB sotto forma di schede parzialmente preassemblate in fabbrica per i componenti SMD; chi fosse interessato ad avere dei campioni è sufficiente che mi contatti ai soliti recapiti.

Il documento è disponibile al seguente URL:  LoRa_Sarimesh_PCB_assemblaggio.pdf