Die Pipeline - ein Einstieg zur Aufklärung des XTRACK2-Verhaltens

Artur,
Du warst mal wieder sehr fleissig und genau.

Vermutlich ist das auch eine richtige Spur, die das XTRAC-Verhalten beschreibt.
Meine _Vermutung_ geht in die gleiche Richtung;
allerdings würde ich das nicht Pipeline sondern Prognose nennen.
Die Mäuse machen eine klassische Trendberechnung, in dem sie die
ermittelten/historischen Daten bis zu einem gewissen Masse fortschreiben,
wenn keine neuen echten Daten vorhanden sind.
Und genau dieser Prognosemechanismus stört an Stellen, an denen
eigentlich genug Daten vorhanden sind, z.B. kurz vor/nach Stillstand.

Zusätzlich führt zum "eckigen" Tracking das Festhalten an Sat-Kombinationen
bis zur totalen Signaluntauglichkeit; wobei der dann folgende Wechsel
auf "bessere Vögel" natürlich einen Sprung im 20...30m-Bereich
nach sich ziehen _muss_.
Was ich nicht verstehe ist folgendes:
- Warum zeigen die Mäuse auch bei guten Verhältnissen diese Eigenart?
- bei "Magerempfang" via Reflexionen kann ich das verstehen, aber so ?????

[Speku]
Rechenpower für Prognose geht zu Lasten der Anzahl paralleler
Empfangskanäle.
[/Speku]

Wolf
...
nur der Ordnung halber:
die sehr simple Konversion von Tracks in MS-Autoroute
verdanken wir Norbert Hein et al. (NH-Top50Trans)

artur, erstmal ein riesen Lob für diesen Beitrag. Allein das erstellen der Beiträge muss ja Stunde gedauert haben (so wirst du nie Top-Poster )

Ich werde mal mit meinen X-Track-Mäusen Tunnel-Loggs aufzeichen und schauen, ob ich den Wert 6 für DR finde. Verstanden habe ich es jetzt auf jeden Fall.

Zitat

Was ich nicht verstehe ist folgendes:
- Warum zeigen die Mäuse auch bei guten Verhältnissen diese Eigenart?

Das allerdings hab ich noch nicht beobachtet, bei guten Empfangsverhältnissen habe ich noch keine Zacken bei Xtrack festgestellt?

Zitat

[Speku]
Rechenpower für Prognose geht zu Lasten der Anzahl paralleler
Empfangskanäle.
[/Speku]

Ich vermute das auch. Wenn es stimmt, müsste dieser Effekt mit Sirf III besser werden.

So langsam bekomme ich den Eindruck, dass Sirf III nur nötig ist, um die Xtrack-Rechnerei in den Griff zu kriegen. Für Standard-Empfänger scheint mir Sirf III nicht notwendig/sinnvoll zu sein.

Ich befürche, in Zukunft gibt es bald keine Standard-Empfänger mehr

Hallo Wastl,

danke für diesen wichtigen Hinweis.

Ich hatte in den Protokollen der 95k nicht an der richtigen Stelle gesucht.

Berichtigung eingearbeitet.

Gruß
artur

Hallo.

1. Dead Reckoning gibt es nicht bei allen Mäusen mit Xtrack2. Die 303S hat es, einige andere wohl auch. Soweit ich das bis jetzt beurteilen kann, der Yakumo auch nicht. Ist also kein Xtrack2-Merkmal sondern vom Hersteller abhängig.

2. Geschwindigkeitsmittelung über ca 5 sek ist kein Xtrack2-Verhalten, das gab es schon bei meiner 2 Jahre alten Emtac.

3. Die Erklärungsversuche - Kompliment Artur für diese ausgezeichnete Auswertung - sind recht gut, treffen aber nicht in allen Punkten - wahrscheinlich - zu. Dead Reckoning habe ich bis jetzt nur beobachtet bei Satabriß wie er in erster Linie in Tunneln auftritt. Wir müssen aber noch ergänzen, Xtrack2 "friert" die Koordinaten und den Trackwinkel bei Geschwindigkeitsverringerung gegen 0 ein. Den genauen Punkt weiß ich noch nicht, liegt aber so bei ca. 1 km/h.

Der Pipeline-Erklärungsversuch, oder die Version von Wolf hat was für sich. Aber: siehe Bild, aus einem Vergleich von Peter der RBT 1000 mit S und X-Mode und der RBT3000 sieht man, der S-Mode und die 3000 liegen auf dem Weg. Xtrack2 liegt daneben und zeitlich versetzt. Ich habe die - noch nicht genügend gesicherte - Erfahrung gemacht, dass sich Xtrack2 bei Richtungswechsel schnell einstellt, allerdings zeitlich hinterherhinkt. Diese Richtungswechselinformation hat offenbar Priorität bei der Rechnerei, denn sie setzt offenbar schneller ein als das Hinterherhinken nachkommt: im Bild da wo es "runter" geht, Rechtsversatz, der auch sehr lange Bestand hat.

Dann gibt es noch den Fall - hatte ich mal als Auswertung unserer Ravennaschlucht-Wanderung gepostet, verzichte hier erstmal auf genauere Bilder und so - dass bei schlechten Empfangsbedingungen und/oder bei Stillstand (zwischen drin) eben Enfrieren - siehe oben - erfolgt, aber bei Wiederaufnahme der Geschwindigkeit die Koordinaten - manchmal bis oft - grauslig danebenliegen. Das würde wieder die "Pipeline" Erklärung unterstützen: interne Rechnerei zur Standortmittelung, aber Ausgabe von teilweise nicht der Realität entsprechenden Koordinaten - vermutlich, weil man die angeschlossenen Progs nicht längere Zeit ohne Werte lassen kann.

Zum Ausblick: es wird an verschiedenen Stellen von "Erhöhung der Anzahl der Korrelatoren", soweit ich das interpretieren kann, eine Hardwareangelegenheit der Chips, gesprochen und einer "Verweilzeit" der Signale innerhalb dieser "Korrelatoren". Hier kann man darüber nachdenken, ob SIRF III eben die Anzahl dieser Korrelatoren erhöht hat und ob man mit einer "Erhöhung der Verweilzeit" nicht vom Regen in die Traufe kommt, sprich das Nachhinken noch schlimmer wird. Nun, wir werden sehen.

Fazit, und das sollten wir nicht vergessen: diese Xtrack2 Effekte stören bei der Navigation so gut wie nicht. Beim Wandern kann es zu Standortversetzungen kommen, die Geocacher sind etwas "gekniffen".

Und für die Auswertung: NMEA ist - leider - nicht gleich NMEA. Nicht alle halten sich an die Konventionen - daran muss man immer wieder mal denken, siehe Geoid-Korrektur - und neue Dinge wie Dead Reckoning habe ich als Erklärung bei den offiziellen Seiten (nmea) auch noch nicht gefunden. Aber: es gab schon Fälle (einen hatte ich glaube ich mal, weiß aber jetzt nicht mehr wo und was) da streikt ein nachgeschaltetes Prog, denn das Dead Reckoning-Feld ist nicht nur im GGA - da steht es ja nur als anderer Wert in einem sonst vorhandenen Feld - auch GLL und RMC enthalten nun ein Feld am Schluß mit der Bezeichnung "Mode Indicator", dieses Feld ist bei den "Dead Reckoning" Mäusen zusätzlich angehängt, kann zu Problemen führen.

Hallo Wastl,

GPSLog: "6" wird ausgewertet, es kann aber sein, dass das in der auf meiner HP stehenden Version noch nicht der Fall ist. Da habe ich ja überhaupt noch "Nachholbedarf", siehe Abbruch bei Leerzeilen

2 Tracks:

man nehme einen der beiden - können im Endeffekt auch mehr sein - in den Windows-Editor. Den 2. ebenso, alles markieren, im 1. am Ende einfügen... Mit weiteren ebenso verfahren.

In Excel laden: öffnen, Trennzeichen ",", alle Felder in Text ändern.
Alles markieren, sortieren nach 1. Spalte A, 2. Spalte B

Suche nach GGA, alles was vorher ist -> Zeilen markieren, entfernen (also Zeile vorher bis Anfang).
Suche nach VTG - das ist i.d.R. der Rest - alle VTG-Zeilen markuíeren, entfernen.

Nun sollten nur noch GGA-Zeilen übrig sein, kontrollieren.
Speichern als CSV. Namen treffend vergeben!
Diese CMV-File doppelt klicken, wir autom. in Excel geöffnet.

Ersetzen alle ";" mit ",". Speichern: Achtung, neuer Name!!! Und wieder als CSV.

Kann dann in *.txt umbennannt werden, muß aber nicht: u-center frißt es auch als csv.

Damit hat man ein File, das von allen eingelesenen (ist aber logisch nur sinnvoll, bei zeitgleich aufgenommenen Logs) Files immer abwechselnd einen Punkt, d.h., in u-center (Einstellung beachten, wenn hier keine Striche zwischen den einzelnen Punkten erscheinen: in der lat/lon oder Map View-Darstellung unten das Icon mit der Hand Connect auf Consecutive, Points auf Bold Dot einstellen.

Achtung: u-center verarbeitet "nur´" 1600 Punkte in der Normal-Version -> normaler Windows Start. Damit werden bei Überschreiten Punkte vom Anfang des Track gelöscht. Will man alles sehen, über Start/Ausführen <genaue Pfad-Angabe mit z.B.C:\...> u-center.exe -history <Punktezahl> starten.
Blank nicht vergessen, Pfad ist der Ort, wo u-center gespeichert ist, Punktezahl habe ich z.B. auf 600000 gesetzt, hier auch wieder Achtung: Performance wird angeknabbert.

Noch eine Erklärung zum Bild:

zeitgleich waren hier die RBT1000 im S- und X-Modus. Die 3000 wurde nachgetragen, da gibt es ja auch keine Striche. War hier nur zum Vergleich, dass eine Nicht-Xtrack2 auf dem Weg bleibt. Solche Files müssen nicht mit Excel gefummelt werden, die werden einfach mit dem Editor angehängt. Laufen dann nacheinander durch, wenn die Punkteanzahl hoch genug liegt wird der "neue" Track einfach über den vorhandenen gelegt.

Ähnliches läßt sich ja mit der Overlay-Wandlung für die TOP-Karten über NHTOP50Trans machen....

Für Wastl ( und alle, die es auch mögen):

Leerzeilenabbruch ist - zumindest bis zu 3 aufeinander folgende - bereinigt.

Wastl

Nachdem ich nochmal in die Protokolle eingestiegen bin, kann sich jetzt feststellen: ich lag mit meiner ursprünglichen Angabe doch richtig.

Die 95k kennt den Indikator "6" nicht.

Berichtigung wieder gelöscht.

Gruß
artur

Es handelt sich um die gepatchte 95k.

Die Pipeline 2
Ein Einstieg zur Aufklärung des XTRACK2-Verhaltens

Vorbemerkung

Bisher sahen wir Beispiele vom Verhalten der Haicom Hi-303S .

Durch einen Beitrag von Wastl und durch Zweifel von Charly stellte sich die Frage: ist das beobachtete Verhalten nur eine Eigenart der Haicom oder ist dieses Verhalten auch repräsentativ für andere XTRACK2-Empfänger?

Wastl hatte mit einem Protokollauszug darüber informiert, dass seine Yakumo GPS-Maus den Indikator 6 sehr wohl kennt, während ich bisher davon ausging, die Haicom wäre die erste (und womöglich einzige), die diesen Indikator verwendet.

Nachdem ich wegen der offenen Fragen noch mal in das Protokoll der MD95000 eingestiegen bin, konnte ich bestätigen, dass die 95k in der Tat den Indikator 6 nicht kennt. Es zeigte sich aber auch, dass sie deswegen nicht aus einem Vergleich bei der Aufklärung des XTRACK2-Verhaltens ausscheiden muß.

Es wird deshalb interessant, die 95k mit ihrem Verhalten in den bisher betrachteten Situationen kurz vorzustellen.

Der Flughafentunnel TXL (SUED)

In der Kartendarstellung erkennt man bei der 95k gegen über der Hi-303S ein etwas abweichendes Verhalten.

Typ Zeit Breite Höhe Q Sat HDOP Alt ID
$GPGGA 121651,493 5233,9671 N 1318,4712 E 1 9 1,1 81,5 M 0000*31
$GPGGA 121652,493 5233,9613 N 1318,4814 E 1 9 1,1 81,6 M 0000*3C
$GPGGA 121653,493 5233,9559 N 1318,4916 E 1 9 1,1 81,8 M 0000*3D
$GPGGA 121654,493 5233,9508 N 1318,5025 E 1 9 1,1 81,2 M 0000*3C
$GPGGA 121655,493 5233,9462 N 1318,5138 E 1 8 1,2 81,2 M 0000*3F
$GPGGA 121656,493 5233,9417 N 1318,5251 E 1 8 1,2 81,9 M 0000*39
$GPGGA 121657,493 5233,9372 N 1318,5369 E 1 8 1,2 81,6 M 0000*39
$GPGGA 121658,493 5233,9316 N 1318,5485 E 1 8 1,2 80,9 M 0000*3F
$GPGGA 121659,493 5233,9257 N 1318,5594 E 1 8 1,2 80,4 M 0000*36
$GPGGA 121700,493 5233,9193 N 1318,5695 E 1 8 1,2 80,9 M 0000*3F
$GPGGA 121701,493 5233,9127 N 1318,5789 E 1 8 1,2 81,3 M 0000*36
$GPGGA 121702,492 5233,9060 N 1318,5885 E 1 7 1,3 80,8 M 0000*31
$GPGGA 121703,492 5233,8994 N 1318,5983 E 1 6 2 80,6 M 0000*3B
$GPGGA 121704,492 5233,8931 N 1318,6083 E 1 4 4,6 80,4 M 0000*39

$GPGGA 121705,492 5233,8878 N 1318,6185 E 1 3 50 80,2 M 0000*05
$GPGGA 121706,492 5233,8823 N 1318,6285 E 1 0 50 80 M 0000*0A
$GPGGA 121707,492 5233,8768 N 1318,6385 E 1 0 50 79,7 M 0000*0B
$GPGGA 121708,492 5233,8713 N 1318,6485 E 1 0 50 79,5 M 0000*0D
$GPGGA 121709,492 5233,8658 N 1318,6586 E 1 0 50 79,2 M 0000*07
$GPGGA 121710,492 0 0 50 M 0000*25
$GPGGA 121711,492 0 0 50 M 0000*24
$GPGGA 121712,492 0 0 50 M 0000*27
$GPGGA 121713,492 0 0 50 M 0000*26
$GPGGA 121714,492 0 0 50 M 0000*21
$GPGGA 121715,492 0 0 50 M 0000*20
$GPGGA 121716,492 0 0 50 M 0000*23
$GPGGA 121717,492 0 0 50 M 0000*22
$GPGGA 121718,491 0 0 50 M 0000*2E
$GPGGA 121719,491 0 0 50 M 0000*2F
$GPGGA 121720,491 0 0 50 M 0000*25
$GPGGA 121721,491 0 0 50 M 0000*24
$GPGGA 121722,491 0 0 50 M 0000*27
$GPGGA 121723,491 0 0 50 M 0000*26
$GPGGA 121724,491 0 0 50 M 0000*21
$GPGGA 121725,491 0 0 50 M 0000*20
$GPGGA 121726,491 0 0 50 M 0000*23
$GPGGA 121727,491 0 0 50 M 0000*22
$GPGGA 121728,491 0 0 50 M 0000*2D
$GPGGA 121729,491 0 0 50 M 0000*2C
$GPGGA 121730,491 0 0 50 M 0000*24
$GPGGA 121731,491 0 0 50 M 0000*25
$GPGGA 121732,491 0 0 50 M 0000*26
$GPGGA 121733,491 0 0 50 M 0000*27
$GPGGA 121734,491 0 0 50 M 0000*20
$GPGGA 121735,49 0 0 50 M 0000*20
$GPGGA 121736,49 0 0 50 M 0000*23
$GPGGA 121737,49 0 0 50 M 0000*22
$GPGGA 121738,49 0 0 50 M 0000*2D
$GPGGA 121739,49 0 0 50 M 0000*2C
$GPGGA 121740,49 0 0 50 M 0000*22
$GPGGA 121741,49 0 0 50 M 0000*23
$GPGGA 121742,49 0 0 50 M 0000*20
$GPGGA 121743,49 0 0 50 M 0000*21
$GPGGA 121744,49 0 0 50 M 0000*26
$GPGGA 121745,49 0 0 50 M 0000*27
$GPGGA 121746,49 5233,4108 N 1318,5108 E 1 5 1,4 112 M 0000*0F
$GPGGA 121747,49 5233,3978 N 1318,4937 E 1 5 1,8 109 M 0000*04
$GPGGA 121748,49 5233,3863 N 1318,4842 E 1 5 1,8 117 M 0000*0F
$GPGGA 121749,49 5233,3783 N 1318,4763 E 1 5 1,4 104 M 0000*04
$GPGGA 121750,49 5233,3676 N 1318,4655 E 1 7 1,3 99,9 M 0000*34
$GPGGA 121751,489 5233,3561 N 1318,4543 E 1 7 1,3 99,1 M 0000*34
$GPGGA 121752,489 5233,3467 N 1318,4435 E 1 7 1,3 64,6 M 0000*35
$GPGGA 121753,489 5233,3353 N 1318,4325 E 1 3 30,9 57,4 M 0000*0C
$GPGGA 121754,489 5233,3239 N 1318,4211 E 1 4 2,5 55 M 0000*3C
$GPGGA 121755,489 5233,3121 N 1318,4099 E 1 3 30,9 55,5 M 0000*0A
$GPGGA 121756,489 5233,3006 N 1318,3981 E 1 4 2,5 54,7 M 0000*33
$GPGGA 121757,489 5233,2891 N 1318,3865 E 1 4 2,5 53,3 M 0000*3D
$GPGGA 121758,489 5233,2777 N 1318,3749 E 1 3 30,9 53,9 M 0000*04
$GPGGA 121759,489 5233,2665 N 1318,3630 E 1 3 30,9 54,8 M 0000*0E
$GPGGA 121800,489 5233,2530 N 1318,3525 E 1 4 2,5 58,5 M 0000*32

Man erkennt im Protokoll der 95k ein ähnliches Verhalten wie bei der Hi-303S.

Ein Unterschied: an der Stelle, wo bei der Hi-303S DR-Zeilen geschrieben werden, schreibt die 95k solche Zeilen ohne den Indikator 6, sie verwendet weiterhin den Indikator 1, setzt den HDOP-Wert auf 50 und die Zahl der Sat_in_use auf 0.

Auch die 95k gibt aber unter diesen Bedingungen Standorte aus, die mit den davor produzierten virtuellen Standorten auf einer Linie liegen.

Mit diesem Verhalten wird die 95k vergleichbar.

Im Bild zählt man bei der 95k acht Standorte, die neben der Fahrbahn liegen. Drei davon müssten nach den Protokollwerten eigentlich auf der Fahrbahn liegen.

Schaut man genau hin, dann waren es wahrscheinlich auch bei der Haicom acht virtuelle Standorte, von denen vier als DR-Zeilen ausgegeben wurden.