main index Le mie pagine sull'APRS sono qui!

A furia di fare statistiche sui pacchetti APRS ricevuti ho alcuni suggerimenti facilmente implementabili nel software di un digipeater al fine di ridurre le pessime abitudini (come quella di utilizzare routing eccessivi) e di ridurre i pacchetti duplicati.

A parità di sistemi APRS trasmittenti, queste semplici regole ridurranno drasticamente la collisione (e perdita) di pacchetti.

Ci tengo a sottolineare che queste riflessioni vengono solo dall'analisi del traffico ricevuto qui; può darsi che alcune delle soluzioni proposte siano già state implementate anche meglio di quanto descritto qui sotto: me lo auguro! Ma nel frattempo continuo a ricevere una gran quantità di pacchetti...


Prima regola: "routing enforcement"

Questo sistema, consigliato dallo stesso Bruninga (inventore dell'APRS), da ormai diversi anni ha già dato ottimi frutti in USA: visto che molti sono così pigri da non aver voglia o tempo di ridurre a valori normali quegli eccessivi routing, tanto vale che ci pensino i digipeater a fare un minimo di pulizia.

Quando il digipeater riceve un pacchetto APRS:

Nota: questo stratagemma tecnico non sostituisce l'educazione o il minimo di competenza di chi trasmette pacchetti APRS.


Seconda regola: "ignorare i pacchetti remoti"

Per i pacchetti APRS dalla International Space Station si può fare un'eccezione. Ma che senso ha ricevere continuamente i pacchetti di una stazione fissa (e impresenziata) a 500 chilometri di distanza e più?

Dato che il canale APRS ha un limite fisico decisamente basso (che qui voglio abbondantemente sovrastimare a un migliaio di pacchetti ogni venti minuti), è un vero spreco di risorse ogni pacchetto che arriva da "fuori area". Magari il primo giorno è divertente vedere pacchetti in arrivo dagli estremi confini della Francia e della Germania, ma dal secondo giorno (e comunque da quando tu cominci a trasmettere in APRS e non riesci a farti sentire a causa di tutto quel "rumore di fondo") non è più così.

Pertanto, quando il digipeater riceve un pacchetto APRS:

  1. se proviene da più di una certa distanza (suggerisco 150 km) allora ignorarlo;
  2. se non ha un'indicazione geografica, allora ignorarlo - a meno che il nominativo mittente non sia presente in un piccolo database locale di nominativi "vicini" (entro il raggio suggerito di 150 km).

Nota: una lista di oltre settemila nominativi ammessi richiederebbe appena 64 kilobytes di memoria, cioè è implementabile anche in un sistema APRS "embedded" senza troppo sforzo.


Terza regola: "delay casuale prima di ripetere"

Nel caso di stazione immobile (velocità uguale a zero: dunque tutte le stazioni fisse, e buona parte dei pacchetti delle stazioni mobili nel momento in cui sono ferme) allora ci si può permettere il lusso di ripeterne il pacchetto dopo diversi secondi (scegliendo casualmente il ritardo), senza che ciò scalfisca il concetto di "sistema tattico" dell'APRS.

Se arriva lo stesso pacchetto identico al precedente a meno della sezione di routing, allora significa che il pacchetto è stato ritrasmesso da un digipeater oppure erroneamente ritrasmesso dall'utente: in entrambi i casi conviene ignorarlo.

Nell'APRS, infatti, l'importante non è conoscere "immediatamente" una posizione, ma di conoscerla "affidabilmente". Col ritardo indicato, se due o più sistemi APRS ricevono contemporaneamente il pacchetto, diventa assai più improbabile che lo ritrasmettano a vicenda generando inutili duplicati.

Si può applicare anche a stazioni in movimento ma a velocità basse; in tal caso il "timeout" per la ritrasmissione dovrà essere minore; suggerirei di non utilizzare tale timeout in caso di velocità superiori a 15-20 km/h.

Dunque, quando il digipeater riceve un pacchetto APRS:

  1. se la velocità risulta da zero a 20 km/h, allora non ritrasmetterlo subito ma metterlo "in coda" per tentarne la ripetizione dopo un periodo casuale che va da uno a venti secondi (ridotto proporzionalmente al livello della velocità);
  2. se nel frattempo si riceve lo stesso pacchetto "ripetuto" dal mittente, allora ignorarlo e ricalcolare il timeout;
  3. se nel frattempo si riceve lo stesso pacchetto "ripetuto" da un altro digipeater, allora eliminarlo dalla coda di attesa (cioè non ripeterlo).

Nota: per ovvie ragioni questo meccanismo (praticamente una specie di CSMA 0.x-persistente) deve poter essere disabilitabile per determinati digipeater ("se il pacchetto è stato ripetuto da lui allora ti puoi fidare").


Quarta regola: "ignorare i pacchetti poco significativi"

Alcuni hanno la pessima abitudine di inserire al posto del callsign una sigla. Altri attivano delle weather station di cui arrivano i dati ma non si sa a "dove" sono riferiti (poiché non trasmettono altri pacchetti contenenti la loro posizione). Altri addirittura trasmettono pacchetti col callsign "NOCALL". Certi principianti talvolta trasmettono più e più pacchetti in pochi secondi, poiché non "vedono" arrivare subito un feedback dal digipeater ("non mi ha sentito?!").

Allora, quando un digipeater riceve un pacchetto:

  1. il digipeater ignorerà deliberatamente i pacchetti in cui il mittente non sembra un callsign (che è composto da 4 a 6 caratteri alfanumerici, di cui uno o due numerici, più eventuale "-nn" di seguito, con "nn" da 1 a 15, etc);
  2. il digipeater ignorerà i pacchetti provenienti da altri digipeater e sprovvisti di coordinate geografiche (a meno che il callsign non abbia precedentemente trasmesso una posizione; anche qui va implementata una lista di callsign conosciuti).
  3. il digipeater ignorerà i pacchetti contenenti valori sospetti (per esempio coordinate 0+0'0", telemetrie 0/0/0/0, etc);
  4. il digipeater ignorerà i pacchetti di "status" che contengono uno status uguale a quello precedentemente trasmesso se non è arrivata una posizione da almeno un'ora (vorrei far ignorare anche quelli con uno status vuoto).

Tutto questo parte dal presupposto che ancora non è stato fatto nulla per la "collaborazione attiva" tra i vari digipeater.