Domanda:
APRS: WIDEn-N vs. TRACEn-N
Georg DO1GL
2013-10-28 15:58:11 UTC
view on stackexchange narkive permalink

Il percorso digipeater APRS suggerito è WIDE1-1, WIDE2-1 per la maggior parte dei casi d'uso. Secondo le specifiche, questo assicura due ritrasmissioni da parte di digipeater di riempimento / regolari attorno al mittente, senza che i digipeater aggiungano il proprio nominativo al percorso.

Il percorso TRACEn-N , al contrario, ha lo scopo di consentire ai digipeater di inserire il proprio nominativo durante l'inoltro. Tuttavia, nonostante l'uso di WIDEn-N , vedo uno o più digipeater nel percorso della maggior parte dei pacchetti.

Esistono ancora casi d'uso validi per TRACEn-N ? Un pacchetto TRACEn-N avrà la stessa copertura di un pacchetto WIDEn-N ?

Una risposta:
#1
+5
oh7lzb
2013-10-28 16:52:56 UTC
view on stackexchange narkive permalink

In realtà, le specifiche attuali incoraggiano o richiedono che i digipeater aggiungano i loro nominativi al percorso WIDEn-N, poiché l'inclusione dei nominativi aiuta enormemente a trovare e risolvere tutti i tipi di problemi di rete (cerca "tracciabile" in la pagina). WIDE1-1 è spesso sostituito dal nominativo di un digipeater stupido, WIDE2-1 è solitamente preceduto dal nominativo di un digipeater.

TRACEn-N è spesso utile per la diagnostica. Molte aree hanno ancora digipeater obsoleti in uso, che non aggiungono i propri nominativi al WIDEn-N path, e questi digipeater spesso aggiungono il loro nominativo ai percorsi TRACEn-N . Quindi qualcuno potrebbe voler usare temporaneamente TRACEn-N per vedere quali digipeater stanno ritrasmettendo i tuoi pacchetti. Se tutti i digipeater nella tua zona sono già stati aggiornati per rendere WIDEn-N tracciabile, non dovrebbe fare molta differenza.

A meno che non ci sia un digipeater che ignora completamente Pacchetti TRACEn-N nella tua zona (sarebbe sorprendente), dovrebbe avere la stessa copertura .

La premessa di pochi nominativi digipeater nel percorso del pacchetto non hanno un effetto pratico significativo sul tempo / dimensione della trasmissione, poiché ogni coppia nominativo-SSID è lunga solo 7 byte (56 bit - 6 byte per nominativo, più un byte per SSID come numero intero), che a 1200 bit / s richiede 46,7 ms inviare. Kenwood TH-D72 ha un'impostazione predefinita di txdelay di 300 millisecondi, che a 1200 bit al secondo attribuisce già a 360 bit di "spreco" all'inizio di ogni trasmissione. Altre radio e tracker hanno impostazioni predefinite simili e talvolta più lunghe per txdelay, anche fino a 500 ms. E poi c'è il contenuto effettivo del pacchetto, che spesso è molto lungo con coordinate non compresse e testi di commento dettagliati.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...