Copertura del protocollo APRS#
Questa pagina confronta il firmware con il protocollo APRS in sé, capitolo per capitolo, invece di confrontarlo con altri programmi APRS. Dove Stato e limitazioni note chiede «come si colloca questo progetto rispetto a Direwolf o Xastir?», questa pagina chiede «quanta parte della specifica va in onda?».
Il riferimento usato in tutta la pagina è l’APRS Protocol Reference 1.2 — il
consolidamento dell’APRS101 1.0.1 originale (2000), dell’addendum APRS 1.1
approvato nel 2004 e delle aggiunte 1.2 pubblicate da allora — insieme ai
singoli file di specifica su aprs.org per le funzioni che esistono solo
lì.
Legenda:
✅ — Implementato e funzionante
⚠️ — Implementazione parziale o limitata
❌ — Non implementato
Un ❌ non è automaticamente un difetto. Diverse righe descrivono formati che la specifica stessa segna come obsoleti o «non raccomandati», e alcune descrivono convenzioni che richiedono hardware radio che questo progetto non pilota. La colonna Note chiarisce quale sia quale.
In tutte le tabelle, trasmettere significa che la stazione può originare il formato, e ricevere significa che il formato viene decodificato abbastanza da alimentare la cache dei duplicati, il filtro di distanza, Last Heard e il registro del traffico — non semplicemente ritrasmesso. Un pacchetto che il firmware non sa decodificare viene comunque digipetato e inoltrato ad APRS-IS, perché entrambi i percorsi lavorano sul campo indirizzi AX.25.
AX.25 e accesso al canale (cap. 3)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Trame UI AX.25, controllo 0x03 / PID 0xF0 |
✅ |
Soft-modem completo, in trasmissione e ricezione, sull’ADC e DAC dell’ESP32 stesso. Solo trame UI senza connessione, che è tutto ciò che APRS usa. |
Campo indirizzi: destinazione, sorgente e 0-8 digipeater |
✅ |
Decodificato e ricodificato rispettando il bit di già-ripetuto. Il decodificatore percorre il campo indirizzi confrontandolo con la lunghezza della trama, quindi un’intestazione che promette più ripetitori di quanti la trama ne porti viene rifiutata invece di essere letta oltre. I costruttori di percorso applicano il limite di 8 indirizzi. |
Accesso al canale CSMA p-persistente |
✅ |
Rilevamento di portante più persistenza, SlotTime e TXDelay configurabili. Un canale occupato viene atteso fino a un limite configurabile (0 = illimitato) e una serie di sorteggi di persistenza mancati a canale libero è limitata, così nessuno dei due può bloccare una trama per sempre. Le trasmissioni forzate sono contate separatamente per ciascun caso. |
Correzione d’errore FX.25 |
✅ |
Tre modalità: spento, sola ricezione, ricezione e trasmissione. Tutti gli 11 tag di correlazione. I blocchi trasmessi restano leggibili da un ricevitore AX.25 semplice. |
Interfaccia host KISS / AGWPE |
❌ |
La stazione non può fare da TNC per software client esterno. È deliberato: il firmware è una stazione completa, non una periferica modem. |
Campi indirizzo di destinazione e sorgente (cap. 4)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Identificatore di versione software nella destinazione (TOCALL) |
⚠️ |
Ogni pacchetto originato usa |
Dati Mic-E codificati nell’indirizzo di destinazione |
✅ |
Le cifre di latitudine, nord/sud, est/ovest e lo scostamento di longitudine sono codificati in trasmissione e riassemblati in ricezione insieme alla metà che viaggia nel campo informazioni. |
Percorso generico di digipeater nell’SSID di destinazione |
✅ |
Riconosciuto dal digipeater come forma di instradamento legacy, dietro un interruttore esplicito spento per impostazione predefinita perché non scavalchi mai un percorso esplicito. |
Simbolo nell’indirizzo di destinazione (GPSxyz / SYMxyz) |
✅ |
Letto in ricezione quando il campo informazioni non fornisce un simbolo proprio, in tutte le forme |
Simbolo dall’SSID dell’indirizzo sorgente (obsoleto) |
⚠️ |
Applicato in ricezione solo come ultimo passo della catena di precedenza dei simboli, e solo ai pacchetti NMEA grezzi, l’unico caso per cui la convenzione è stata inventata. Per ogni altro tipo di dato l’SSID resta il ruolo della stazione, che è ciò che significa oggi. |
Reti alternative |
❌ |
Il traffico originato usa sempre il TOCALL del progetto; non c’è un’impostazione per un indirizzo di destinazione di rete alternativa. |
Formati di ora e posizione (cap. 6)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Latitudine e longitudine non compresse |
✅ |
Trasmesse e analizzate nella forma |
Marca temporale zulu giorno/ora/minuto |
✅ |
È l’unica forma che questa stazione origina, su posizioni, oggetti, rapporti di stato e meteo. L’orologio funziona sempre in UTC, quindi non interviene alcuna conversione di fuso. |
Marche temporali locale giorno/ora/minuto e ora/minuto/secondo in ricezione |
✅ |
Vengono lette tutte e quattro le forme: le due forme zulu da 7 byte, quella storica in ora locale e la marca mese/giorno/ora/minuto di un rapporto meteo senza posizione. Le forme zulu sono risolte in UTC assoluto rispetto all’orologio, tornando indietro di un giorno, di un mese o di un anno quando il valore cadrebbe nel futuro, e la forma locale è riportata esattamente come l’ha scritta il mittente, perché il pacchetto non nomina il fuso in cui si trova. Il valore è mostrato nella colonna DECODIFICATO della tabella del traffico, che è ciò che distingue un pacchetto ritrasmesso con minuti di latenza da uno appena sentito. |
Ambiguità di posizione |
✅ |
Da una a quattro cifre in bianco in trasmissione, a livello di stazione. In ricezione i minuti in bianco sono analizzati cifra per cifra e risolti al centro del riquadro di ambiguità, così una posizione grossolana si filtra comunque per distanza in modo ragionevole invece di collassare verso il bordo del grado. |
Altitudine |
✅ |
La forma |
|
✅ |
Trasmesso su posizioni non compresse e dentro il campo di testo Mic-E, soppresso quando è in uso l’ambiguità di posizione o è selezionato il formato compresso, perché entrambi dichiarano già una precisione diversa. Un token ricevuto viene applicato nel verso opposto, in entrambe le sue forme d’aria — le cifre leggibili e la forma base-91 che emette la maggior parte dei tracker — così una posizione non compressa in arrivo viene raffinata fino a circa 18 m prima che il filtro di distanza la misuri. Un rapporto compresso viene lasciato com’è, perché i suoi campi base-91 portano già quella precisione. |
Rapporti di posizione NMEA grezzi ( |
✅ |
Le frasi |
Posizione nulla predefinita |
❌ |
Le coordinate configurate vengono sempre trasmesse così come sono; non c’è convenzione per segnalare «posizione sconosciuta» quando l’operatore non le ha impostate. |
Estensioni dati (cap. 7)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Rotta e velocità |
✅ |
Nello slot da 7 byte non compresso, nella forma compressa a due byte e nel Mic-E. |
Direzione e velocità del vento |
✅ |
Occupa lo stesso slot da 7 byte nei rapporti meteo con posizione, con segnaposto quando nessun sensore è mappato. |
Potenza / altezza / guadagno / direttività (PHG) |
✅ |
Costruito da watt, piedi, dBi e una direzione nella pagina Station e rispecchiato nei beacon per ruolo e negli oggetti. |
Sonde PHGR (carattere di cadenza del beacon) |
✅ |
La forma a nove byte della 1.2 («PHGphgd» più un carattere di cadenza in beacon all’ora e la barra finale obbligatoria) viene trasmessa ogni volta che l’intervallo proprio del beacon IGate è noto, il che avviene sempre, ed è analizzata in ricezione: il carattere di cadenza e la barra vengono riconosciuti e rimossi, così il commento che segue viene letto correttamente invece di iniziare con una barra vagante. |
Portata radio precalcolata (RNG) |
✅ |
Selezionabile come estensione dati dei beacon IGate e digipeater, in miglia terrestri. Il beacon tracker porta solo PHG. |
Intensità di segnale omni-DF (DFS) |
✅ |
Selezionabile come estensione dati dei beacon IGate e digipeater, con l’intensità in punti S più gli stessi codici di altezza, guadagno e direttività usati da PHG. |
Rilevamento e numero/portata/qualità (BRG/NRQ) |
✅ |
In trasmissione e in ricezione. Disponibile su oggetti e item e sul beacon di posizione della stazione stessa, nella forma |
Estensioni dati in ricezione |
✅ |
Lo slot da 7 byte di un rapporto non compresso in arrivo viene analizzato invece di essere letto come i primi sette caratteri del commento: |
Descrittore di oggetto area |
✅ |
Codifica completa di forma, colore e dimensione, inclusa la regola che sostituisce la barra con una cifra per valori di colore da dieci in su. I due codici di dimensione usano la scala corretta di 1500-esimi di grado e non i centesimi del testo originale. |
Formati dei rapporti di posizione e DF (cap. 8)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Tutti e quattro gli identificatori di tipo dato di posizione |
✅ |
In trasmissione e ricezione. La scelta fra gli identificatori con e senza capacità di messaggistica segue l’impostazione reale di messaggistica della stazione, non il fatto che ci sia o meno una marca temporale. |
Identificatore |
✅ |
Una posizione senza marca temporale introdotta da un |
Campo commento |
✅ |
Presente in ogni posizione originata, con il blocco di frequenza, |
Formato del rapporto DF |
✅ |
Selezionabile come estensione dati del beacon di posizione della stazione stessa, che è la forma descritta dal capitolo per una stazione di radiogoniometria, oltre che su oggetti e item per un rilevamento preso su un’altra stazione, e decodificato in ricezione. Viaggia solo con il simbolo DF (tabella |
Rapporti di posizione compressi (cap. 9)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Latitudine e longitudine compresse in base-91 |
✅ |
Selezionabile per servizio — tracker, IGate, digipeater e oggetti — e decodificata in ricezione. La compressione è soppressa automaticamente quando sono in uso un’estensione PHG o DF o l’ambiguità di posizione, perché nessuna di queste sopravvive al formato compresso; la portata radio precalcolata è l’unica estensione che invece lo fa, e viene ripiegata nel campo a due byte. |
Rotta/velocità compresse e il byte di tipo di compressione |
✅ |
Un tracker in movimento codifica rotta e velocità nel campo a due byte e imposta il byte di tipo su rotta/velocità compresse con fix corrente; una stazione senza nulla da riportare invia la codifica a tre spazi di «nessun dato». Il campo quantizza la rotta a passi di 4 gradi e la velocità a passi di circa l’8 per cento, e il codificatore mantiene entrambi i byte nell’intervallo che appartiene alla forma rotta/velocità, quindi un token non viene mai letto come la forma di portata radio che condivide quei due byte. In ricezione i tre byte sono riletti allo stesso modo: il byte di tipo decide fra altitudine, portata radio e rotta/velocità, così una stazione in movimento mostra la sua rotta e la sua velocità invece di una coordinata nuda. |
Portata radio precalcolata compressa |
✅ |
Una baliza la cui estensione dati è la portata radio precalcolata la ripiega nel campo a due byte — il marcatore riservato |
Altitudine compressa |
✅ |
Un beacon compresso che porta un’altitudine la mette negli stessi due byte, con il byte di tipo che dichiara GGA come sorgente, che è ciò che seleziona quella lettura. Quando lo fa, il token |
Formato dati Mic-E (cap. 10)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Mic-E in trasmissione e ricezione |
✅ |
Codificatore e decodificatore completi, che coprono la metà nell’indirizzo di destinazione, la longitudine, la velocità e la rotta, la coppia di simbolo compreso il suo carattere di sovrapposizione, e entrambi gli identificatori di tipo dato, l’attuale e il vecchio. |
Codice di tipo e identificatore del costruttore |
✅ |
Il byte di tipo segue il byte della tabella simboli e riflette la capacità di messaggistica della stazione; la coppia costruttore/versione chiude il campo di testo. Senza di essi un beacon Mic-E è anonimo per ogni client, perché l’indirizzo di destinazione porta la posizione e non può anche identificare il firmware. |
Altitudine, blocco di frequenza e |
✅ |
L’altitudine apre il campo di testo e sposta il commento invece di sostituirlo, e il blocco di frequenza e l’estensione datum sono emessi nell’ordine canonico mostrato dagli esempi della specifica stessa. |
Codici di commento di posizione (Off Duty, En Route … Emergency) |
✅ |
Il ricevitore decodifica tutti e quindici i valori, incluso l’insieme personalizzato e lo schema Emergency di tutti zeri, e riporta correttamente come indefinito uno schema misto standard/personalizzato. La pagina Tracker consente di scegliere per la trasmissione uno qualsiasi dei quattordici valori standard e personalizzati. Emergency è deliberatamente assente da quell’elenco: chiede ad altri operatori di rispondere a un’emergenza reale, cosa che una pagina di configurazione non dovrebbe poter attivare con un clic sbagliato e lasciare attiva per tutti i beacon successivi. |
Indicazione di emergenza |
✅ |
Un’emergenza Mic-E ricevuta via radio o da APRS-IS produce una riga di log di livello warning e una propria voce nel registro del traffico, accanto al pacchetto che l’ha trasportata. Gli altri quattordici commenti di posizione sono registrati a livello informativo, perché il valore vive nell’indirizzo di destinazione ed è altrimenti invisibile nel testo del pacchetto. Le forme tra parentesi esclamative nel campo commento che una stazione priva di Mic-E usa per la stessa segnalazione ( |
Velocità oltre i 670 nodi |
✅ |
L’estensione 1.2 è applicata in entrambi i versi, quindi una trama digipetata da una stazione spaziale riporta la propria velocità orbitale invece di una troncata. Quella scala è quantizzata a passi di 112 nodi e ha un vuoto fra 671 e 781 nodi che la regola pubblicata stessa lascia senza rappresentazione; sotto i 671 nodi il campo resta esatto al nodo. |
PHG dentro il campo di testo Mic-E |
✅ |
L’estensione dati viene scritta dentro il testo Mic-E, dopo il blocco di frequenza e prima del commento dell’operatore, così una stazione che trasmette beacon in Mic-E annuncia la propria copertura come consente l’aggiunta 1.2. L’interruttore è nella pagina Tracker; i suoi quattro sottocampi sono i dati d’antenna della stazione stessa. |
Telemetria Mic-E |
❌ |
Deliberatamente assente: la versione 1.2 depreca questo formato a favore dei codici di tipo del costruttore e della telemetria base-91 nel commento, entrambi implementati da questo firmware. |
Rapporti di oggetto e item (cap. 11)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Rapporti di oggetto |
✅ |
Cinque slot configurabili, nomi riempiti a nove caratteri, stati vivo e annullato, posizione compressa o non compressa, con l’intero insieme in trasmissione e ricezione. |
Rapporti di item |
✅ |
Nomi variabili da tre a nove caratteri con i marcatori di vivo e annullato. Va notato che la specifica segna il formato item come non raccomandato in RF; gli oggetti sono la scelta migliore per qualcosa di lunga durata. |
Annullare un oggetto o item |
✅ |
Un oggetto annullato viene ritrasmesso alcune volte come rapporto di annullamento prima che il suo flag di abilitazione venga azzerato, così i riceventi vedono davvero il ritiro invece di lasciare che l’oggetto invecchi nelle loro liste. |
Oggetti permanenti |
✅ |
Viene emessa la pseudo-marca temporale fissa di tutti uno per un oggetto contrassegnato come permanente, che è ciò che serve a un oggetto fisso di ripetitore o punto di riferimento. |
Oggetti di area |
✅ |
Forma, colore e dimensione sugli stessi slot di oggetto, con le forme a linea in grado di dichiarare una larghezza di corridoio in miglia come token tra parentesi graffe in testa al commento. |
Oggetti e item segnaletici |
✅ |
Fino a tre caratteri di testo del cartello fra graffe, sul simbolo apposito. |
Instradamento proporzionale per gli oggetti |
✅ |
Un preset di percorso per trasmissione, ruotando fra loro, così un oggetto di lunga durata non inonda ogni salto a ogni ciclo. Ogni preset è contato in salti ed escluso dalla rotazione se supera il limite AX.25. |
Rapporti meteorologici (cap. 12)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Rapporto meteo completo, con e senza marca temporale |
✅ |
La forma raccomandata, con il simbolo meteo, l’estensione dati del vento e il blocco completo dei dati meteo. L’identificatore di tipo con capacità di messaggistica segue l’impostazione di messaggistica della stazione, come per le posizioni ordinarie. |
Rapporto meteo come oggetto |
✅ |
Un oggetto meteo con nome in una posizione diversa da quella della stazione. |
Rapporto meteo senza posizione |
⚠️ |
Emesso quando la stazione non ha coordinate configurate, con la marca temporale mese/giorno/ora/minuto richiesta dal formato. La neve è omessa da questa forma di proposito, perché la lettera che userebbe è già la velocità del vento lì; il firmware registra a log quando questo scarta una lettura configurata. La specifica segna questo formato come non raccomandato. |
Campi meteo obbligatori |
✅ |
Direzione e velocità del vento, raffica e temperatura sono sempre emesse, ripiegando sui segnaposto a punti quando nessun sensore è mappato, così il rapporto resta una trama meteo valida e non troncata. |
Pioggia, umidità e pressione barometrica |
✅ |
Pioggia nell’ultima ora, nelle ultime 24 ore e da mezzanotte; umidità con la codifica a due zeri per il 100 %; pressione in decimi di millibar nel campo completo a sei caratteri confermato dalla revisione 1.2. |
Luminosità e nevicata |
✅ |
La luminosità usa la lettera maiuscola sotto i 1000 W/m² e quella minuscola sopra; la nevicata usa la forma frazionaria sotto i dieci pollici e quella intera con zeri sopra. |
Idrometro / altezza di piena |
✅ |
Entrambe le forme, in piedi e in metri, della proposta idrometro della 1.2, con risoluzione al decimo e senza riempimento, come mostra l’esempio di quel documento. |
Identificatori di tipo software e di unità meteo |
⚠️ |
Entrambi sono emessi, come ultimo token del campo informazioni perché un parser rigido non assorba il commento dell’operatore nella stringa dell’unità. Il codice di unità è libero e va bene; il singolo carattere di tipo software è uno che la specifica non assegna. |
Contatore di pioggia grezzo |
✅ |
Il conteggio corrente del pluviometro stesso, quattro cifre dopo un |
Campi di radiazione e tensione |
❌ |
I due campi proposti per la 1.2 non hanno un token meteo proprio e viaggiano come canali analogici di telemetria, che è dove li instrada il framework dei sensori. |
Rapporti meteo grezzi Peet Bros e Ultimeter |
⚠️ |
Riconosciuti come meteo dal classificatore di gateway, quindi vengono instradati correttamente, ma i payload grezzi non sono mai decodificati in letture. La specifica dice comunque che chi trasmette dovrebbe convertire al formato completo, quindi si tratta di ampiezza in ricezione e non di una lacuna in trasmissione. |
Dati di tempesta |
❌ |
Nulla codifica o decodifica la forma in onda. Una stazione di questo tipo non ha da dove ricavare quell’informazione — viene dai servizi meteo — quindi ritrasmettere tali pacchetti intatti, come accade oggi, è il comportamento sensato. |
Dati di telemetria (cap. 13)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Rapporto di telemetria |
✅ |
Numero di sequenza, cinque canali analogici e il banco digitale a otto bit, con i canali mappati per nome ai driver dei sensori locali perché abilitare o disabilitare un driver non li ripunti silenziosamente. |
Intervallo analogico esteso 000-999 |
✅ |
Il campo a tre cifre accetta l’intero intervallo 1.2 invece della finestra originale 000-255, e le letture fuori intervallo sono limitate invece che avvolte. Prima si applicano un minimo e un massimo grezzi per canale, così l’operatore può tenere i valori dentro la finestra che il suo software ricevente comprende. |
Definizioni dei parametri in onda |
✅ |
Tutti e quattro i messaggi di definizione — nomi, unità ed etichette, coefficienti dell’equazione e senso dei bit con titolo del progetto — inviati come messaggi indirizzati, come richiede la specifica. Il rapporto porta il valore grezzo e il ricevitore applica i coefficienti. |
Telemetria base-91 nel commento |
✅ |
Il contatore di sequenza, i canali analogici e il banco digitale a otto bit sono codificati nel gruppo delimitato da barre verticali. Poiché quel gruppo è posizionale — l’n-esima coppia è il canale n, senza identificatore per coppia — il codificatore si ferma al primo canale disabilitato o non risolto invece di lasciare un vuoto che sposterebbe di un posto ogni canale successivo, e la coppia digitale viene aggiunta solo dietro un insieme completo di cinque coppie analogiche, l’unico punto in cui la specifica la consente. Una stazione senza alcun canale da riportare non emette alcun gruppo, poiché l’estensione deve portare il contatore e almeno un canale. |
Forma alternativa del numero di sequenza |
❌ |
L’identificatore di sequenza a tre lettere che alcuni codificatori usano al posto di un numero non è prodotto né riconosciuto in modo speciale in ricezione. |
Messaggi, bollettini e annunci (cap. 14)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Messaggi di testo con conferma e rifiuto |
✅ |
Campo destinatario a nove caratteri, corrispondenza di conferma e rifiuto limitata a uno-cinque caratteri alfanumerici come consente la specifica, e un timer di ritentativo per i messaggi in uscita non confermati. Una riga entrante viene presa come messaggio solo quando il suo campo informazioni porta l’inquadratura completa — l’identificatore |
Reply-ACK |
✅ |
Tutte e sette le regole dell’algoritmo, incluso costruire il suffisso nell’istante della trasmissione e tenere una piccola tabella per stazione delle conferme dovute. È ciò che fa scorrere uno scambio di messaggi a velocità di conversazione invece di due pacchetti per turno. |
Formato del numero di messaggio |
⚠️ |
I numeri in ingresso di qualsiasi lunghezza legale vengono riconosciuti. I messaggi in uscita si numerano con due cifre, con ritorno a capo a 99, così un suffisso Reply-ACK rientra ancora nei cinque caratteri che la specifica consente per l’intero identificatore. |
Gruppi di messaggi |
✅ |
I messaggi indirizzati ai nomi di gruppo integrati |
OBJECT-in-MSG e ITEM-in-MSG |
❌ |
Le due proposte 1.2 che portano un report completo di oggetto o item dentro il corpo di un messaggio, pensate per una stazione che non può digiripetere il pacchetto oggetto/item ordinario, non sono riconosciute come classe a sé. Questa stazione non ha una mappa su cui tracciarne uno e non origina né necessita di quell’espediente; un messaggio che usa una delle due forme arriva comunque all’operatore come testo semplice. |
Codifica del testo UTF-8 |
✅ |
I campi messaggio e gli altri campi di testo libero sono trasparenti a 8 bit da un capo all’altro: nulla qui ricodifica o rifiuta un byte non ASCII, il che è la raccomandazione della specifica stessa ( |
Bollettini generali, annunci e bollettini di gruppo |
✅ |
Cinque slot configurabili con le forme di destinatario corrette per tutti e tre: identificatore numerico per i bollettini, identificatore a lettera per gli annunci e suffisso col nome del gruppo per i bollettini di gruppo. Ogni slot ha la propria scadenza. |
Cadenza di trasmissione dei bollettini |
✅ |
Ogni slot porta la cadenza decrescente raccomandata dalla specifica: un intervallo iniziale, una cadenza lenta e il rapporto per cui viene moltiplicato l’intervallo dopo ogni trasmissione finché non raggiunge quella cadenza lenta e vi si mantiene. Un bollettino è così frequente all’inizio e si dirada nell’arco di ore, il che carica meno un canale condiviso a parità di effetto. La rampa riparte dall’intervallo iniziale a ogni modifica o riavvio, e lasciare non impostata la cadenza lenta o il rapporto mantiene l’intervallo piatto. |
Bollettini del servizio meteorologico nazionale |
❌ |
Il loro contenuto non viene analizzato: un bollettino del servizio meteorologico è gestito come il messaggio ordinario che è sul filo, ritrasmesso correttamente e mai confermato, perché il destinatario non è questa stazione. La famiglia di destinatari è invece riconosciuta in un punto — il gateway INET → RF, che non mette mai in onda un bollettino o una diffusione del servizio meteorologico — quindi ciò che resta è come tale avviso viene etichettato nell’interfaccia. |
Radiogrammi NTS |
❌ |
La convenzione dei prefissi di riga non viene analizzata. La specifica dice esplicitamente che un’applicazione non deve necessariamente comprenderla, perché le righe sono messaggi ordinari e si leggono correttamente come testo semplice, che è ciò che accade qui. |
Capacità di stazione, interrogazioni e risposte (cap. 15)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Interrogazioni generali |
✅ |
L’interrogazione a tutte le stazioni, inclusa l’impronta opzionale di latitudine, longitudine e raggio, più le interrogazioni broadcast di meteo, IGate e QRU. Un’interrogazione che arriva da internet riceve risposta su internet e una che arriva in RF riceve risposta in RF, così un’interrogazione da internet non può mai eccitare il trasmettitore. |
Interrogazioni dirette a una stazione |
✅ |
L’insieme completo: posizione, stato, stazioni udite in diretta, cronologia di una stazione udita, messaggi in sospeso, oggetti e traccia del percorso, incluso l’alias ping per l’interrogazione di traccia. Le risposte sono costruite dallo scheduler dei beacon e non dal task di ricezione, così una raffica di interrogazioni non può far traboccare uno stack di ricezione. |
Cronologia delle stazioni udite |
✅ |
L’istogramma di 18 ore richiesto dalla specifica, tenuto per stazione e trasportato con essa quando la sua riga si sposta in cima alla tabella. |
Pacchetto delle capacità di stazione |
✅ |
Inviato in risposta all’interrogazione IGate e, quando l’operatore lo abilita, con un temporizzatore proprio, così un vicino scopre che il gateway esiste senza chiedere. Entrambi portano la stessa riga, con il token di gateway, i contatori di messaggi e di stazioni locali — che significano ciò che dice la specifica e non totali grezzi di trame — e gli eventuali elementi aggiuntivi digitati dall’operatore, perché il modello delle capacità è aperto. |
Rapporti di stato (cap. 16)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Rapporto di stato con e senza marca temporale |
✅ |
Testo di stato per ruolo con marca temporale zulu opzionale. |
Budget di lunghezza del testo di stato |
✅ |
Il limite di 62 caratteri è applicato scartando i blocchi opzionali in un ordine definito — prima il locatore, poi il blocco di frequenza — e il testo dell’operatore non viene mai toccato. Se ancora non entra, il rapporto viene rifiutato invece di essere troncato in una trama malformata. |
Rapporto di stato con locatore Maidenhead |
✅ |
Il locatore a quattro o sei caratteri e il suo simbolo vengono prodotti subito dopo l’identificatore di tipo dato, prima del blocco di frequenza. Non viene mai combinato con una marca temporale: se entrambi sono abilitati, il locatore ha la precedenza e la marca temporale viene omessa. |
Direzione d’antenna e potenza irradiata efficace |
✅ |
I due caratteri chiudono il testo di stato dopo un |
Tunneling di rete e traffico di terze parti (cap. 17)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Trame di terze parti |
✅ |
Costruite quando si ritrasmette traffico da internet verso RF e scartate in ingresso, usando il nominativo della stazione interna per la soppressione dei duplicati e Last Heard, non quello del gateway. Una trama che non entra viene rifiutata invece che troncata. |
Token di percorso che vietano il gateway |
✅ |
Sono rispettati tutti i classici token di divieto di gateway e i q-construct di sola internet, e solo nell’intestazione dove hanno senso: un pacchetto il cui commento contenga per caso una di quelle parole non viene scambiato per uno instradato con essa. |
Marcatore di non archiviazione |
✅ |
La stringa |
Rapporto del percorso IGate→RF |
❌ |
L’involucro sperimentale |
Specifica di frequenza (cap. 18)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Blocco di frequenza in posizioni, oggetti e stato |
✅ |
Vengono prodotte tutte e tre le forme fisse da dieci byte: quella a dieci kilohertz sotto i 100 MHz, la forma comune in VHF e UHF e quella con prefisso a lettera per le bande a microonde; si lavora in kilohertz interi perché nessuna cifra derivi, e si rifiuta di emettere qualsiasi cosa non misuri esattamente dieci byte. |
Tono, scostamento e portata |
✅ |
Il tono CTCSS a tre cifre, lo scostamento in unità di dieci kilohertz e la portata di copertura a due cifre in miglia o chilometri, nell’ordine definito dalla specifica di frequenza. La portata è un sottocampo di Oggetti/Elementi (la copertura che un ripetitore fisso annuncia di sé), non un’impostazione per servizio di tracker, IGate o ripetitore digitale. |
Tono a banda stretta, codice DCS e frequenza TX/RX separata |
❌ |
Altri tre sottocampi opzionali definiti dalla specifica non vengono costruiti: l’indicatore di modulazione a banda stretta (minuscolo), il codice DCS che può sostituire il tono CTCSS, e la forma con frequenza di trasmissione/ricezione separata. Nessuno dei tre è un difetto nel blocco che questa stazione trasmette, che resta valido e auto-sintonizzabile anche senza di essi - sono lacune di capacità, tralasciate perché il firmware non ha un’impostazione radio a banda stretta/DCS da riportare e objitem_t modella un’unica frequenza di monitoraggio invece di TX/RX indipendenti. |
Richieste di frequenza e QSY nei messaggi |
❌ |
Non vengono generate né gestite le forme di messaggio proposte che richiedono o comandano un cambio di frequenza operativa. Sono proposte 1.2 con scarsa diffusione sul campo. |
Formati definiti dall’utente e altri tipi di pacchetto (cap. 19-20)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Formato dati definito dall’utente |
❌ |
Lo spazio di estensione privata che la specifica riserva agli sperimentatori è inutilizzato. Sarebbe la sede corretta per qualsiasi diagnostica specifica del firmware che il progetto volesse mettere in onda, invece di sovraccaricare il testo di stato. |
Pacchetti di dati non validi e di prova |
❌ |
L’identificatore dei dati di prova non è riconosciuto come classe a sé, quindi tali pacchetti finiscono nel percorso generico. Non dovrebbero mai essere inoltrati a internet. |
Formato di radiogoniometria Agrelo |
❌ |
Il formato di rilevamento e qualità del radiogoniometro autonomo non viene decodificato. Restano pochissime unità in servizio. |
Beacon con locatore Maidenhead |
❌ |
L’identificatore del beacon di locatore autonomo non viene decodificato. La specifica stessa lo segna come obsoleto; il locatore ora vive nei rapporti di stato. |
Identificatori riservati (elemento di mappa, dati di rifugio, meteo spaziale) |
❌ |
Riservati dalla specifica e mai definiti ulteriormente, quindi non c’è nulla da implementare. |
Nessuno dei cinque identificatori qui sopra porta un payload che questo firmware decodifichi, ma tutti e cinque sono classificati per l’instradamento sotto un unico bit di filtro condiviso, la casella «Altri» della pagina IGate Filter, così un pacchetto di una qualsiasi di quelle classi può essere inoltrato ad APRS-IS invece di essere scartato qualunque cosa spunti l’operatore. Il traffico di terze parti e i dati di test restano non classificati di proposito e non vengono mai ritrasmessi: re-instradare il traffico di terze parti è il modo in cui nascono i loop di IGate, e i dati di test non sono pensati per lasciare il canale su cui sono stati inviati.
Simboli (cap. 21)#
Funzione APRS |
Stato |
Note |
|---|---|---|
Tabelle dei simboli primaria e alternativa |
✅ |
Un selettore visuale nell’amministrazione web copre entrambe le tabelle, con un simbolo per ruolo per tracker, IGate, digipeater, stazione meteo e ogni oggetto. |
Caratteri di sovrapposizione |
✅ |
Un carattere di sovrapposizione può essere collocato nella posizione della tabella per i simboli che lo accettano, ed è così che un digipeater annuncia la propria politica di instradamento sulla mappa. Sono accettate sovrapposizioni alfabetiche e numeriche, e una numerica viene emessa in un rapporto compresso come la lettera minuscola |
Precedenza dei simboli |
✅ |
Le tre sorgenti vengono consultate in ricezione nell’ordine fissato dal capitolo. Il campo informazioni vince ogni volta che fornisce un simbolo: tutti i formati di posizione, oggetto ed elemento, compressi o meno, e Mic-E, la cui coppia di simbolo viaggia lì anche se la sua posizione no. Un payload che non porta un simbolo proprio, soprattutto una sentenza NMEA grezza, ripiega sull’indirizzo di destinazione e poi, solo per quel tipo di dato, sull’SSID di origine. Mic-E è escluso dal passo dell’indirizzo di destinazione, perché lì trasporta latitudine, codice di messaggio e ambiguità, non un simbolo. Un unico risolutore condiviso serve entrambi i flussi, così una stazione si legge allo stesso modo sia che venga ascoltata via radio sia che arrivi da APRS-IS. In trasmissione la questione non si pone: il traffico originato porta sempre il proprio simbolo nel campo informazioni. |
Convenzioni SSID |
✅ |
Gli SSID di ruolo raccomandati sono i valori di fabbrica di ogni servizio, e ogni campo SSID è verificato per intervallo sia nel modulo sia nel caricatore di configurazione. |
Digipeating e il paradigma New-N#
Funzione APRS |
Stato |
Note |
|---|---|---|
Digipeating New-N tracciato |
✅ |
Una tabella di alias definita dall’operatore, con forma jolly, un massimo di salti per riga e una modalità traccia o riempimento per riga. Gli alias legacy che il paradigma New-N ha sostituito non sono onorati, di proposito. |
Ruolo di digipeater di riempimento (domestico) |
✅ |
Un singolo interruttore limita la stazione alle righe a salto singolo, che è la configurazione corretta per un digipeater domestico al servizio delle stazioni che non raggiungono quello ad ampio raggio. |
Trappola sul conteggio dei salti |
✅ |
Un conteggio di salti superiore al massimo della riga corrispondente viene limitato e ripetuto oppure scartato, a scelta dell’operatore, con lo scarto contato sotto la sua motivazione nel pannello. |
Soppressione dei duplicati |
✅ |
Una cache condivisa con profondità e finestra temporale configurabili, usata sia dal digipeater sia dal gateway, così una trama non può essere ripetuta da un percorso dopo che l’altro l’ha già vista. Un unico interruttore nella pagina IGate la disattiva per entrambi. |
Digipeating preventivo |
✅ |
Spento per impostazione predefinita e selezionabile in due modalità indicatrici: gli indirizzi saltati vengono mantenuti e marcati come usati, oppure scartati così che esca solo ciò che resta da fare. La scansione va dal primo indirizzo inutilizzato fino alla fine del percorso e reclama solo un’identità fissa, quindi entrambe le esclusioni enunciate dalla proposta - gli alias n-N generici e un alias scritto con un conteggio di salti - sono garantite per costruzione. |
Instradamento legacy tramite SSID di destinazione |
✅ |
Disponibile dietro un interruttore spento per impostazione predefinita. Quando è spento, un pacchetto che usa quella convenzione ricade sulla logica del percorso esplicito invece di essere scartato. |
Segnalazione di precedenza e di operatore presente con i bit RR |
❌ |
Le proposte che riutilizzano i bit riservati dell’ottetto SSID non sono implementate in nessuna delle due direzioni. La modalità di marcatura del digipeating preventivo accende il bit riservato basso sugli indirizzi che salta, ma la trama viene ricodificata dalla sua rappresentazione TNC2, che non porta quei bit sul canale. |
Gateway APRS-IS#
Funzione APRS |
Stato |
Note |
|---|---|---|
Accesso e identificazione del software |
✅ |
La riga di accesso porta il nominativo, il passcode, il nome e la versione del software, e il filtro lato server solo quando ne è configurato uno: la parola chiave di filtro nuda senza argomento non viene mai inviata. |
Identità di accesso |
✅ |
La stazione accede con il proprio nominativo-SSID, la stessa identità che i suoi pacchetti portano come sorgente e la stessa che segue il costrutto q sulle trame instradate, scritta in un unico punto perché le tre non possano divergere. È l’indirizzo a cui va inviato un messaggio da APRS-IS, dato che il server confronta il destinatario con l’accesso in modo esatto. |
Percorso del traffico originato localmente |
✅ |
Tutto ciò che questa stazione immette da sé in APRS-IS porta |
Gateway da RF a internet |
✅ |
Caselle di gateway per tipo, un filtro di distanza attorno alla stazione, filtri di prefisso di nominativo e lista nera, e un elenco di gateway satellitare per stazioni udite tramite digipeater spaziali. |
q-construct per stazione |
✅ |
Il gateway sceglie fra i due costrutti di ricezione per stazione sorgente e non con un flag globale, così una stazione a cui questo gateway non consegnerebbe un messaggio viene marcata come tale, che è esattamente ciò che il costrutto significa. |
Gateway da internet a RF |
✅ |
Una maschera configurabile decide quali categorie possono attraversare, e i messaggi devono inoltre soddisfare le tre condizioni stabilite dalla documentazione dei gateway, seguite dal pacchetto di posizione della stazione destinataria. |
Validazione del filtro lato server |
✅ |
La stringa di filtro viene controllata grammaticalmente prima dell’invio — forma del termine e tipo di argomento — mentre l’intervallo e la sensatezza dei valori sono lasciati al server, che è l’autorità. |
Commutazione fra server |
✅ |
Quattro slot di server con riconnessione automatica. La rotazione avanza ogni volta che il server selezionato smette di sostenere la stazione — una connessione che non si stabilisce, una sessione che il server chiude, un errore di ricezione o un collegamento che resta muto oltre il timer di collegamento morto — quindi un server in manutenzione viene lasciato indietro invece di trattenere la stazione. Le chiusure richieste dalla stazione stessa, come il salvataggio della pagina, mantengono lo slot corrente. |
Riepilogo#
Contando le righe precedenti: la stazione implementa per intero il nucleo di
posizione, oggetti, messaggi, interrogazioni e stato del protocollo, in
entrambe le direzioni, più i due ruoli di rete (digipeater e IGate) e le
aggiunte successive al 2000 che contano di più nel traffico quotidiano —
posizioni compresse, !DAO!, Mic-E con identificazione dell’apparato, il
campo di frequenza, Reply-ACK, telemetria base-91 nel commento e il paradigma
New-N.
Le lacune si concentrano in tre punti, e vale la pena dirlo chiaramente:
Ampiezza in ricezione. La stazione trasmette più formati di quanti ne decodifichi. I record meteorologici grezzi Peet Bros e Ultimeter sono riconosciuti come categoria — quanto basta per farli passare attraverso i filtri di gateway — ma il loro contenuto non viene mai analizzato. In un IGate questo si manifesta come stazioni che superano il filtro di tipo ma le cui misure non sono disponibili localmente.
Proposte successive al 2004. Manca la proposta di segnalazione con i bit RR, mentre le sonde PHGR sono supportate. Sono aggiunte reali alla specifica, non folclore, ma la loro diffusione sul campo è disomogenea. Il digipeating preventivo, il più rilevante del gruppo, è implementato e spento per impostazione predefinita.
Formati senza sorgente locale. I dati di tempesta, i bollettini NWS e i radiogrammi NTS sono, per una stazione di questo tipo, questioni di puro trasporto: il firmware non ha da dove ricavare quelle informazioni. Sono elencati per completezza, e il comportamento sensato — ritrasmetterli intatti — è già quello attuale.
Nessuna delle righe ❌ impedisce alla stazione di operare come IGate, digipeater, tracker, stazione meteo o di telemetria pienamente conforme.