HomeUncategorizedLoRa APRS: alla ricerca di uno standard… per la compatibilità

Commenti

LoRa APRS: alla ricerca di uno standard… per la compatibilità — 6 commenti

  1. Dopo tanto tempo perso in rete, finalmente un riassunto chiaro e completo dello stato dell’arte!
    Mi sembra coerente (e quindi sposo) l’idea di mantenere l’incapsulamento nel protocollo AX25.
    Anche se questo protocollo è vecchio e quindi non molto efficiente se applicato su livello fisico Lora, il throughput APRS è così limitato che non penso sia un problema.

    Inoltre mi chiedo come fanno i GW OE_STYLE a inviare ad aprs.fi i pacchetti ricevuti via Lora, se mancano tutte le informazioni del PATH e del paradigma WIDEN-n.

    Rimango in attesa di vostri chiarimenti e vi saluto

    • ciao Alfredo, infatti ci sta un problema… la soluzione che ho implementato nel nostro SW è “forzare” un path di tipo standard LoRa…

      // fix APLT00-1 OE_style destination to include WIDE1-1 in order to allow routing from a standard iGate repeater algoritm
      if(( OE_Packet.indexOf("APLT00-1") >= 0 ) && ( OE_Packet.indexOf("APLT00-1,WIDE1-1") < 0 ) ) { // perform APLT00-1 enforcement to APLT00-1,WIDE1-1 if(APRS_debug) Debug.printf("<==== performing APLT00-1 fixing: OE_Packet= %s\r\n",OE_Packet.c_str() ); OE_Packet.replace("APLT00-1","APLT00-1,WIDE1-1"); if(APRS_debug) Debug.printf("====> performing APLT00-1 fixing: OE_Packet= %s\r\n",OE_Packet.c_str() );
      };

      … un poco violento ma penso che risolva il problema…

    • ciao Alfredo,
      non è indispensabile in quanto il server APRS-IS su cui l’iGate si registra per poter iniettare i suoi pacchetti, aggiunge automaticamente un q-construct del tipo qAS con il callsign dell’iGate… per es.

      Ultimo percorso: I8FUC-7>APLS01 via WIDE1*,qAS,I8FUC-10 (good)

      il primo callsign è quello del tracker che ha inviato il pacchetto, qAS lo ha aggiunto il server e il secondo callsign è quello cell’iGate su cui il pacchetto è transitato e che ha iniettato il pacchetto su APRS-IS sempre aggiunto dal server APRS-IS su cui l’iGate è loggato

      Quello seguente invece è un esempio di un pachetto di beacon generato dall’igate stesso e iniettato verso APRS-IS…

      2021-10-26 13:53:42 CEST: I8FUC-10>APLS01,TCPIP*,qAC,T2QUEBEC:!4038.67N/01424.55E#iGate-LoRa, 31.25/SF7 (8.68 I8FUC-10 Beacon 62.91)

      come vedi in questo caso il callsign sorgente è quello dell’iGate, mentre il server APRS-IS ha aggiunto un q-construct qAC e l’identità del server APRS-IS tramite cui il pacchetto è stato iniettato …

      ciao
      Michele I8FUC

  2. Grazie Michele, non sapevo che il q-construct venisse creato dal server e non dal client.
    A questo punto l’aggiunta del Wide1-1 basta, considerando che, da quanto ho capito, non ci sono ancora digipeater OE style, quindi i beacon OE style possono essere ascoltati solo in diretta.
    Confermi?
    Grazie ancora per le delucidazioni e 73
    Alfredo

    • il q-construct è pensato da quello che mi risulta principalmente per essere usato dai server di accesso APRS-IS per evitare effetti non voluti senza dover caricare gli igates di un lavoro ad hoc; volendo però è possibile anche inserire dei costrutti direttamente da parte dell’igate sfruttando una particolare clausola I ma che io sappia in genere non si usa perchè bisognerebbe modificare gli igates.
      Riguardo al discorso dei digipeater OE originali che io sappia non supportano le funzionalità digipeater APRS complete ma si limitano ad iniettare direttamente i pacchetti ricevuti verso internet… ma su questo punto non ritengo di essere aggiornato in quanto ho visto quel SW qualche anno fa e quindi non sono aggiornato degli sviluppi recenti.

      Volendo implementare in realtà una rete OE-Style con la funzionalità di digipeater basta usare il SW sarimesh impostando appropriatamente i valori dell’incapsulamento e della sync-word.

      73 Michele I8FUC

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *