Duplicate and Delayed Packets in APRS.FI : Duplicate and Position Packets which arrive in the wrong order. Solutions.

Onderstaande is gedeeltelijk eerder geplaatst in zendamateur.com ( onder DIGITALE MODI ) en in het ON0LB forum ( onder APRS ). Voor een schoonheidsprijs zal de pagina nooit in aanmerking komen, deze is uitsluitend gemaakt om een antwoord te geven op steeds weer terugkerende vragen en om sommige actuele zaken binnen het APRS gebeuren op een rijtje te kunnen zetten.

Voor hun die een Digi en I-Gate willen gaan runnen en nog niet bekend zijn met het genoemde verschijnsel ( titel ) is deze link bedoeld, zie hier.

Onder andere vindt men er dit : The visible effect of delayed packets.

A packet transmitted from a moving car 64 seconds ago might arrive at aprs.fi later than a packet that was transmitted 4 seconds ago. If the car was moving at 100 km/h (27.8 m/s, 62 MPH), and that packet would go unnoticed and would be stored to the database as the latest good position, the car would suddenly jump back 1.6 km on it's track. When the next packet would be received, it'd quickly jump forward to it's current position. Without additional filtering the above scenario is met very often, and it looks very ugly on the map. The hard part filtering the old packets and duplicates without losing too much valid data.

Vrij vertaald in het Nederlands : Het zichtbare effect van vertraagde packets.

Een baken, bijvoorbeeld 64 seconden geleden uitgezonden door een bewegende auto, zou bij aprs.fi later kunnen aankomen dan een packet, dat pas 4 seconden geleden verzonden is. Stel, de auto bewoog zich voort met 100 km/h ( 27.8 m/s, 62 MPH ), en het ( 64 seconden geleden ) packet wordt opgeslagen in het gegevensbestand als het meest recente, dan zal de auto plotseling 1.6 km 'terug springen'. Wanneer dan het volgende packet wordt ontvangen, springt het symbooltje op de kaart snel vooruit naar de huidige positie. Zonder extra filtering treedt het bovengenoemde scenario vaak op, en het ziet er helemaal niet goed uit op de kaart. Het filteren haalt de oude packets en 'duplicates' weg zonder al te veel verlies van data.

HET VOORKOMEN VAN DUPLICATE AND DELAYED PACKETS

1 - Mobiele stations gebruiken WIDE1-1,WIDE2-1 ( goed : 2 hops ) of WIDE1-1,WIDE2-2 ( 3 hops ). Soms zie je ook WIDE2-2 ( 2 hops ) daar waar geen assistentie verlangd wordt van home stations. In een gebied, waarin zich digi's bevinden met een ( zeer ) grote reikwijdte, gebruiken mobiele stations een aangepast pad, bijvoorbeeld WIDE2-1. Hierover later meer.

2 - I-Gates dienen onder normale omstandigheden andere waarden dan hierboven te blokkeren, zie hieronder.

3 - UI-View32 Digipeaters zijn van het type New Style, onder meer is er de W2 A.P.T. SSn-N uitvoering, zie hieronder.

2 - Indien je UI-View32 gebruikt dan kun je, om dit te bereiken, in de IGATE.INI file de regel NOGATE=NOGATE,RFONLY wijzigen in : NOGATE=NOGATE,RFONLY,RELAY,TRACE,WIDE3,WIDE4,WIDE5,WIDE6,WIDE7 Het betreft verboden en minder gewenste waarden. Als nu een mobiel station zo'n waarde voert, zal de I-Gate deze simpelweg blokkeren waardoor het probleem ten gevolge van het ontstaan van duplicate and delayed packets zal kunnen verminderen. Merk op dat ook RELAY geblokt wordt.

3 - Betreffende de UI-View32 APRS New Style Digipeaters, inclusief de uitvoering met Abusive Path Trapping ( A.P.T. ) zijn de instellingen in het kader van bovenstaande belangrijk. Met name de W2 A.P.T. SSn-N Digipeater * helpt mee het probleem te voorkomen ! De benodigde instellingen vind je makkelijk via een piepklein javascriptje, zie hier ( kies de N1 configuratie voor UI-View32, N staat in dit geval voor New-N Paradigm ). Het betreft het [DIGI_OPTIONS] blokje in de Uiview32.INI file ((-,O))

* de A.P.T. digi blokkeert het packet met een te lang pad niet zonder meer zoals de I-Gate ( indien van toepassing ). Maar zendt het op de werkfrequentie nog eenmaal uit, meestal zonder het betreffende WIDE statement, of in gewijzigde vorm. Andere digi's doen er dan niets mee. Vandaar de term trapping ..

De A.P.T. digi draagt bij aan het verbeteren van het netwerk. Het doorgeven van packets met ongewenste, te hoge waarden in de WIDE statements wordt voorkomen. Daardoor vermindert de kans op het ontstaan van duplicates en andere zaken in niet geringe mate. Een voorbeeldje ( niet verplicht tot lezen hi, kan echter verhelderend werken ) :

met WIDE3-3 ziet het er voor dit type digipeater zo uit :

18:28:47R DB0KX-2>APNU19,NOCALL-2*,WIDE3-3 Port=1 <UI C Len=59>:
!5116.94NN00620.84E#PHG2110/APRS-DIGI VFDB/DARC DOK:Z59/R02
18:28:47T DB0KX-2>APNU19,NOCALL-2*,PC1L-2* Port=1 <UI C Len=59>:
!5116.94NN00620.84E#PHG2110/APRS-DIGI VFDB/DARC DOK:Z59/R02

de ( W2 A.P.T. ) digi PC1L-2 zet het WIDE3-3 dus niet om in WIDE3-2 en zendt het WIDE statement zelfs helemaal niet meer uit. Dus ook geen WIDE3*. Duidelijk is te zien dat het baken wel ( her ) uitgezonden wordt .. Indien het een statement betreft waarbij N = 1 ( WIDEn-N ), bijvoorbeeld WIDE3-1, dan wordt dit als WIDE3* nog eenmaal meegezonden ..

18:28:47R DB0KX-2>APNU19,NOCALL-2*,WIDE3-1 Port=1 <UI C Len=59>:
!5116.94NN00620.84E#PHG2110/APRS-DIGI VFDB/DARC DOK:Z59/R02
18:28:47T DB0KX-2>APNU19,NOCALL-2*,PC1L-2*,WIDE3* Port=1 <UI C Len=59>:
!5116.94NN00620.84E#PHG2110/APRS-DIGI VFDB/DARC DOK:Z59/R02

met WIDE2-2 ziet het er zo uit :

12:03:53R PD1AJJ-7>UP5YV3,WIDE1*,WIDE2-2 Port=1 <UI R Len=42>:
`{K-pg|<\`"4M}Peter op pad met de VX8e _
12:03:53T PD1AJJ-7>UP5YV3,WIDE1*,PC1L-2*,WIDE2-1 Port=1 <UI R Len=42>:
`{K-pg|<\`"4M}Peter op pad met de VX8e _

een andere digi zal ( vanwege het WIDE2-1 ) dan nog eenmaal verder kunnen geven .. ( met WIDE2* ) ..

zoals hierboven al te zien is, heb ik de digi zodanig ingesteld ( volgens de N1 configuratie, al eerder op deze pagina genoemd ) dat een baken met WIDEn-N waarbij N = 1 ( bijvoorbeeld WIDE5-1 ) nog eenmaal met WIDEn* ( in dit voorbeeldje dus met WIDE5* ) verder gegeven wordt .. verklaring : WIDE5-1 is nog een hop te gaan ( net zoals bijvoorbeeld WIDE3-1 of WIDE7-1 ), en kan men als toegestaan beschouwen .. het WIDEn* is daarom ( zichtbaar ) aanwezig in de laatste uitzending, ook al doet een volgende digi er niets meer mee

een ander, geldig statement in een gedeeltelijk fout pad wordt, wederom in tegenstelling tot bij de I-Gate, meestal intact gelaten en doorgegeven .. de digi zal een pad met NLn-N ( waarin bijvoorbeeld n = 2, N = 2, toegestane waarden ) en WIDEn-N ( waarin bijvoorbeeld n = 5, N = 1, toegestane waarden ) zo verder geven : WIDEn*,NLn-N .. echter met WIDEn-N ( waarin n = 5, N > 1, niet toegestane waarden ) : NLn-N ..

NL2-2, in bijvoorbeeld WIDE5-1,NL2-2 => de digi geeft WIDE5*,NL2-2
NL2-2, in bijvoorbeeld WIDE5-2,NL2-2 => de digi geeft NL2-2

worden er zaken als RELAY, TRACE en WIDE zonder n-N aangetroffen dan wordt dit gehonoreerd met volledige stop, ook het NL2-2 in bovenstaand voorbeeld wordt niet meer uitgezonden, zelfs het baken niet meer : trapped .. in dubbel opzicht

NL2-2, in bijvoorbeeld WIDE,NL2-2 => de digi zendt niet uit ..

NOGMAALS DE INSTELLINGEN VOOR MOBIELE STATIONS

RELAY, WIDEn-N en TRACEn-N zijn vervangen door WIDEn-N ( dat nu onder TRACE valt, het vroegere WIDEn-N viel onder FLOOD, het werd wel non traceable of flooding WIDE genoemd ). Het 'nieuwe' SSn-N valt nu onder FLOOD ( zie ook verder naar beneden voor enige uitleg ). Mobiele stations hoeven alleen nog maar WIDEn-N en eventueel SSn-N in hun pad te zetten. De ( goed geconfigureerde ) digi doet de rest.

Vul de juiste waarden in ( er zijn steeds meer digi's die alles stop leggen, als het niet goed is ) ! Zie hieronder.

1 - indien assistentie gewenst door fill-in ( type home ) digi's en WIDEn-N digi's : gebruik WIDE1-1,WIDE2-1 ( gebruik niet enkel WIDE2-2 dat ook 2 hops oplevert ). Of WIDE1-1,WIDE2-2 ( 3 hops ). Hoe dan ook, zelfs al is er geen fill-in digi beschikbaar dan is het pad toch compatible met de andere digi's, de WIDEn-N uitvoeringen.

2 - indien uitsluitend assistentie gewenst door WIDEn-N digi's : gebruik WIDE2-1 ( 1 hop ) of WIDE2-2 ( 2 hops ) ..

3 - gebruik geen combinatie als : RELAY,WIDE2-1 of RELAY,WIDE2-2 onder het motto als het ene ( RELAY ) niet kan dan maar het andere ( WIDE ) in dat pad ..... zorg dat RELAY niet in het pad voorkomt ( de combinatie kan hoe dan ook verloren raken .. ), vervang het desgewenst door WIDE1-1 ! Voor KF-163 gebruikers : zie hier ..

4 - plaats nooit RELAY of WIDE1-1 na WIDE ( bijvoorbeeld WIDE2-2, RELAY ) .. altijd vooraan de regel plaatsen !

Met betrekking tot de punten 3 en 4 vestig ik hierbij aandacht op het uitermate interessante Proportional Pathing ( standaard ingebouwd in de tracker software voor de KF-163 .. ). Het betreft reeksen van bakens met een steeds wijzigend digipad waarin soms nog RELAY kan voorkomen. Dit is desgewenst zeer eenvoudig te verwijderen. Ook kan er een 'vast' pad ingesteld worden .....

5 - gebruik geen waarden als WIDE3-3 of WIDE4-4 of nog hoger in het pad ! Er zijn ( noodzakelijkerwijze ) meer en meer smart digi's met Abusive Path Trapping : weg digipeat in zo'n geval ..

6- indien assistentie gewenst door een S digi zet dan SSn-N ( State Systems ) in het pad waarbij je SS vervangt door NL ( nederland ) of bijvoorbeeld BE ( belgie ). Gebruik je deze instelling in nederland dan kun je eens kijken wat NL2-2 zal doen. Plaats dit aan het eind van de regel. Nogmaals ( de instellingen van de digi betreffende, ook met betrekking tot SSn-N ) de verwijzing naar de link van het scriptje dat deze zaken regelt ( [DIGI_OPTIONS] in de Ui-view32.INI file ), zie hier. Opmerking : de S ( in S digi ) betreft het overlay. Daardoor herken je dit type digi makkelijk. Er is een S te zien in een gele vijfpuntige ster.

DIGIPEATEN VAN MOBIELE STATIONS MET TRACEABLE WIDE : INSERTED DIGI CALLSIGNS

Hier zeer in het kort nog iets over het digipeaten van een mobiel station met in het pad :

1 - WIDE1-1,WIDE2-2

Origineel packet : PC1L-9 to APRXQ via WIDE1-1,WIDE2-2
Door PC1L-2 uitgezonden packet : PC1L-9 to APRXQ via PC1L-2,WIDE1*,WIDE2-2
Door volgende digipeater ( PA3GKF-2 ) uitgezonden packet : PC1L-9 to APRXQ via PC1L-2,WIDE1*,PA3GKF-2,WIDE2-1

WIDEn-N valt onder het TRACE proces, er is een toevoeging ( insertion ) van de callsign van het digipeatende station.

2 - WIDE1-1,NL2-2

Origineel packet : PC1L-9 to APRXQ via WIDE1-1,NL2-2
Door PC1L-2 uitgezonden packet : PC1L-9 to APRXQ via PC1L-2,WIDE1*,NL2-2
Door volgende digipeater ( PA3GKF-2 ) uitgezonden packet : PC1L-9 to APRXQ via PC1L-2,WIDE1*,NL2-1

NLn-N valt onder het FLOOD proces, er is geen toevoeging ( insertion ) van de callsign van het digipeatende station.

Vanwege de drie hops, mogelijk gemaakt door de waarden in de hierboven behandelde paden, kunnen er al behoorlijke afstanden overbrugd worden. Het is niet moeilijk in te zien dat bij nog meer hops de kans op duplicates en delayed packets aanzienlijk toeneemt. Bij waarden als WIDE3-3 en zeker daarboven zie je in aprs.fi ( ruw : raw data check hier, vul de callsign in ) soms rood verschijnen.

Meer in detail, het pad en het digipeaten in de praktijk, zie verder naar beneden ( hoe het er kan uitzien op een monitor ).

Te adviseren paden ( vanaf 2011 ) voor mobiele stations :

1 - WIDE1-1,WIDE2-1 of WIDE2-2 ( zie ook 3 ) waarbij het eerste pad bovendien assistentie van fill-in digi's mogelijk maakt.
2 - WIDE1-1,NL2-2 assistentie mogelijk door fill-in en S digi's.
3 - WIDE2-1 of WIDE2-2 assistentie mogelijk in gebieden met New Style digi's met een ( zeer ) groot bereik ( high-level digi's ) *.
4 - NOGATE toegevoegd ( bijvoorbeeld WIDE2-2,NOGATE ) : als boven maar I-Gates zetten ( meestal ) niets op internet *.

* merk op dat WIDE2-1 net als WIDE1-1 slechts een hop oplevert maar een fill-in digi doet niets met WIDE2-1.
* een correct geconfigureerde UI-View32 I-Gate zal met NOGATE ( of RFONLY ) in een pad helemaal niets doorgeven. Let op ! Voor RELAY, TRACE of WIDEn-N ( n > 2 ) hetzelfde verhaal. Een eventueel geldig statement in dat pad wordt eveneens tegengehouden.

Met betrekking tot de laatste vier regels : uitsluitend bestemd voor sysops, bedoeld als overdenking. Het is zeer eenvoudig om in UI-View32 WIDE of SS ( NL ) te vervangen door AIR, indien gewenst. Verder : merk op dat kolom 2 valt onder TRACE en kolom 3 onder FLOOD .. hieronder meer.

DE GROOTHEDEN TRACE EN FLOOD ( UITRACE EN UIFLOOD IN UI-VIEW32 )

Nog iets over TRACE en FLOOD. Voor sommigen kennelijk niet helemaal duidelijk. Deze processen zijn actief in de digipeater zelf en handelen het ingestelde pad van een ( mobiel ) station af. Onder de tabel meer erover.

Het beste kan men TRACE en FLOOD beschouwen als normale grootheden ( net zoals de grootheid lengte, met de daarbij behorende eenheid meter, de grootheid lengte wordt uitgedrukt in de eenheid meter ). Vroeger waren de daarbij behorende eenheden respectievelijk TRACE ( deze eenheid had dezelfde naam als de betreffende grootheid ) en WIDE ( deze eenheid had niet dezelfde naam als de betreffende grootheid ) .. nogal verwarrend .. Tegenwoordig, met de nieuwe afspraken, zijn de bijbehorende eenheden WIDE ( WIDEn-N ) en State Systems ( SSn-N ) geworden *, dus beide eenheden hebben nu een andere naam dan de betreffende grootheden.

* in de plaats van het vroegere non traceable WIDE ( flooding WIDE ) is het huidige traceable WIDE ( verhuisd van FLOOD naar TRACE ) gekomen en State Systems kwam onder het vrijgekomen FLOOD proces.

Wat doen TRACE en FLOOD ? Deze processen regelen het aftelmechanisme waarbij de waarde N ( in WIDEn-N of SSn-N ) met 1 verminderd zal zijn bij re-transmissie. Dus N wordt N-1. WIDE2-2 wordt WIDE2-1, WIDE3-3 wordt WIDE3-2 etcetera *. Bij het TRACE proces wordt bovendien de callsign ( en SSID, indien van toepassing ) van het digipeatende station toegevoegd ( trace : traceren ).

* met andere woorden, het resterend aantal potentiele hops, bepaald door de nummers ( N ) achter de WIDE en NL statements, wordt bij uitzenden met 1 verminderd.

Opmerking : RELAY ( in ALIAS ) werd WIDE1-1, een 'aparte' parameter.

HET PAD EN HET DIGIPEATEN IN DE PRAKTIJK : APRS.FI RAW PACKETS

Het heruitzenden van de packets. En hoe het er tenslotte uitziet op de monitor. Eerst nog even dit :

WIDE1-1,WIDE2-2 originele uitzending door een mobiel station

WIDE1-1*,WIDE2-2 heruitzending door een fill-in digi ( home station ) : de eerste hop

WIDE1*,WIDE2-2 heruitzending door een high-level digi : de eerste hop
WIDE1*,WIDE2-1 heruitzending door de volgende high-level digi : de tweede hop
WIDE1*,WIDE2* heruitzending door de laatste high-level digi : de derde hop

Hieronder dan enkele complete voorbeelden, hoe het er op een monitor kan uitzien ..... De groen gekleurde tekst kun je overslaan, deze betreft monitoring door PC1L met transmissie simulatie. Voor hun die het toch willen lezen : betreft een APRS UI-View32 New Style W2 WIDEn-N Abusive Path Trapping S ( SSn-N, State Systems ) digi met absolute RELAY block en X I-Gate ( experimenteel ) ..... altijd makkelijk om te weten hi.

Voorbeeld 1 : de eerste hop ( WIDE1-1 naar WIDE1* ) werd geregeld door een high-level digi. De laatste hop werd geregeld door PA3GKF-2 ( toegevoegde callsign ), alweer een high-level digi.

14:10:31R PD2OK-9>APERXQ,WIDE1*,WIDE2-1 Port=1 <UI Len=36>:
!5053.07N\00559.55Ev304/000/A=000438
14:10:31T PD2OK-9>APERXQ,WIDE1*,PC1L-2*,WIDE2* Port=1 <UI Len=36>:
!5053.07N\00559.55Ev304/000/A=000438
14:10:32R PD2OK-9>APERXQ,WIDE1*,PA3GKF-2*,WIDE2* Port=1 <UI Len=36>:
!5053.07N\00559.55Ev304/000/A=000438

aprs.fi raw packets :

2010-07-08 12:10:23 UTC: PD2OK-9>APERXQ,WIDE1-1,WIDE2-1,qAR,DB0SDA:!5053.07N\00559.55Ev304/000/A=000438

duidelijk is dat een hop door DB0SDA geregeld werd. PA3GKF-2 doet hoe dan ook de laatste hop ( WIDE2* ) .. merk op dat PC1L-2 ( monitoring, geen transmissie * ) exact dezelfde regel weergeeft.

* PA3GKF-2 kan PC1L-2 niet 'zien' en doet de laatste hop.

Opmerking ( niet lezen, tenzij geinteresseerd ) : zo ziet het op de ( eigen ) monitor uit indien PC1L-2 het WIDE1-1 afhandelt ..

11:52:41R PA2TA-9>UP3XR6,WIDE1-1,WIDE2-2 Port=1 <UI R Len=26>:
`{H<"S->/]"6y}431.275MHz=
11:52:41T PA2TA-9>UP3XR6,PC1L-2*,WIDE1*,WIDE2-2 Port=1 <UI R Len=26>:
`{H<"S->/]"6y}431.275MHz=

PC1L-2 is toegevoegd, vóór het WIDE1*,WIDE2-2

12:03:53R PD1AJJ-7>UP5YV3,WIDE1*,WIDE2-2 Port=1 <UI R Len=42>:
`{K-pg|<\`"4M}Peter op pad met de VX8e _
12:03:53T PD1AJJ-7>UP5YV3,WIDE1*,PC1L-2*,WIDE2-1 Port=1 <UI R Len=42>:
`{K-pg|<\`"4M}Peter op pad met de VX8e _

PC1L-2 is toegevoegd, na het WIDE1*, een andere digi heeft het WIDE1-1 al geregeld. Uit onderstaande ( aprs.fi ) blijkt dat dit ON9CC-2 is geweest. ON0BAF-4 doet in werkelijkheid de tweede hop.

2010-07-11 10:03:52 UTC: PD1AJJ-7>UP5YV3,WIDE1-1,WIDE2-2,qAR,ON9CC-2:`{K-pg|<\`"4M}Peter op pad met de VX8e _
2010-07-11 10:03:52 UTC: PD1AJJ-7>UP5YV3,WIDE1,WIDE2-2,qAR,ON0BAF-4:`{K-pg|<\`"4M}Peter op pad met de VX8e _

ON9CC-2 : WIDE1-1 wordt WIDE1* ( WIDE1 in aprs.fi ) ON0BAF-4 : WIDE2-2 wordt WIDE2-1

Voorbeeld 2 : een hop werd geregeld door DB0SDA, PC1L-2 regelt de laatste hop ( WIDE2* ), theoretisch natuurlijk, in verband met het niet QRV zijn.

14:08:28R PA1PLT>UQ1QW5,WIDE2-1 Port=1 <UI R Len=16>:
`{UEl-CY/]"4&}=
14:08:28R PA1PLT>UQ1QW5,DB0SDA*,WIDE2-1 Port=1 <UI Len=16>:
`{UEl-CY/]"4&}=
14:08:28T PA1PLT>UQ1QW5,DB0SDA*,PC1L-2*,WIDE2* Port=1 <UI Len=16>:
`{UEl-CY/]"4&}=

aprs.fi raw packets :

2010-07-08 12:08:17 UTC: PA1PLT>UQ1QW5,WIDE2-2,qAR,PI1EHV-6:`{UEl-CY/]"4&}=

duidelijk is dat een hop door PI1EHV-6 geregeld werd.

Voorbeeld 3 : onderstaande drie regels spreken voor zich. PA3GKF-2 regelt de laatste hop ( WIDE2* ).

14:26:48R ON6YYY-14>UP5RW7,ON0VRT*,WIDE2-1 Port=1 <UI R Len=27>:
`z+:l!=u/]"50}ON6YYY/M
14:26:48T ON6YYY-14>UP5RW7,ON0VRT*,PC1L-2*,WIDE2* Port=1 <UI R Len=27>:
`z+:l!=u/]"50}ON6YYY/M
14:26:51R ON6YYY-14>UP5RW7,ON0VRT*,PA3GKF-2*,WIDE2* Port=1 <UI R Len=27>:
`z+:l!=u/]"50}ON6YYY/M

aprs.fi raw packets :

2010-07-08 12:26:02 UTC: ON6YYY-14>UP5RW8,ON0VRT,WIDE2-2,qAR,ON0BAF-4:`z+9m!!u/]"5/}ON6YYY/M
2010-07-08 12:26:33 UTC: ON6YYY-14>UP5RW7,ON0VRT,WIDE2-2,qAR,ON0DAS-4:`z+:l!=u/]"50}ON6YYY/M
2010-07-08 12:27:05 UTC: ON6YYY-14>UP5RW7,ON0VRT*,WIDE2-2,qAR,ON0ANT:`z+:l!=u/]"5.}ON6YYY/M
2010-07-08 12:27:05 UTC: ON6YYY-14>UP5RW7,ON0VRT,WIDE2-2,qAR,ON0BAF-4:`z+:l!=u/]"5.}ON6YYY/M
2010-07-08 12:26:33 UTC: ON6YYY-14>UP5RW7,ON0VRT,WIDE2-2,qAR,ON0DAS-4:`z+:l!=u/]"50}ON6YYY/M
2010-07-08 12:27:05 UTC: ON6YYY-14>UP5RW7,ON0VRT*,WIDE2-2,qAR,ON0ANT:`z+:l!=u/]"5.}ON6YYY/M
2010-07-08 12:27:05 UTC: ON6YYY-14>UP5RW7,ON0VRT,WIDE2-2,qAR,ON0BAF-4:`z+:l!=u/]"5.}ON6YYY/M
2010-07-08 12:27:36 UTC: ON6YYY-14>UP5RW8,ON0VRT,WIDE2-2,qAR,ON0DAS-4:`z+:l!=u/]"57}ON6YYY/M
2010-07-08 12:28:08 UTC: ON6YYY-14>UP5RW7,ON0VRT*,WIDE2-2,qAR,ON0LN-10:`z+:l!=u/]"5/}ON6YYY/M
2010-07-08 12:28:40 UTC: ON6YYY-14>UP5RW7,ON0VRT,WIDE2-2,qAR,ON0BAF-4:`z+;l!=u/]"57}ON6YYY/M

interessante toestand hier, let op :

1 - de aprs.fi raw packets met UP5RW7 en `z+:l!=u/]"50} ( `z+:l!=u/]"50} betreft coordinaten in gecomprimeerde vorm ).
2 - de packets ertussen met UP5RW7 `z+:l!=u/]"5.} : vijf transmissies met WIDE2-2.

Voorbeeld 4 : de eerste hop ( WIDE1-1 naar WIDE1* ) werd geregeld door een high-level digi. De tweede hop werd geregeld door PA3GKF-2 ( toegevoegde callsign ). PC1L-2 doet ( theoretisch ) de derde en laatste hop ( WIDE2* ).

16:45:28R PD0MR-9>UP5QS0,WIDE1*,PA3GKF-2*,WIDE2-1 Port=1 <UI R Len=16>:
`{ElRK>/]"4H}=
16:45:28T PD0MR-9>UP5QS0,WIDE1*,PA3GKF-2*,PC1L-2*,WIDE2* Port=1 <UI R Len=16>:
`{ElRK>/]"4H}=

aprs.fi raw packets :

2010-07-09 14:45:15 UTC: PD0MR-9>UP5QS0,WIDE1-1,WIDE2-2,qAR,ON9CC-2:`{E<0x1d>lRK>/]"4H}=

uit bovenstaande regel mag blijken dat de bedoelde high-level digi ON9CC-2 is ..

APRS.FI RAW PACKETS : DUPLICATES

Nu duidelijk is hoe het er kan uitzien in aprs.fi ( raw packets ) nog een klassiek voorbeeld met een vliegtuig waarbij gemakkelijk duplicates ( en andere zaken ) kunnen ontstaan. Een APRS zender ( eventueel low power ) in een vliegtuig kan, afhankelijk van de hoogte, een enorm bereik hebben. De nodige digi's ontvangen de APRS signalen en het komt voor dat uiteindelijk sommige bakens vertraagd arriveren bij aprs.fi ..

DL8YF-7 in de D-KGFU op zondagmiddag 110710 :

DL8YF-7>APZAVR,ON0VRT*,WIDE2-1,qAR,ON7EQ:/111150z5039.22N/00628.00E'198/073/A=004400 10.0V Peer unterwegs in seinem Flugzeug, D-KGFU, zu hoeren auf 122.100 (AM) [Duplicate position packet]
2010-07-11 11:51:36 UTC: DL8YF-7>APZAVR,WIDE1-1,WIDE2-3,qAR,PI1EHV-6:/111151z5038.36N/00626.88E'240/068/A=004496 10.0V Peer unterwegs in seinem Flugzeug, D-KGFU, zu hoeren auf 122.100 (AM) [Location changes too fast (>500 km/h)]

BI2939 ( vliegend object ) op zondagmorgen en middag 180710 :

2010-07-18 10:19:03 UTC: BI2939>UQ1VY8,WIDE2-1,qAR,ON0DAS-4:`|a-pSb'/"@p}
2010-07-18 10:19:08 UTC: BI2939>UQ1VY6,WIDE2-1,qAR,PI1EHV-6:`|a6q4m'/"@t}
2010-07-18 10:19:14 UTC: BI2939>UQ1VY9,PI1EHV-2,WIDE2*,qAR,PI1EHV-6:`|a?q4H'/"@y}Juecke
2010-07-18 10:19:19 UTC: BI2939>UQ1WP7,WIDE2-1,qAR,ON0LN-10:`|a5q-''/"A$}
2010-07-18 10:19:24 UTC: BI2939>UQ1WP7,PI1EHV-2,WIDE2*,qAR,PI1EHV-6:`|a,ohJ'/"A)}
2010-07-18 10:19:29 UTC: BI2939>UQ1WP0,WIDE2-1,qAR,PI1EHV-6:`|a3qS3'/"A-}Juecke
2010-07-18 10:19:34 UTC: BI2939>UQ1WP5,WIDE2-1,qAR,ON0DAS-4:`|a<q>='/"A/}
2010-07-18 10:19:39 UTC: BI2939>UQ1WQ3,WIDE2-1,qAR,PI1EHV-6:`|a9q}C'/"A8}
2010-07-18 10:19:45 UTC: BI2939>UQ1WQ6,WIDE2-1,qAR,PI1EHV-6:`|a/p|x'/"AC}Juecke

Ondanks het feit dat dit geen callsign voor radiozendamateurs betreft, wordt BI2939 als voorbeeld gebruikt. Er is namelijk uitstekend te zien dat het pad WIDE2-1 ( hier ) goed werkte. Door het ontbreken van WIDE1-1 in combinatie met de 'matige' gemiddelde hoogte van circa 1000 meter, zie hier, waren er geen problemen. De vele fill-in digi's reageerden niet. De baken intervaltijd was mogelijk ietwat kort gekozen ( gezien de gemiddelde snelheid van 90 tot 100 km per uur .. ). Het leverde wel gedetailleerde 'plaatjes' ( koers ) op. Hoe dan ook, meerdere navolgende uitzendingen veroorzaakten geen duplicates.

DC2EH-11 ( met een ballon ) op zondagmorgen 230510 :

2010-mei-23 10:59:36 DC2EH-11>APT3A1,WIDE1-1,WIDE2-2,PC1L,I:
!5051.47N/00542.73EO215/028/A=000141
2010-mei-23 11:01:34 DC2EH-11>APT3A1,WIDE1-1,WIDE2-2,PC1L,I:
!5050.64N/00542.98EO149/033/A=000157

Ten tijde van dit schrijven waren de betreffende DC2EH-11 raw packets in aprs.fi niet meer beschikbaar ( daarom zijn hierboven alleen de eigen ontvangen data geplaatst ). Omdat de ballon zich op bovengenoemde tijdstippen erg laag voortbewoog zie hier ( hoogte ), waren er geen duplicates te bespeuren. Ondanks het pad : WIDE1-1,WIDE2-2 hi. Geen probleem. Maar op een andere datum was dit te zien, zie hier, alle ballonnen hadden WIDE1-1,WIDE2-2 in het pad en bovendien ook meer hoogte .. De aprs.fi raw packets pagina was volledig rood gekleurd .. We hebben overigens genoten van de voorstelling, daar niet van. En hopen de DC2EH ballonnen nog vaak aan te treffen. Wie weet, met een iets gewijzigd pad. Wil je het hele verhaaltje eens lezen, klik dan hier.

Duplicates zijn niet altijd te voorkomen. Ze kunnen ook ontstaan indien de waarden in het pad verkeerd gekozen worden. Dat is hierboven, aan het begin van deze pagina, al uitgelegd. Een vliegtuig vereist andere waarden dan bijvoorbeeld een auto of een boot. Snelheid, hoogte en de manier van voortbewegen kunnen van grote invloed zijn. Zo kan je bij een vliegtuig serieus overwegen om in het pad geen WIDE1-1 op te nemen. Dit levert uitsluiting op van de vele fill-in digi's, dit kunnen er tientallen of zelfs honderden zijn in actuele 'high density' area. Immers, hoe hoger het vliegend object, hoe groter het gebied van de dekking ! Te vergelijken met een zaklantaarn boven een oppervlak, hoe groter de afstand hoe groter de lichtvlek .. zie hieronder *. Zonder WIDE1-1 zullen home digi's niet reageren op de APRS AIR signalen. WIDE2-1 voor een ballon op hoogte is een veilige waarde. Waarbij de baken intervaltijd geschikt gekozen moet worden.

Voor een zich snel verplaatsend vliegtuig op relatief lage hoogte kan een wat kortere intervaltijd aangehouden worden, eventueel met WIDE2-1,NOGATE in het pad ( onder voorbehoud ) *. Zo'n object is snel weer buiten bereik. Verder moet men zich goed realiseren dat het APRS netwerk niet echt geschikt is voor vliegende objecten. Maar bij wijze van uitzondering, het kan. Interessant om te lezen : klik hier ! Betreft wetenswaardigheden omtrent een IFR flight waarbij in het pad WIDE2-1 gebruikt werd. En mocht amateur radio in vliegtuigen je interesse hebben, kijk eens onder Flights van mijn website. Betreft enige GPS en ATV toepassingen /AIR .....

* een correct geconfigureerde I-GATE zal dan jouw bakens niet naar het internet doorgeven. Het is een interessante optie indien je zelf over de nodige extra ontvangstmiddelen beschikt.

Nog een opmerking, overweging. Men zou bij vliegende objecten van serieuze aard het WIDEn-N kunnen laten vervallen. Ten aanzien van de configuratie van de digi zou een suggestie van deze zijde zijn : gebruik in plaats van WIDEn-N het ( eveneens ) traceable of zelfs flooding AIRn-N. De 'gewone' digi's doen er niets mee. Maar de AIR digipeater des te meer. Indien daarover een afspraak gemaakt kon worden .. ( met name over de onderlinge gemiddelde afstand en dergelijke ) .. Maar zelfs als het niets zou worden werk je nu 'storingvrij' met een AIR digi on AIR hi. En het APRS netwerk wordt niet langer verkeerd gebruikt en overbelast.

De sysop van een digi moet rekening houden met een en ander. Configureer een digi en zeker in dit geval ook de I-Gate zodanig dat, indien mogelijk, alles correct afgehandeld wordt. Voor als een ( mobiel ) station in de fout zou gaan. Uiteindelijk komt alle informatie juist via de I-Gates op internet terecht. Een doordachte configuratie is van groot belang. Een voorbeeld. Zet eens de muisaanwijzer op onderstaande afbeelding. In Gate RF To Internet kun je zien dat Open the gateway is aangevinkt *. Als de andere instellingen hier niet op 'aansluiten' kan dit voor problemen zorgen. Om dit 'aansluiten' te bewerkstelligen moet de ( default ) ini file aangepast worden, en wel in directe zin. Immers, een wijziging in bijvoorbeeld de NOGATE regel ( zie ook elders op deze pagina ) kan niet via het scherm bewerkstelligd en moet bovendien aangebracht worden indien Open the gateway is aangevinkt.

* tijdens een connect ( en login ) met een internet server wordt ( mede afhankelijk van andere instellingen ) APRS RF traffic ( gehoord op de radio poorten ) doorgestuurd. Het is belangrijk dat dit zo correct mogelijk gebeurd middels een juiste configuratie van de IGATE.INI file ..

De UI-View32 I-Gate wordt ingesteld via onderstaande afbeelding. Maar voor een volledige configuratie is de ini file benodigd : IGATE.INI Hierover later meer indien de reacties er om vragen : UNDER CONSTRUCTION ..

UI-VIEW32 DUBBELE AFSCHERMING, DIGI EN I-GATE SAMEN

De preventieve werking van de A.P.T. digi wordt verder aangevuld met de speciale configuratie van de I-gate. Daar is hierboven al over geschreven. Nogmaals de opmerking :

dit type I-Gate zal een eventueel geldig statement in een ( gedeeltelijk ) fout pad eveneens tegenhouden. Men zij gewaarschuwd ..

Enige voorbeeldjes met geldige statements in een overigens fout pad :

Ben je mobiel, met een ( min of meer ) fout pad in de buurt van een smart digi, A.P.T digi, dan is er kans dat niets op internet gezet wordt. Lees daarom de bakentekst van zo'n station, als je er over beschikt.

DIGI EN I-GATE BAKENTEKST GOED LEZEN !

Als je bijvoorbeeld dit ziet : PHG01312/W2 A.P.Trapping SSn-N, even goed lezen ! Hieronder enige uitleg ( meer erover vind je elders in de PC1L site ).

Indien alleen de I-Gate ( SSID -10 ! ) werkt met PHG01312 : geen vermogen, er is geen HF transmissie, DE DIGI WERKT NIET ( is bijvoorbeeld tijdelijk uitgeschakeld ), antennehoogte tot circa 12 meter, antennegain 3 dB, antennerichting NO en 2 bakens per uur. En natuurlijk : WIDE3 waarden en hoger worden niet doorgegeven. BOVENDIEN WORDEN DAN EVENTUEEL ANDERE, GELDIGE STATEMENTS IN HET PAD EVENEENS GEBLOKT ! Zoals bijvoorbeeld SSn-N ..

Indien de digi ( SSID-2 ) werkt met bijvoorbeeld PHG21312 : als boven echter met HF transmissie, vermogen tot 9 Watt. Trapping down boven waarden van 2 voor WIDE ! NLn-N ondersteuning ( nederlandse digi met SSn-N mogelijkheid ). Of PHG21302/X W2 A.P.Trapping SSn-N : als boven echter met een antenne OMNI DIRECTIONAL, en de X staat voor experimentele toepassing.

Vanwege de zeer beperkte ruimte in een bakentekst wordt er zoveel mogelijk info in zo weinig mogelijk tekst gezet. Even puzzelen, soms kan dat helpen ..

Leon PC1L ((-,O)) ..

Advies : het uitzenden van bakentekst waaronder de PHG code ( via radio of internet of beide ) is sterk aan te raden, ook als alleen de I-Gate QRV is. Andere ( mobiele ) stations kunnen nota nemen van mogelijk belangrijke gegevens, zoals type station, antennesituaties en dergelijke.

KF-163 GEBRUIKERS ! VERWIJDEREN VAN RELAY !

Omdat er nog steeds KF-163 gebruikers zijn die met RELAY in het pad werken, wordt hieronder beschreven hoe ervan af te komen. Met RELAY in het pad ontstaan er problems, smart en A.P.T. digi's geven vaak helemaal niets meer verder.

Sluit een kabel * aan ( er mag dan geen GPS unit aangesloten zijn ) tussen KF-163 en COM poort van je PC, gebruik de meegeleverde bootable CD. Stel zo nodig in het BIOS boot CD in. De rest gaat vanzelf : Linux wordt opgestart, het wordt echter niet geinstalleerd. Er is een menu en alles wijst zich vanzelf uit. De tracker kan nu geconfigureerd worden. Je kunt je roepnaam en params wijzigen en klaar. Erna verdwijnt alles weer van je PC.

* kijk uit met het aansluiten van de PC kabel, verwissel c4 en c5 niet.

Kies voor het Nieuw-N paradigma ( hierin is RELAY vervangen door WIDE1-1 ). Gebruik optie P ( Switch Paradigm ) voor het omschakelen van Nieuw-EU naar Nieuw-N. Het aantal hops wordt ingesteld met Proportional Pathing. Voor de PP defaultwaarde ziet het digipad er na bovenstaande wijziging bij transmissie van het derde baken zo uit : WIDE1-1,WIDE2-1 in plaats van RELAY,WIDE2-1 ..

Korte toelichting : in aprstracker v0.11 is SmartBeaconing enabled ( Beacon interval set 0 ) en Proportional Pathing set 3. Dit laatste betekent dat er bakens worden uitgezonden met een digi pad dat toeneemt tot een maximum van 3 hops. Het eerste baken wordt zonder digi pad uitgezonden, het tweede met digi pad RELAY, het derde met digi pad RELAY, WIDE2-1 en bij het volgende baken begint alles weer van voren af aan. Het betreft default settings volgens het zogenoemde Nieuw-EU paradigma ( zie de afbeelding hieronder ). RELAY wordt echter, ook in Europa, steeds minder of niet langer gebruikt ! Natuurlijk voorziet de KF-163 tracker software in de ultieme oplossing, de makers dachten vooruit : switch naar Nieuw-N paradigma ( optie P ).

Als dat gebeurd is kun je mogelijk besluiten om nog een wijziging aan te brengen ( met optie 2 ). Proportional Pathing ( PP ) is soms een uitermate zinvolle toepassing. Wil je het om een of andere reden ( toepassingsgebied ) toch uitschakelen, geef dan een 6 in. Bij alle uitgaande bakens vind je nu WIDE1-1,WIDE2-2 in het pad. Uitgaande van software version 11, anders even checken.

WIDE1-1,WIDE2-2 wordt nog veel gebruikt, en anno 2012 heb ik tot nu toe geen digi of I-Gate gezien die het blokkeert. Ook al zie je steeds meer adviezen verschijnen om het terug te brengen naar WIDE1-1,WIDE2-1 .. in high density area. Ook de intervaltijden van de bakens zijn in deze erg belangrijk.

Wil je gebruik blijven maken van PP : maak Proportional Pathing niet groter dan 3 ! Anders verschijnen er ( zoals met PP 4 ) WIDE3-3 statements. Weg digipeat en gating .. Met PP 3 vind je trouwens ( steeds bij het laatste baken in de reeks ) een pad met WIDE1-1,WIDE2-1 ( vanaf 2011 de ideale defaultwaarde voor het 'gewone mobiele station' ).

DE LUCHT IN MET EEN TRACKER

APRS AIR zie hier.