Nell’ultimo articolo “lora aprs: alla ricerca di uno standard per la compatibilita..:” abbiamo analizzato quali diversità esistono oggi tra le varie implementazioni di “APRS over LoRa” disponibili.

Abbiamo anche illustrato una possibile soluzione al problema delle incompatibiltà SW e al modo di superarle in maniera abbastanza indolore.

Quello che resta è ovviamente la diversità delle piattaforme HW su cui tali SW possono trovarsi a dover operare.

 

Supporto di piattaforme HW diverse..

Analizzando le principali implementazioni oggi disponibili sul WEB e quasi sempre orientate a girare sui vari “schedini conesi” abbiamo notato che la tendenza più consolidata è quella di utilizzare una metodica di “autodiscovery” per superare le diversità HW dei vari dispositivi:  questa impostazione è sicuramente interessante,  ma in linea di massima presenta una serie di problemi legati alla reale e concreta possibilità di discernere l’esatto HW su cui si sta tentando di usare il nostro SW.

Inoltre una simile impostazione richiede un costante aggiornamento del SW per rincorrere le nuove varianti di HW che sono in circolazioe.

Un ultimo discorso che abbiamo evidenziato è la reale efficienza di questa metodica e l’impossibilità di avere un approccio “hand’s on”  sul proprio ambiente… della serie essere in grado di evidenziare e capire le reali sottili differenze presenti nel proprio HW in relazione al SW che si vuole utilizzare.

Nel tentativo quindi di adattare il nostro SW a poter girare agevolmente su piattaforme HW diverse dalla nostra e in particolare sui famosi “schedini cinesi”, abbiamo deciso di usare un approccio diverso e a nostro parere più “da radioamatore”…  il radioamatore è notoriamente un soggetto poco SW oriented e molto più HW oriented… a cui piace capire le cose e che diffida naturalmente dai processi “automatici”…. orbene quale migliore modo di venire incontro alle sue curiosità e desiderio di approfondimento esiste che non sia quello di “leggere” il proprio HW e customizzare il SW per adattarsi ad esso…

Ci siamo allora interrogati su quali siano le principali “varianti HW” presenti sugli schedini che si trovano in giro e come era abbastanza prevedibile si è scoperto che le differenze sono sempre abbastanza minimali e riconducibili a semplici problemi di “collegamenti” tra pochi pins del processore e dei circuiti che ad esso si collegano.

La soluzione che abbiamo quindi deciso di implementare non fa altro che rendere possibile, tramite una opportuna pagina della interfaccia GUI,  di adattare il mappaggio dei pins del processore verso i dispositivi periferici presenti sul circuto reale su cui si vuol far girare il nostro SW.

A conti fatti si tratta di specificare quali pins sono utilizzati per i due bus presenti sul processore , ovvero I2C e SPI, e un limitato altro numero di parametri… tutte informazioni facilmente deducibili dalla seppur limitata documentazione reperibile su internet.

Nella nostra ultima versione SW 1.0.9.2 abbiamo quindi implementato il supporto di questa metodica in modo da generare delle immagini SW binarie adattabili agevolmente alle diverse varianti reperibili sul mercato degli schedini cinesi.

Va osservato che allo stato non è possibile avere una unica immagine SW per tutti gli schedini esistenti per una serie di motivi  legati in particolare al diverso SW di base richiesto dalle diverse famiglie, e  in relazione al diverso tipo di chipset LoRa utilizzati;  nel nostro caso abbiamo quindi generato delle immagini SW diverse per i due principali tipi di HW cinese ovvero per le piattaforme TTGO-T-Beam e Heltec WiFi LoRa 32, oltre alla piattaforma SARIMESH .

Le immagini SW sono reperibili sulla seguente pagina:  http://www.sarimesh.net/sperimentazione-lora-aprs-documentazione-e-sw-disponibile/

E’ anche disponibile sulla stessa pagina una versione aggiornata Vr. 1.6 del manuale di installazione che riporta i dettagli operativi richiesti per il setup del SW sulle diverse piattaforme.

 

La figura seguente riporta il contenuto della pagina della interfaccia WEB che consente di adattare il SW alle diverse piattaforme HW:

 

Come si può notare vengono chiaramente identificati i vari elementi che richiedono eventuale customizzazione:

• Bus I2C
• Bus SPI
• Elementi specifici display OLED
• Elementi specifici chip Lora
• Elementi specifici chip GPS utilizzato

 

Tutte le informazioni richieste sono agevolmente deducibile dalla immagine che in genere viene resa disponibile sul portale internet di acquisto dello schedino , relativamente allo schedino stesso.

In pratica quindi basterà cercare su tale immagine i pins indicati nella schermata popolando nella pagina i valori ottenuti, e salvando quindi la pagina.

Per rendere effettivi inuovi valori immessi si rende necessario fare il reboot del dispositivo.

Va osservato che i valori presentati di default nella schermata sono i più diffusi per la versione SW di piattaforma installata

Per verificare se i valori immessi sono corretti è possibile consultare la pagina del “Inventory configuration” presente sulla pagina principale della GUI,  per verificare se siano stati correttamente identificati i vari componenti presenti sul circuito, in particolare per quanto riguarda il chip GPS.

 

 

 

 

Va osservato in merito alla modalità di conservazione della configurazione che, diversamente dall’HW SARIMESH  che è dotato di una memoria FRAM per mantenere tali dati, gli schedini cinesi richiedono di salvare i  dati relativi in flash e quindi in una minipartizione della stessa; nel caso del SW SARIMESH tale partizione è strutturata come filesystem LittleFS e viene caricata all’atto del caricamento dell’immagine binaria completa di prima installazione.

Tale configurazione può essere quindi customizzata tramite la interfaccia GUI ed i relativi dati vengono salvati nella partizione suddetta su flash.

All’atto di un successivo aggiornamento SW, per evitare di cancellare i dati di configurazione customizzati, si consiglia di effettuare l’aggiornamento SW NON utilizzando l’immagine SW completa, ma tramite la modalità OTA, caricando quindi la sola partizione della flash corrispondente al codice, ed evitando quindi di cancellare/sovrascrivere con dei defaults la partizione LittleFS.

La partizione corrispondente alla parte di “codice” è reperibile nell’immagine binaria completa ed è riconoscibile facilmente essendo il file con estensione .bin di dimesione maggiore tra i vari files presenti nell’archivio ZIP  corrispondente all’immagine completa.

Con l’HW SARIMESH la limitazione di cui sopra non si applica essendo i dati di configurazione salvati in memoria FRAM e non in flash.

Supporto di larghezze di banda inferiori a 62.5 Khz..

Un ulteriore tema che ci siamo prefissati di affrontare parlando di schedini cinesi è stato il discorso della loro utilizzabilità con parametri radio diversi da quelli genericamente utilizzati, ovvero 125 Khz di larghezza di banda.

Infatti uno dei problemi che ci aspettiamo prima o dopo di dover affrontare nel contesto normativo italiano è il fatto che tale larghezza di banda è fuori da ogni altro tradizionale modo di comunicazione di normale utilizzazione.

Il problema che si presenta tentando  di usare gli schedini cinesi con valori di larghezza di banda inferiori a 62.5 Khz è che, a causa del tipo di oscillatore utilizzato in associazione ai chipset di prima generazione montati su tali dispositivi, è molto facile che ricevitore e trasmettitore, pur impostati sulla stessa frequenza nominale, in realtà lavorino troppo spostati di frequenza per consentire una ricezione corretta dei segnali LoRa… per quanto questa metodica sia abbastnza tollerante per possibili offset di frequenza tra TX ed RX.

In alcuni SW , tra cui quello SH123 su cui la nostra implementazione SARIMESH, è basata,  è presente una funzionalità, supportata peraltro solo sui chipset LoRa di prima generazione, che consente di realizzare una sorta di agganciamento di frequenza tra TX e RX:  sfortunatamente questa funzione  ha modo di funzionare correttamente solo in caso di un collegamento tra due soli dispositivi LoRa; infatti in caso di più dispositivi presenti in una certa zona il meccanismo va in crisi in quanto i diversi trasmettitori possono avere valori di frequenza diversa e quindi il generico ricevitore finirà per “inseguire” i vari trasmettitori, finendo per generare una situazione di sostanziale stallo….

La soluzione in genere prevista per aggirare il problema dell’offset di frequenza tra TX e RX è quello di impostare separatamente le due frequenze, misurando per es. con un ricevitore SDR il delta di frequenza tra i RX/TX da far colloquiare…  la metodica è ovviamente complessa in quanto richiede di avere a disposizione un RX SDR da usare allo  scopo, e non risolve il problema della coesistenza in una certa zona di più trasmettitori.

La soluzione che abbiamo deciso di implementare nel nostro SW è una metodica sostanzialmente adattiva gestita manualmente che consiste nel “misurare” i valori di offset che il ricevitore LoRa vede nel suo funzionamento con i vari TX presenti in zona,  generando una metrica che chiamiamo Frequency-Jitter  che rappresenta la media mobile degli ultimi 4 pacchetti ricevuti dal generico dispositivo…. questa metrica per sua natura quindi dovrebbe mediare i vari TX visibili dal ricevitore fornendo una sorta di “soluzione di compromesso” tra i vari TX presenti in zona…

Il valore della metrica indicata viene presentata in tempo reale sulla pagina GUI Dashboard, per cui osservando tale pagina nel tempo si può avere una indicazione della stabilità della metrica in un certo contesto operativo.

Per impostare la frequenza di trasmissione in maniera da quasi azzerare l’offset di frequenza è sufficiente andare nella pagina di setup Lora: viene presentato all’ultima riga della pagina il valore della metrica indicata: è sufficiente inserire nella casella LoRa FreqCorrect il valore presentato, cambiato di segno  e quindi salvare la schermata e riavviare il dispositivo… il dispositivo risalirà  impostato per usare il valore di offset caricato e sarà possibile verificare tramite la voce FreqJitter della schermata Dashboard che ora RX e TX sono praticamente allineati.

Il metodo proposto riteniamo sia sufficientemente agevole da implementare e non richiede l’uso di dispositivi ausiliari.

Una volta impostato l’offset di frequenza come indicato è possibile operare anche con valori di larghezza di banda inferiori a 62.5 Khz anche con sbalzi termici  non eccessivi; è evidente che scendendo con valori di larghezza di banda la situazione diventa sempre più critica; da verifiche effettuate appare che con una larghezza di banda di 31.25Khz si riesce ad operare tranquillamente anche con il dispositivo in macchina posizionato sul cruscotto e quindi esposto al sole, per diverse ore.