Nach einer Reihe von Diskussionen zeichnet sich nunmehr bei den Sysops der Digipeater in DL die Bereitschaft zur Umstellung auf das neue New n-Paradigma von Bob Bruninga (WB4APR) ab. Bitte lesen Sie zum Verständnis zunächst die sehr schöne einführende Übersetzung des New n-N - Paradigm von Lukas (DO7VLR).
Ergänzend sei noch angemerkt, dass nicht nur die Frequenzentlastung, sondern auch die (dann mögliche) Verbreitung lokaler Informationen ein integraler Bestandteil von NEWn-N ist. So können beispielsweise Informationen zu lokalen Sprach-Digipeatern oder Echolink-Gateways durch die Digipeater an durchreisende Mobilstationen in Echtzeit übertragen werden. Vgl. hierzu: "APRS Local Repeater Info Initiative"
Der von Bruninga im ursprünglichen "New-EU Paradigm" vorgeschlagene Weg in Europa maßgeblich auf die Einsicht der Nutzer zu setzen hat sich auch für ihn nicht als durchschlagend erwiesen. Insofern schlagen wir vor, dem modifizierten New-EU-Paradigm (welches dem US-Amerikanischen NEWn-N entspricht) zu folgen.
Insofern setzen wir weitestgehend auf die Umsetzung des NEWn-N-Konzeptes :
Die folgenden Darstellungen stellen Hinweise für Sysops zur Parametrierung der Digipeater dar. Aufgrund von Anregungen, soll nach der Beschlusslage auf dem 2.APRS-DL-Treffen die
Wir bitten alle verantwortlichen Betreiber von Digipeatern nunmehr mit Umstellung entsprechend der nachfolgenden Parametrierungsvorschläge zu beginnen. Bei eventuellen Pfadkürzungen sollte nach der regionalen Verkehrsdichte entschieden werden :
Für die Nutzer ist es ausgesprochen sinnvoll den Sende- und Empfangsradius eines Digipeaters zu erfahren. Zudem kann hierdurch die Versorgungsgüte eines Gebietes ermittelt werden. Insofern sollten Digipeater grundsätzlich ihre PHG(D)-Parameter oder den "RadioRange" im Feld "Data Extensions" übertragen (vgl. Appendix 1, TAPR APRS Protocol Reference v. 1.0, S. 94). Zu den Einzelheiten siehe bitte den Text von DL1MH. Der PHG-Wert kann hier online bestimmt werden.
Beispiel für Bake mit PHG(D):
"!4900.05N100823.29E#PHG2230/W1 Kommentar" Anzeige:
Zur Kennzeichnung der Digipeaterfunktionalitäten sollten nunmehr folgende Overlays verwendet werden:
Wegen der Verwendung von Overlays muss das Symbol für den Digi aus der sekundären Symboltabelle gewählt werden. Für den Stern also das "#" -Zeichen.
Beispiel einer kompletten Fill-In-Digi-Bake:
!4900.05N100823.29E#PHG2230/W1-1 Digi Karlsruhe
UIDIGI:
Konfigurationsfile für UI-DIGI-ROM (Version 1.9 BETA 3). Bitte Mycall, Password, Position und PHG anpassen.
TM-D700:
UIDIGI:
Pfadersetzung:
Im Rahmen der Implementierung der APRS4R-IGate/Digipieater-Software haben wir (DO5MC, DL1LJ) uns Gedanken zur Umsetzung des New n-N- Paradigmas in DL gemacht.
Kritik:
Auf verschiedenen APRS-Treffen und im Internet wurden die Konzepte zur Implementierung des New n-N Paradigmas in APRS4R vorgestellt und kontrovers diskutiert. Aus den für uns nachvollziehbaren Kritikpunkten haben wir Konsequenzen für die Implementierung abgeleitet und insofern das ursprüngliche Paradigma modifiziert bzw. abgeschwächt. Die wesentlichen von einzelnen OM vorgebrachten Punkte sind:
1. Umsetzungs- / Übergangsfrist für New n-N
Implementierung: generische Modifikationen erforderlich, wird in APRS4R umgesetzt.
2. Keine Entmündigung von OM bei bewußter Entscheidung für lange Pfade
Implementierung: Einbeziehung einen Keywords "RFONLY" bei dem Modifikation von Pfaden unterbleibt.
3. Kennzeichnung von Fill-In-Digipeatern
Implementierung: schon im Orginalvorschlag enthalten. Alternatives Symbol und Overlay "1".
Vorbedingungen :
Grundsätzlich soll es in New n-N jeder Pfad "traceable" werden und es aus Gründen der Vereinfachung nur noch WIDE n-N geben. Letzteres lässt sich aber für einen Übergangszeit nur bedingt umsetzen, wenn das System auch beim Einsatz von "alten" Digis traceable sein soll. Zudem sind eine Reihe von Erweiterungen des New n-N Paradigmas schon jetzt sinnvoll:
Umsetzung:
Die Umsetzung des von Bob Bruninga vorgeschlagenen NEWn-N Paradigmas, gliedert sich in der APRS4R-Software in drei weitgehend voneinander unabhängige Teile.
Pfadübersetzung:
Die Pfadübersetzung dient dazu, alle nicht mehr gültigen Rufzeichen (RELAY, WIDE, TRACE, TRACEn-N) in gültige Rufzeichen umzuwandeln, so dass diese weiterverarbeitet werden können.
Die nachfolgende Tabelle veranschaulicht die Umsetzungsregeln
Rufzeichen (alt) | Stelle im Pfad | Rufzeichen (neu) | Anmerkungen |
RELAY | 1. RELAY | WIDE1-1 | Umsetzung WIDE1-1 Paradigma |
RELAY | sonst | WIDE2-1 | kein Ansprechen von Fill-In-Digis |
WIDE | egal | WIDE2-1 | |
WIDE1-1 | 1. WIDE1-1 | WIDE1-1 | keine Umsetzung |
WIDE1-1 | sonst | WIDE2-1 | kein Ansprechen von Fill-In-Digis |
TRACE | egal | WIDE2-1 | übergangsweise TRACE2-1 |
TRACEn-m | egal | WIDEn-m | übergangsweise TRACEn-m |
Übergangsweise wird nach der eigentlichen Umsetzung alter Rufzeichen eine weitere Umsetzung durchgeführt. Dabei werden alle WIDEn-m, die nach einem TRACEn-m stehen, durch ein identisches TRACEn-m ersetzt. Diese Umsetzung ist nur von temporärer Natur, da TRACEn-m nur in der Übergangszeit unterstützt wird, sind alle Digipeater auf NewN-n umgestellt, erbringt WIDEn-m die gleiche Funktion wie bisher TRACEn-m.
Pfadoptimierung :Die Pfadoptimierung dient dem Zusammenfassen von WIDE-Rufzeichen, so dass dadurch die Anzahl der WIDE-Rufzeichen und somit die Länge des Pfades reduziert werden kann. So können beispielsweise zwei aufeinanderfolgende WIDEn-N-Rufzeichen zusammengefasst werden, sofern die Summe der verbliebenen Hops 7 nicht überschreitet.
Pfad (alt) | Pfad (neu) | Anmerkungen |
WIDE1-1,WIDE2-1,WIDE2-1 | WIDE1-1,WIDE2-2 | WIDE1-1 erhalten, Rest zusammengefasst |
WIDE1-1,WIDE2-1,WIDE5-5,TRACE2-2 | WIDE1-1,WIDE6-6,TRACE2-2 | WIDEn-Ns zusammengefasst, TRACEn-N erhalten |
WIDE1-1,WIDE2-2,WIDE2-2,WIDE4-4 | WIDE1-1,WIDE4-4,WIDE4-4 | WIDE2-2s zusammengefasst, keine weitere Reduzierung |
WIDE1-1,WIDE2-2,TRACE5-5,TRACE4-4 | WIDE1-1,WIDE2-2,TRACE5-5,TRACE4-4 | WIDE4-4 wurde in TRACE4-4 umgewandelt |
Pfadkürzung:
Die abschließende Pfadkürzung soll überlange Pfade von APRS-Nachrichten vermeiden. Abhängig von der lokalen Konfiguration werden dabei solange Hops aus dem Pfad entfernt, bis die gewünschte Hop-Anzahl erreicht ist. Die Reduzierung der Hop-Anzahl beginnt dabei direkt nach dem ersten Hop, welcher im Anschluss vom Digipeater selbst verbraucht wird. Die Pfadkürzung wird jedoch nur vorgenommen, wenn das Rufzeichen RFONLY nicht im Pfad vorhanden ist.
Pfad (alt) | Hops (alt) | Pfad (neu) | Hops (neu) | Anmerkungen |
WIDE1-1,WIDE7-7 | 8 | WIDE1-1,WIDE2-2 | 3 | Kuerzung um 5 Hops |
WIDE1-1,WIDE3-3,WIDE4-4 | 9 | WIDE1-1,WIDE2-2 | 3 | WIDE3-3 vollstaendig aufgebraucht |
WIDE1-1,WIDE2-2,TRACE5-5,TRACE4-4 | 11 | WIDE1-1,TRACE2-2 | 3 | WIDE2-2 und TRACE5-5 aufgebraucht |
Beispiel:
Ein APRS4R-Digipeater empfängt nachfolgende APRS-Nachricht
SOURCE,DEST>RELAY,RELAY,WIDE,WIDE,WIDE5-5,TRACE5-5,WIDE4-4>Dies ist eine Testbake
Im ersten Schritt (Pfadübersetzung) werden die ungültigen Rufzeichen RELAY,WIDE übersetzt. Übergangsweise wird das Rufzeichen TRACE5-5 nicht ersetzt. Ausserdem wird das WIDE4-4 uebergangsweise in ein TRACE4-4 umgewandelt. Das Resultat sieht dann wie folgt aus.
SOURCE,DEST>WIDE1-1,WIDE2-1,WIDE2-1,WIDE2-1,WIDE5-5,TRACE5-5,TRACE4-4>Dies ist eine Testbake
Anschließend wird im zweiten Schritt (Pfadoptimierung) versucht, die Anzahl der Pfadbestandteile zu reduzieren. Dazu werden, sofern möglich, kleine WIDEn-N Rufzeichen zusammengefasst.
SOURCE,DEST>WIDE1-1,WIDE3-3,WIDE5-5,TRACE5-5,TRACE4-4>Dies ist eine Testbake
Im letzten Schritt der Vorverarbeitung einer APRS-Nachricht wird, wenn aktiviert, eine Pfadkürzung vorgenommen. Im vorliegenden Fall sind insgesamt 18 Hops im Pfad enthalten. Da der Digipeater selbst einen Hop verbraucht, müssen also 13 Hops entfernt, wenn nach dem Aussenden noch 2 Hops verfügbar sein sollen. Die Hops werden hinter dem ersten nicht verbrauchten Hop entfernt. Dabei werden WIDEn-N-Rufzeichen aus dem Pfad entfernt, wenn diese vollständig verbraucht sind. Für das vorliegende Beispiel würde die Kürzung folgendes Resultat erbringen.
SOURCE,DEST>WIDE1-1,TRACE2-2>Dies ist eine Testbake
Da sowohl WIDE3-3, als auch WIDE5-5 und TRACE5-5 vollständig aufgebraucht wurden, wurden diese Rufzeichen sofort aus dem Pfad entfernt. Das verbleibene Rufzeichen TRACE4-4 wurde auf TRACE2-2 reduziert. Somit kann die APRS-Nachricht noch über zwei weitere Hops nach dem Aussenden verbreitet werden.
Als wesentlicher Mehrwert stellt sich die Abstrahlung lokaler Informationen beispielsweise zu Sprach-Relays dar. Durchreisende Mobilstationen sind sodann unmittelbar über die aktuellen örtlichen Repeater-Frequenzen unterichtet. Hierzu senden die APRS-Digipeater Objekt-Baken in dem folgenden Format aus, welche im den Display-Feldern des TM-D700 und TH-D7 problemlos angezeigt werden können. Vgl. umfassend: "APRS Local Repeater Info Initiative"
Objekt-String im Bakentext (BT in UIDIGI):
;FFF.FFF+x*111111zDDMM.hhN/DDDMM.hhWrAAAAAAAAAABBBBBBBBBB88888888....
Objekt:
Nutzlast:
AAAAAAAAAA, BBBBBBBBBB, 88888888 sind die 10x10x8 Textfelder des TH-D7 (20 Byte sichtbar) TM-D700 (28 Byte sichtbar):
26.06.2007 DL1LJ/DO5MC
28.07.2007 DL1LJ
23.09.2007, DL1MH