Nell’articolo recentemente pubblicato ( loraaprs: eppur si muove )  abbiamo accennato al discorso della compatibilità tra le diverse implementazioni di LoRa su APRS …  è un discorso abbastanza noto a chi si sia interessato di questo argomento e che ha le sue radici  storiche, come problema, nel fatto che in diversi contesti ed in diversi luoghi , da che è nato il sistema LoRa di trasmissione, si è cercato di sfruttare questa tecnologia per introdurre dei miglioramenti o delle nuove funzionalità a cose pre-esistenti….

Senza nessuna pretesa di originalità o di completezza provo a fare una sintesi di alcune applicazioni di LoRa in ambito radioamatoriale e della loro collocazione temporale:

• forse la prima applicazione è stata per i palloni sonda radiomatoriali basati su piattaforma arduino e chips lora di prima generazione
• successivamene è nata una applicazione LoRa-APRS pensata per girare su piattaforma HW raspberry e utilizzando chips lora di prima generazione; il SW era di tipo non open source   IOT4PI  e quindi non riproducibile o analizzabile agevolmente
• è stata quindi resa pubblica una nuova implementazione di APRS su LoRa  disponibile come opensource  https://github.com/sh123/esp32_loraprs  e che utilizzava come incapsulamento il formato AX.25 , conformemente all’APRS originale per es. su 144.800Mhz , sempre basato su chips LoRa di prima generazione e pensato per processori ESP32
• quindi è stata proposta una implementazzione opensource,  basata sull’approccio di incapsulamento dei pacchetti APRS presente in IOT4PI (e che nel seguito chiameremo OE_Style per intenderci)  e che usava il processore ESP32,  che è stata attivamente sviluppata ed è reperibile su https://github.com/peterus
• da questa implementazione sono poi scaturite numerose altre versioni che hanno mantenuto lo stesso tipo di incapsulamento;  esempi molto diffusi sono  https://www.lora-aprs.at/ (OE1ACM)   ,  lora-aprs/LoRa_APRS_iGate (OE5BPA)   ,  TTGO-T-Beam-LoRa-APRS (OE3CJB)  ,   ESP32_KISS_LoRa_APRS_1200 (M0IGA)  e TTGO-T-Beam-LoRa-APRS (SQ9MDD)     
• Dal punto di vista delle librerie utilizzate per la gestione dei chips LoRa, quasi tutte queste implementazioni utilizzano la libreria sandeepmistry/arduino-LoRa    e come incapsulamento il formato OE_Style
• Con l’avvento dei chips LoRa di seconda generazione sono emerse altre applicazioni di LoRa in particolare nell’ambito del progetto FOSSASAT e che si basava sull’uso di un diverso tipo di libreria per la gestione del chip Lora, ovvero la libreria   RadioLib  che è già in grado di gestire una lunga lista di dispositivi radio tra cui i chips LoRa sia di prima che di seconda generazione.
• Il risultato netto di questa situazione è che oggi esistono numerose versioni di HW/SW che però non possono interlavorare, ovvero miscelarsi in una rete LoRa-APRS.

 

Orbene, quando abbiamo pensato ad iniziare una nostra sperimentazione sul discorso “APRS over LoRa” ci siamo trovati,circa due anni fa, nel ben mezzo di una situazione tuttaltro che definita e soprattutto difronte alla evidenza che le poche proposte apparentemente disponibili non davano evidenze di deviare dall’uso dell’esistente, mentre noi si voleva proprio guardare avanti per es. verso i chips LoRa di seconda generazione non disponibili, al tempo e peraltro ancor oggi, sulle classiche implementazioni HW “cinesi”.

In un articolo di qualche tempo fa descrivemmo il nostro processo decisionale che ci portò a quella che è oggi la nostra piattaforma HW/SW; sostanzialmente i punti su cui ci basammo furono i seguenti

• un HW modulare basato su ESP32  per poter introdurre nuovi chips LoRa e altre varianti
• una piattaforma di sviluppo SW basata su Arduino IDE
• utilizzo della libreria RadioLib per la gestione delle radio ( loRa o non LoRa )
• utilizzo del formato di incapsulamento dei pacchetti APRS AX.25
• piattaforma SW  di partenza  https://github.com/sh123/esp32_loraprs
• gestione tramite interfaccia GUI da PC o cellulare

 

Su queste linee guida ci siamo coerentemente mossi.  Ovviamente  come è sempre consigliabile abbiamo evitato di deviare da questa impostazione prima di aver visto a quali risultati si potesse arrivare;  allo stato riteniamo di aver ottenuto una buona parte dei risultati a cui miravamo, per cui diventa possibile guardarsi intorno e vedere come la nostra soluzione si posizioni con le altre che nel frattempo ovviamente hanno pure esse subito delle evoluzioni per adattarsi ai tempi…

In particolare abbiamo cercato come prima cosa di analizzare gli elementi di fondo su cui si è purtroppo fino ad oggi basata l’evidenza di “incompatibilità”  delle varie soluzioni LoRa-APRS disponibili…  cercando se possibile di arrivare a superare tali incompatibilità e rendere possibile l’interlavoro tra le varie implementazioni, in modo da lasciare la possibilità di sperimentare sia gli aspetti di natura tecnica/radio, che gli aspetti di servizio ed applicativi o di modalità di gestione.

Dalla nostra analisi è emerso, forse un poco sorprendentemente…, che le differenze , almeno tra le due principali proposte in campo,  sono in concreto assai limitate e facilmente superabili, e si limitano in pratica ai seguenti punti:

• diversa “sync_word” tra i due sistemi principali: in un caso viene usato il valore 0x34 previsto nell’ambito delle specifiche LoRa per l’uso in ambienti “pubblici” , e nell’altra  viene usato il valore 0x12 previsto per ambienti “privati”, dove comunque il pubblico o privato non viene meglio specificato.
• diverso incapsulamento dei dati che compongono i messaggi APRS per produrre il “payload” da tasmettere tramite il sistema a pacchetto che usa LoRa ( nativamente binary compatible).
• diversa strategia di definizione ed utilizzo del campo “PATH” e di altri campi dello standard APRS di riferimento disponibile da anni, e recentemente emendato.

 

Preso atto di questi punti ci siamo attivati per cercare una soluzione che consentisse di “appianare” queste difformità consentendo quindi di ottenere almeno un parziale livello di compatibilità tra le due implementazioni di riferimento, in modo da poter far coesistere in una stessa rete dispositivi delle due tecnologie e consentendo quindi di condurre delle sperimentazioni di più ampio respiro.

 

Funzioni di compatibilità AX.25 / OE_Style

Allo stato è disponibile una versione 1.0.9 del nostro SW  ovviamente in fase che potremmo definire di beta-test  che consente le seguenti funzionalità:

• ogni nodo sia Tracker che iGate è in grado di ricevere pacchetti LoRa APRS delle due tecnologie gestendone (parzialmente e limitatamente) i contenuti in termini di componenti del payload APRS
• Ogni nodo  iGate è in grado di inviare verso internet i payloads ricevuti via LoRa  (indipendentemente dall’incapsulamento utilizzato) adattando eventualmente il PATH dei pacchetti provenienti dallo standard OE_Style
• Ogni nodo iGate è in grado di ritrasmettere verso il lato LoRa i pacchetti ricevuti, e filtrati, da APRS-IS utilizzando , opzionalmente il formato di incapsulamento AX.25 o OE_Style, marcando appropriatamente i payloads.
• Ogni nodo Tracker o iGate è in grado di trasmettere i propri dati utilizzando opzionalmente l’incapsulamento AX.25 o OE_Style
• Ogni iGate effetua il routing dei pacchetti APRS ricevuti utilizzando il classico sistema APRS basato sul metodo WIDE1-x.

 

Per consentire di superare il problema della “sync_word” diversa a livello LoRa viene consentito, da interfaccia GUI, di modificare il valore di sync_word da utilizzare.

Allo stato sono state effettuate un limitato numero di prove di compatibilità in campo di nostri dispositivi usando come base per i test la versione di SW  lora-aprs/LoRa_APRS_iGate (peterus)  e utilizzando come dispositivi HW due schedini “cinesi” rispettivamente TTGO-T-Beam vr 1 e Heltec LoRa wifi32,  con risultati positivi.

 

 

La figura precedente illustra un esempio di pacchetto trasmesso da I8FUC-7  in formato OE_Stype, ricevuto da I8FUC-10 processato attraverso la funzione di digipeater, con accorciamento del path, e ritrasmesso verso APRS-IS in formato standard e verso LoRa in formato AX25 con aggiunta del report di ricezione da parte di I8FUC-10 ( opzionale e che se presente ovviamente allunga il pacchetto).
Ovviamente I8FUC-10 continua in parallelo ad operare sui paccchetti ricevuti e ritrasmessi in formato AX25…   Tutti i dispositivi di questo scenario montano il nostro SW vers. 1.0.9

La figura sopra mostra un esempio di pachetto generato da I8FUC-5 che è un TTGO T-Beam con il SW  tracker originale di  https://github.com/lora-aprs/ e ricevuto da I8FUC-10, analizzato per vedere il routing e bloccato in quanto il path originale impedisce il routing per il path che contiene…

La figura mostra un ulteriore esempio di pacchetto echo ricevuto da I8FUC-7 che opera in modalità incapsulamento OE_Style, e ripetuto da I8FUC-5 che opera come iGate con il SW originale OE di cui sopra…

La figura sopra mostra un esempio di tracciato di un dispositivo I8FUC-6 basato sul SW https://github.com/lora-aprs/  originale  (con smart-beaconing disabilitato ) ed uno schedino TTGO T-Beam che viene ricevuto dal nodo iGate  I8FUC-10 che gira sulla nostra piattaforma HW/SW con SW Vr. 1.0.9 ….   Il test è stato effettuato utilizzando le modalità a livello radio della nosta rete LoRa, ovvero  larghezza di banda 31.25Khz, SF=7 e CR=7 ; data l’imprecisione di frequenza del TTGO è stato necessario settare l’offset di frequenza per allineare il TTGO alla frequenza corretta….

 

Disponibilità del SW vr. 1.0.9

Il nostro SW in versione. 1.0.9 è già disponibile come immagine binaria per le nostre piattaforme di sperimentazione .

Rispetto alle versioni precedenti è stata aggiunta una nuova pagina alla GUI per poter selezionare il tipo di incapsulamento dei pacchetti APRS, mentre alla schermata di setup della parte LoRa è stata aggiunta una nuova voce selezionabile alla casella “lora_sync”  per selezionare il valore da utilizzare.

Qualora ci fosse un qualche interesse da parti di altri a sperimentare il nostro SW , oltre che sulle nostre piattaforme HW, anche su piattaforme TTGO-T-Beam o Heltec LoRa wifi32  è possibile rendere disponibili le immagini binarie anche per queste piattaforme.