Come avrete notato sono trascorsi numerosi mesi dal mio ultimo post… forse qualcuno … ,malpensante,  avrà pensato:  finalmente hanno capito che quello che stanno ( o stavano ) facendo … sono tutte cazzate…  addirittura mi è capitato di scoprire che ci sono stati dei colleghi che si sono premurati di fare una analisi approfondita (???) del nostro lavoro HW/SW scoprendo infiniti problemi…. salvo poi scoprire che in realtà,  purtroppo per loro, si erano completamente sbagliati (non avevano capito nulla e non avevano letto nessuna delle nostre chiacchierate…)

Orbene devo dire che questi mesi di “silenzio” , purtroppo per gli eventuali malpensanti, sono stati mesi di intenso lavoro, ovviamente sempre compatibilmente con l’essere il nostro,  un hobby e quindi una “seconda” priorità rispetto ad altre priorità non radiantistiche…

Infatti per la prima volta siamo riusciti a vedere un certo numero di dispositivi dual-mode in funzione … cosa per niente scontata visto che la quasi totalità dei tracker in uso non sono ancora in grado di operare in split-mode…

Un secondo grosso risultato è che abbiamo avuto il piacere di notare che più di un collega ha cominciato a smanettare sull’HW e/o sul SW per testare approfonditamente particolari aspetti o introdurre nuove funzionalità…

Un terzo risultato, anche questo a mio modo di vedere importante , è l’aver scoperto quanta disinformazione esiste in giro su certe tematiche che dovrebbero essere un sottofondo comune e ben noto per chi ha anche in passato operato su tecnologie quali l’APRS o  i modi di trasmissione più innovativi.

Last but not least è stato un periodo di riflessione e di ripensamento del già fatto e di possibili nuove cose fattibili ad oggi sulla base della disponibilità di nuovi dispositivi o tecnologie…

Interessante è stato anche il confronto con svariati colleghi che ha consentito di focalizzare alcune tematiche interessanti o degne di approfondimenti…

Quello che pensavo di fare con questo post era in effetti provare a meglio chiarire l’obiettivo principale della nostra attuale fase di sperimentazione….

In effetti il nostro lavoro non è qualcosa che vuole mettersi in competizione con tante altre soluzioni HW/SW che utilizzano LoRa… il nostro obiettivo è quello di investigare una “nicchia” estremamente particolare dell’utilizzo di LoRa, ma che ci sembra una nicchia chiave perchè tutte le altre applicazioni possano essere realisticamente utilizzabili: ovvero come “evadere” dalla prigione dei 293 bit/sec…  consentendo di riutilizzare tutto il resto del parco “end points” esistente,,,,

Vorrei quindi provare , senza fare divagazioni accademiche,  a fare qualche considerazione… anche forse un poco “eretica”…

La prima considerazione che mi viene è quella della congestione.…  purtroppo sembra che ci siamo tutti dimenticati che LoRa opera su un canale condiviso da tutti gli utilizzatori attivi in una certa zona… ed ovviamente questo implica che se la zona è limitata, ovviamente è meno probabile che ci si calchi ii piedi, rispetto al caso di una zona molto estesa…   orbene si è scelto di usare un valore di SF=12 che teoricamente fornisce la massima ampiezza di zona copribile …  cosa che ovviamente sembra un controsenso…

La seconda considerazione è stata quella di osservare che con una banda disponibile di soli 293 bit/sec fare digipeating era praticamente da dementi…  e  quindi , almeno all’inizio, si è pensato di usare per LoRa una modalità di lavoro in cui i tracker parlavano e gli iGates ascoltavano solo ( senza parlare…) e mandavano su internet i beacon ascoltati…  strategia sicuramente appropriata ad una situazione in cui il canale radio utilizzabile era di soli 293 bit/sec…

Questo ha portato ad un paradosso…  sostanzialmente uno sperimentatore tipico innanzitutto metteva in funzione un iGate,  e poi solo dopo  semmai si dotava di un trarcker… il risultato è che si è arrivati ad una situazione paradossale, in cui si vedevano fiorire iGates ma non si vedeva quasi nessun tracker….

Orbene, fintanto che gli  iGates erano “muti”, ovvero ascoltavano solo ,  tutto filava liscio… si faceva a gara a vedere quale iGate era più bravo a far arrivare gli spots da lui ricevuti ,  su aprs.fi….. dimenticando che questo dipendeva ampiamente dalle regole di deduplicazione usate da aprs.fi, piuttosto che dalle caratteristiche dei nodi che riportavano tali spots…

Poi è cominciato a succedere ch, con l’espandersi della moda LoRa,  vecchi cultori del tradizionale APRS si sono affacciati pure loro al mondo LoRa ed immediatamente hanno fatto notare come fosse limitativo non sfruttare il digipeating !!!!!  e via con i WIDE1-1… ovviamente il fatto era simpatico perchè finalmente gli iGates cominciavano a parlare…. peccato che di iGates a parlare ce ne fossero non 1 o pochi… ma spesso tanti e soprattutto troppi…..

Ad un certo punto c’è stato pure qualcuno più scaltro degli altri,che ha anche pensato di superare il claustrofobico WIDE1-1 … e via con i WIDE2-2   a manetta….

Chi ha avuto un poco di esperienza con il vecchio classico APRS capisce subito a cosa tutto questo film porta …. congestione sempre maggiore e conseguentemente un crollo del sistema….

Ovviamente di fronte ad una tale situazione ed in prospettiva capirete bene che chiunque abbia un minimo di senno e di lungimiranza non può non dire: fermi tutti… facciamo un poco di conti… cerchiamo di capire meglio cosa succede… cerchiamo di capire come possiamo “evadere” dai famosi 293 bit/sec che di fatto sono la causa prima di tutto questo…

Capite quindi, spero, a questo punto il significato di quello che noi vorremmo fare:  da eretici diciamo pane al pane e vino al vino…  293 bit/sec NON è praticabile come “modo di lavoro prevalente”  … bisogna trovare qualcosa di meglio e per farlo è necessario  guardarci  intorno…

Ovviamente i miracoli in elettronica non esistono… per cui per fare qualcosa bisogna necessariamente scomodare … la scienza… e cercare di capire come il frutto degli scienziati che hanno inventato il protocollo LoRa possa venirci in aiuto…

La prima cosa che ci saltò in ment,e fin dall’inizio … eravamo nel 2018-2019, fu l’evidenza dell’utilizzo sostanzialmente universale di chips LoRa di prima generazione, quando oramai erano già disponibili chips LoRa di seconda generazione…..  uno dei grossi plus della seconda generazione LoRa è stata la disponibilità, finalmente, di un sistema di “Channel Activity Detection CAD” realmente funzionante:   di che si tratta direte… orbene conviene rileggere uno dei ripassini di qualche articolo fa… provo a riassumere…

Con i chip LoRa di prima generazione un trasmettitore che vuole impegnare un canale in genere parte a trasmettere appena  gliene viene la voglia…  questo implica che è abbastanza probabile che vada a “cozzare” con qualche altro trasmettitore che aveva già impegnato il canale…  il risultato come potete ben capire è una collisione con il risultato quasi garantito che solo uno dei trasmettitori riuscirà a farsi sentire se non addirittuta nessuno degli n trasmettitori che vanno in collisione…. visto che il tempo tipico di trasmissione di un pachetto in SF=12 è di circa ben 4-6 secondi…

Per cercare di mitigare questo problema i chip di prima generazione già includevano un meccanismo di CAD, ma questo meccanismo era molto “scadente” in quanto era sensibile esclusivamente alla fase di preambolo di un pacchetto trasmesso… di fatto era sostanzialmente inutilizzabile…

Con i chips di seconda generazione il meccanismo di CAD è stato rivisto ed ora è in  grado di rivelare non solo il preambolo ma tutto il pacchetto trasmesso…. cosa significa questo:  mentre con i chips di prima generazione di trasmeteva alla cieca, con i chips di seconda generazione si può fare innanzitutto una fase di “ascolto” e se il meccanimo CAD in questa fase dà via libera, passare a trasmettere….  capite bene che già da solo questo meccanismo dà una pesantissima mano a cercare di contenere la congestione in quanto “mette un poco di ordine” nel meccanismo di impegno del canale…

Tutti i nostri HW, fin dalla primissima versione, hanno sempre  e solo usato chips LoRa di seconda generazione… mentre il mondo continuava  imperterrito ad usare chips di prima generazione ….

Da solo questa proprietà non è però in grado di fare miracoli… resta il limite dei 293 bit/sec e del fatto che con SF=12 si hanno delle aree di copertura molto estese…

Diventa imperativo “evadere ” dai 293 bit/sec… e LoRa ci fornisce tantissimi modi per farlo… se almeno ci facciamo un poco di conti…  il fatto che LoRa possa essere usato con valori di SF da 12 fino a 5 fornisce un potentissimo strumento di ottimizzazione… infatti al diminuire dello “Spreading Factor”  si hanno due effetti concomitanti e apparentemente contrastanti…  un aumento notevole della banda trasmissiva disponibile ed una contrazione della area di copertuta di un trasmettitore, a parità di altri fattori….

Paradossalmente questi due fatti ci aiutano enormemente se sappiamo utilizzarli … infatti diminuendo lo spreading factor riusciamo ad arrivare anche a svariati Kbit/sec,  ma in aree più limitate… entrambi i fattori giocano a vantaggio di una riduzione della congestione come potete capire agevolmente… quindi la chiave è passare da SF=12 per es. ad SF=7 ( che è quello che stiamo cercando di sperimenatre attualmente)….

Purtroppo questo passaggio non è affatto semplice … e per un motivo pratico banale… tutto l’esistente lavora in SF=12… e se si passa ad SF=7 tutto l’esistente che fa ????   ovviamente non comunica….   capite bene che quindi il problema è trovare una soluzione che consenta di tenere in vita SIMULTANEAMENTE le due modalità di lavoro… cercando di far sì che si usi peferibilmente quella più veloce …

Ottimo mi direte… abbiamo trovato la soluzione !!!!!

Purtroppo tra il dire ed il fare ci sta di mezzo il classico mare:(

Infatti, se è vero che LoRa può lavorare in modi diversi. è anche vero che purtroppo un dispositivo non può lavorare SIMULTANEAMENTE in due modi diversi…  o meglio: se si tratta si operare come un end node ovvero un tracker, è certamente facile operare in modi diversi in RX e TX,,, in effetti un tracker o parla o ascolta… nessuno gli impedisce di ascoltare un modo o l’altro… o meglio può benissimo decidere di operare in un qualsiasi modo… a patto che i suoi corrispondenti possano fare altrettanto…  ed è qui che sorge l’inghippo… chi sono i corrispondenti elettivi per i tracker ?… gli iGates,,,,  e siccome un iGate opera in genere con una molteplicità di trackers diversi, ovviamente l’unico modo in cui  il discorso è fattibile è che l’iGate sia in grado di almeno ascoltare SIMULTANEAMENTE in due modi diversi…e questo richiede che l’iGate monti due radio diverse …

Siamo quindi arrivati ad un primo risultato: una qualsiasi strategia di migrazione che voglia salvare l’esistente non può non richiedere degli iGates a doppia radio…

Ma purtroppo questa condizione seppur necessaria, non è sufficiente a risolvere il problema: infatti bisogna fare in modo che i trackers e gli iGates si “capiscano” vicendevolmente per poter sfruttare i due modi in maniera utile… in altre parole è necessario un qualche meccanismo con il quale un tracker possa scoprire che in zona ci siano degli iGate a doppia radio, e dei criteri che gli consentano di impegnare uno dei modi di trasmisisonie disponibile in maniera affidabile…

La nostra sperimentazione proprio su questi punti attualmente sta cercando di lavorare…

Nell’ultima versione del SW Sarimesh vr.6.x è stata introdotta una prima modalità di interlavoro che attualmente stiamo cercando di valutare in campo… già sappiamo che sono possibili altre modalità… con la versione vr. 7 del SW attualmente in fase di sviluppo viene introdotta una seconda modalità…

Valutare i risultati di questi cambi e di questi meccanismi non è cosa proprio semplice, per cui una delle cose importanti che verrà introdotta nella nuova versione 7 è l’implementazione di una serie di “metriche”atte a valutare l’efficacia del sistema dual-mode in modo da capire come ottenerre il massimo delle prestazioni.

Ovviamente l’utilizzo di un modo LoRa a basso valore di SF riduce l’area geografica potenzialmente copribile….  ma il fatto in realtà non risulterà particolarmente impattante in quanto comunque resta utilizzabile, in caso di impossibilità di collegamento a basso SF,  la vecchia possibilità di lavoro ad SF=12 ovvero alla massima estensione dell’area di copertura…  sarà come dire che l’SF=12 verrà utilizzabile per i DX , mentre l’SF=7 diverrà la modalità di lavoro preferred quando ci si trova nelle vicinanze di un iGate a doppia radio… con il vantaggio enorme di ridurre drasticamente la congestione  in particolare sul modo SF=12.

Ovviamente tutto questo implica delle modifiche a livello dei dispositivi sia iGates che tracker ( end points).

Dal punto di vista HW un qualsaisi dispositivo a singola radio LoRa è in grado di operare in maniera tracker split-mode con sole modifiche di tipo SW.

L’anno scorso, proprio per capire l’entità di queste modifiche potenziali,  facemmo una serie di modifiche al SW di Ricardo che tutti conoscete,  con l’obiettivo di valutare la fattibilità e l’entità del lavoro di adattamente da fare sui SW in campo… il nostro test si svolse  sul SW di Ricardo in quanto quello più diffuso allo stato .. in una settimana circa di lavoro implementammo una “proof of concept”  con successo… tra l’altro inviammo pure le nostre patch al buon Ricardo,  il quale effuse complimenti , salvo poi a non dare seguito assolutamente al discorso.

Lato iGate, purtroppo il discorso è decisamente più complesso per due motivi: il primo è di tipo HW legato al fatto che bisogna usare dispositivi a doppia radio che attualmente non esistono in commercio, a parte ovviamente il nostro Maxi pensato ad hoc proprio allo scopo… un secondo motivo è che a livello SW, operare un dispositivo a doppia radio è abbastanza più complesso del semplice operare una singola radio, per la complessità del lavoro di sincronizzazione delle due radio, che difficilmente è fattibile in maniera usabile con dei SW di tipo NON multithreading… il nostro SW, come penso vi sia noto, è stato concepito proprio per operare in modo multithreading allo scopo di implementare agevolmente anche configurazioni di lavoro complesse e con requirement di tempo reale, diversamente dalla maggioranza degli altri SW attualmente utilizzati.

Questa evidenza, implica che, per effettuare un deploiment estensivo ci saranno due possibilità,,, la prima e quella più completa è quella di introdurre dei dispositivi iGate a doppia radio, la seconda sarebbe quella di “convertire  semplicemente dei dispositivi iGate a singola radio per operare in modalità SF=7  anzicchè in modo SF=12, sfruttando il fatto che attualmente ci sta una inflazione di iGate tutti operanti in SF=12.

Come vedete ci sta tanto lavoro da fare…. per chi vuole realmente fare della sperimentazione che non sia semplicemente quella di vedere i propri spots su aprs.fi 🙂

Una ultima nota:  per chi ama approfondire le caratteristiche di lavoro e le performancies del protocollo LoRa vi segnalo il sito dove è possibile trovare un “calcolatore” con cui determinare le caratteristiche di una tarsmissione LoRa al variare dei parametri impostati… :  “LoRa Calculator”