[SUCHE] Logger für anspruchsvolle Wanderungen/Klettertouren mit zum Teil nicht optimalen Empfangsverhältnissen.

Servus und Hallo @all

Wie bereits im Titel erwähnt suche ich einen GPS-Logger um meine Wanderungen zu protokollieren. Dabei zähle ich mich schon fast zu den "Wanderkletterern", da ich nicht immer nur auf eingezeichneten Wegen unterwegs bin (70% Gewichtung) sondern auch schon einmal an einer Felswand hänge (10% Gewichtung) oder mich durch Schluchten schlage (20% Gewichtung). Dementsprechend habe ich natürlich auch alles andere als ideale Verhältnisse was den GPS Empfang angeht und auch sehr oft kleinste Geschwindigkeiten. Der gesuchte Logger sollte also auch in anspruchsvollerem Terrain eine gute Figur machen und sich nicht gleich durch ein paar Reflexionen komplett aus dem Konzept bringen lassen. Außerdem würde ich zur Navigation gerne einen Bluetooth-Link zu meinem Smartphone haben um dort in ruhigeren Phasen auch einmal nach dem Weg sehen zu können. Also noch einmal kurz das Anbspruchs-/Verwendungsziel zusammengefasst:

• Wandern auf üblichen Wegen - 70%
  
• Wandern in unzugänglichem Gelände/Schluchten - 20%
  
• Klettern an Felswänden - 10%
  

Nun gibt es ja so manche Hardware auf dem Markt die sich schon in vielen Systemen bewährt hat. Unter anderem würde ich sagen bilden hier der alt ehrwürdige Mr. SirfIII, und die Chips SirfIV, u-blox 5/6 und der MTKII die Grundlage auf derer es sich zu entscheiden gilt. Wobei ich diese gerne in drei Kategorien einteilen würde.

1) Sirf III
Über den SirfIII wurde schon viel Gutes geschrieben. Gerade bei Geschwindigkeiten unter 0,2 km/h soll er ja den Trackwinkel exklusiv gut abbilden können. Aber andererseits frage ich mich ob dieser Chipsatz wirklich noch auf der Höhe der Zeit ist. Mit 20 Kanälen bietet er nur einen Bruchteil seiner heutigen Zeitgenossen. Und gerade beim Punkt Navigation kann ich was den Winkel angeht auch ohne Probleme den eingebauten Kompass in meinem Smartphone verwenden, richtig? - Weshalb ich derzeit aus meiner Sicht eher dazu tendiere diese Kategorie an Chips auszuschließen. Wobei ich mich aber gerne eines Besseren belehren lasse.

2) SirfIV u-blox 6

Diese Chips scheinen zwar das Neueste vom Neuen zu sein, aber dennoch habe ich noch keinen von Ihnen in einem GPS-Logger zu Gesicht bekommen. Bisher sah ich solche Exemplare exklusiv in Mobilgeräten, Autonavigationssystemen und ähnlichen Endgeräten, aber eben in keinem GPS Logger. Darum schließe ich diese Kategorie ebenfalls aus.

3) u-blox 5 + MTK II

Somit bleiben als mögliche Chipsätze lediglich der u-blox 5 sowie der MTK II übrig. Wobei sich eben nun die Frage stellt welcher der beiden ist besser geeignet für meine doch etwas anspruchsvolleres Profil im Vergleich zu so manchem "Normalbenutzer".

Möglich Geräte mit den beiden Chips u-blox 5 und MTKII gibt es ja zuhauf auf dem Markt (vor allem was den MTKII Chip angeht). Darum bin ich hier auch leicht überfordert eine klare Entscheidung zu treffen. Natürlich kommt es mir in erster Linie auf den aufgezeichneten Track an. Der sollte natürlich möglichst sauber sein. Die Logger-Eigenschaften dürfen sich dabei gerne auf Zeit/Ort/Höhe/Geschwindigkeit begrenzen. DOP Werte benötige ich nicht unbedingt, da ich hier keine Zeit habe die Tracks ausgiebig nachzuarbeiten. Zur Not kann man bei den meisten GPS Loggern ja per Bluetooth immer noch auf dem Handy den NMEA Stream aufzeichnen. Somit hat man dann oft doch wieder DOP Werte, sollte es einen einmal interessieren. Es wäre auch schön, wenn man etwas näher am Chipsatz arbeiten kann. Aber dank BT747 und u-center kann man das denke ich bei fast allen MTK II und u-blox 5 Geräten ohne Probleme tun. Also wesentlich sind:

• Bluetooth Sschnittstelle
  
• Sehr gute Empfangscharakteristik
  
• Gute Anpassbarkeit (u-center [u-blox]/ BT747 [MTKII])
  

Und nun stellt sich endlich die Frage nach der Gerätewahl. Ich möchte hier nicht allzu viel angeben und bin in diesem Punkt eher einmal auf eure Meinungen gespannt. Ich habe lediglich einmal zwei Exemplare herausgesucht von denen ich denke, dass sie so ziemlich die Speerspitze dessen sind was derzeit möglich ist. Dies wären:

• QStarz Q1000eX (MTK II)
  
• WinTec WBT-202 (u-blox 5 [ROM-Version])
  

Zu welchem Gerät, das nicht zwangsläufig aus der oberen Liste entnommen werden muss würdet Ihr in meinem Falle greifen? Ich bin gespannt.

Viele Grüße,
Chris

Hallo Christof,
vielen Dank für Deine Antwort und die Einschätzung was den WBT202 angeht. Das Interesse ist meinerseits durchaus vorhanden und besagten Beitrag, sowie viele viele andere habe ich ebenfalls schon komplett gelesen (nicht gescrollt). Und ich finde, dass ich mich als blutiger Anfänger in der GPS-Szene bereits schon ganz gut durchgearbeitet habe. Ich hoffe, man kann erkennen, dass ich mich durchaus etwas tiefer belesen habe und mir über meine Anforderungen, die verfügbaren Chips und deren Modifikationsmöglichkeiten via u-center,... durchaus im Klaren bin. So schlecht lag ich ja mit meinem WBT202 Vorschlag was die u-blox Seite angeht nicht.
Allerdings muss ich auch offen gestehen, dass es so gut wie zu jedem Logger sowohl Meinungen gibt die ihn in den Himmel loben und andere die kein gutes Haar an ihm lassen. Außerdem hat sich seit ~2009 in der Loggerszene nicht mehr allzu viel bewegt (nach Sirf III, MTK II und u-blox 5 wurden ja bisher keine neueren Chips mehr in Loggern verbaut). Lediglich der MTK wird von einigen Firmen für immer höhere Updateraten zugelassen 5Hz/10Hz. Letzten Endes entscheidet da wohl mehr die Firmware + die verbaute Antenne über die Qualitäten eines Loggers. Doch ob sich da seit 2007-2009 so viel getan hat kann ich nicht beurteilen. Womit wieder eine ganze Armada an Loggern in Frage kommen würde und. Denn was wirklich der aktuelle Stand ist und welche Geräte man doch eher zum alten Eisen zählen sollte ist für mich sehr oft noch ein großes Rätsel. Aber ich bin zuversichtlich dieses auch noch zu lösen.

Viele Grüße,
Chris

Hallo Chris,

nun bin ich schon eine Weile raus aus dem "Geschäft", aber der WBT202 ist, wenn ich wieder mal loggen will, meine Wahl bei doch einigen anderen, die sich so bei mir angesammelt haben.

Leider sind ja Mäuse eine aussterbende Spezies, Logger zählen wohl inzwischen auch dazu, denn wirklich neues konnte ich auch nicht finden. Wintec hat zwar noch einen WSG2000 mit neuerem ublox-Chip gefertigt, aber das ist leider ein recht - für Wanderer - unseliger Biker-Logger geworden.

Einen Qstarz 1000X mit MTK hatte ich mal 5 Tage herumgeschleppt, gefiel mir recht gut, nur die Auswerte-SW war reichlich gewöhnungsbedürftig. Da habe ich aber vermutlich andere Anforderungen, Ziele, weswegen Geräte mit u-blox-Chip einfach für mich die Wahl sind, erlauben sie doch mit dem m.M. nach einzigartigen SW u-center Auswertungen die sonst nicht zu finden sind.

Aber ein Vorschlag: schau mal auf der Seite von haid-services was dort angeboten wird. Und dann frage mal dort Sylvia Haid oder Torsten ob man Dir mal 2 Logger Deiner näheren Wahl zum Testen geben könnte, sage einen schönen Gruß von mir. Einen davon wirst Du ja dann vermutlich behalten... Viel Spaß und Erfolg.

Hallo Christof, Hallo Charly,
vielen Dank für eure weiteren Beiträge. Ich habe mich noch etwas weiter in die Materie ublox5/MTKII vertieft. Dabei kam ich auch zu dem Entschluss, dass nichts an einem persönlichen Test der beiden Chipvarianten vorbeiführt. Darum war ich gestern Nachmittag unterwegs und habe mir einen WBT202 besorgt + einen QStarz 8181XT mit MTKII Chip. Leider war der Logger Q1000eX nicht vorrätig. Sollte ich mich aber für den MTKII entscheiden, so kann ich beide zurück bringen und erhalte den Q1000eX sobald er da ist. Da der Chipsatz jedoch der Gleiche ist sollte der 818er für einen Vergleich genügen.
Zuerst habe ich natürlich einmal die Geräte konfiguriert. Wobei ich mich auf unkritische Bereiche wie Bewegungssensor deaktivieren, Bluetooth Timeout abschalten,... beschränkt habe. Ein Blick in BT747 & ucenter wagte ich aber dennoch. So habe ich für den WBT202 mit dem ucenter noch schnell EGNOS aktiviert. Und schon während diesem "Reinschnuppern" fiel mir auf, dass der ublox 5 wohl deutlich mehr Konfigurationsmöglichkeiten hat was den Empfängerbereich angeht, während ich beim MTKII mithilfe von BT747 fast nur Loggeroptionen, Ausgabeintervalle und Ausgabedatenströme anpassen kann. Das ist zwar auch schön, aber der ublox ist eben doch deutlich offener. So kann man hier, sofern man sich gut genug belesen hat und weis was man tut, durchaus auf den Kalmanfilter, die Fix-Qualitätskriterien,... direkt Einfluss nehmen um diese für seine Bedürfnisse ideal anzupassen. Schon zu diesem Zeitpunkt war mir (als Spielkind) der ublox irgendwie sympathisch . Aber gut, der Praxistest stand noch aus, und letzten Endes kommt es nur darauf an wie sich die Chips hier schlagen werden. Also mal eben mit den Empfängern auf unseren Hausberg hier gelaufen und unter sehr guten Sichtverhältnissen in jede Himmelsrichtung die Geräte unter stationären Bedingungen knapp eine Stunde lang initialisiert. Danach waren dann die Bahndaten da wo sie hin gehören, nämlich im GPS.
Ab dann ging es los. Der 818XT NMEA Datenstrom wurde über mein Smartphone mitgeschnitten (1Hz Wiederholrate) und der WBT202 hat auf seine SD Karte geloggt (ebenfalls 1Hz). Die Teststrecke war für GPSRs eigentlich alles andere als ideal. Ging es doch hauptsächlich durch Häuserschluchten... wieder ab nach Hause... war ja kalt . Außerdem musste ich ja schnell wieder heim um die Daten zu checken. Es ging dann noch einige Male auf einer kleineren Teststrecke durch die Stadt; Alles immer schön in Schrittgeschwindigkeit. Aufgrund der vielen Reflexionen und wechselnden Sichtverhältnissen zu den einzelnen Satelliten war es sicherlich ein etwas extremer Test. Aber auch hier erwarte ich von modernen Chipsätzen, dass sie wenigstens grob die Position wiederspiegeln und nicht 3 Parallelstraßen daneben liegen (was zum Glück bei keinem der beiden Chipsätze passierte). Meiner Meinung nach kam der ublox mit dieser Situation etwas besser zurecht. Der MTKII hatte da schon etwas mehr mit Multipath-Einflüssen zu kämpfen und driftete unter diesen Umständen hin und wieder doch weiter ab als der ublox. Dabei wurden beide Logger die ganze Zeit mit ~40cm Abstand zueinander, in einer idealen Position (Patchantenne zum Himmel) gehalten. Ja, in jeder Hand einer und die Hände schön ausgestreckt. Zum Glück war es bei den Tests schon dunkel. Aber für so etwas mache ich mich gerne mal zum Affen . Aber zurück zum Thema. Ich bemerkte auch, dass der MTKII immer etwas "hinterher" hinkte. So war meine reale Position der GPS Position auf der TOP10 BW Karte + der Openstreetmap Karte immer ein Stück voraus. Evtl. eine etwas zu weich eingestellter Filter? Beschleunigungen wurden jedenfalls nicht so spontan erfasst wie beim ublox. Beim ublox war das Hinterherhinken ganz so extrem der Fall. Dennoch konnte man auch hier ein leichtes "Nachhängen" ausmachen, wenn auch deutlich geringer. Dennoch empfand ich insgesamt die Tracks des ublox etwas besser als die des MTKII. Auch hatte ich das Gefühl, dass beim MTKII Gerät der Track zusätzlich etwas geglättet wird. Als ich im Kreis lief (ca. 2-3m Durchmesser,... ja ein kleiner Kreis) war dieser im MTKII Log kaum auszumachen. Es sah eher so aus als ob man hier ein kurzes Stück rückwärts gegangen ist. Der ublox hingegen bildete den Kreis deutlicher ab. Ich beschloss also schon nach den ersten paar Logs, dass ich auf alle Fälle den ublox5 WBT202 behalten werde. Sicher sind beides super Produkte, aber dennoch, für mich bedient der ublox meine Anforderungen am besten, auch wenn der MTKII indoor etwas schneller den Fix findet (er ist eben doch rund 5dBm empfindlicher als der ublox). Aber ein Indoor-Fix ist sowieso nicht zu gebrauchen, ganz egal ob er früher oder später kommt. Im Wald und beim Klettern werden die -160dBm des ublox wohl reichen.


Nach dieser Entscheidung ging es dann heute in die zweite Runde: Die Optimierung. Das mit dem geringfügigen "Nachhängen" gefiel mir noch nicht so gut, auch wenn dies nur minimal zu verspüren war. Es war also an der Zeit etwas tiefer in ucenter ein zu steigen und sich an die tieferen Einstellungen heran zu wagen. Im Netz fand ich die "u-blox5_Protocol_Specifications(GPS.G5-X-07036)" als PDF Datei (Google ist Dein Freund). Dort ist schön erklärt für was die einzelnen Navigation Modes, insbesondere die Dynamic Platform Model Einstellungen gedacht sind. So stand mein WBT202 anfänglich auf "0 - Portable". Mit den Einstellungen "Pedestrian" und schließlich mit "Automotive", was bezüglich der Beschleunigungen noch etwas zügiger reagiert, bekam ich dann das "Hinterherhängen" schließlich auch weg. Schon eine tolle Sache an den Filtern so aktiv Hand anlegen zu können. Weiterhin habe ich noch die SHT auf Null gesetzt. Die Genauigkeitsparameter (GPS Mode) lies ich erst einmal auf den Werkseinstellungen. Evtl. ziehe ich diese aber später mittels WBT-Tool etwas hoch auf die "high accuracy" Einstellung. Wobei ich ganz ehrlich sagen muss, dass ich lieber einen etwas schlechteren Fix mal habe als einen Empfangsabbruch. Da die Standardeinstellung bisher ganz gut lief, blieb es wie gesagt erst einmal dabei. Außerdem benötige ich ja auch noch Experimentierstoff für die kommenden Wochen. Ein kleines BATCH-Progrämmchen habe ich dann doch noch geschrieben, so dass ich die TES Files des WBT202 mittels GPSBabel alle auf einen Schlag umwandeln kann. Mit dem WBT-Tool war das schon müssig. Einen zusätzlichen BL-5C Nokia Akku habe ich mir noch nicht besorgt. Aber ich denke mindestens einer kommt auf die nächste Tour mit. Die 5 Euro sind sicherlich keine Fehlinvestition.


Zwei Punkte bezüglich des WBT202 würde ich aber noch gerne klären

• Bekommt Ihr auch eine Fehlermeldung beim Speichern der Einstellungen in TMX unter dem Reiter Navigations-Einstellungen? Die anderen Reiter funktionieren alle. Ich denke, dass das bei allen WBT202 so ist, da TMX ja ein universelles Programm für viele Wintec Empfänger ist und dieser Reiter wohl nur für die Antaris4 Platform vorgesehen ist. Auch in ucenter muss ich ja die NAV5 Einstellungen ändern. NAV & NAV2 funktionieren beim ublox5 ja auch nicht. Da ich im Grunde sowieso nur das WBT-Tool für Wintec spezielle Einstellungen (z.B. Bewegungssensor, oder für die Genauigkeitsprofile) benutze, und das ucenter für alles Andere, mache ich mir um TMX auch keine weiteren Gedanken. Ist also nur so aus Interesse.
• Was mich etwas mehr beschäftigt sind folgende Fragen rund um das Thema "EGNOS":

• Wenn ich das Testflag zulasse, werden die Sats mit Testflag (gibt doch keine mehr oder?) dann mit in die Berechnung einbezogen oder nur angezeigt? Hab da mal was gelesen, dass diese dann nicht zur Korrektur benutzt werden obwohl sie angezeigt werden. Ich weis aber nicht mehr ob dies für den WBT202 galt.
• Bei uns in Deutschland kann ich ja nur die PRNs 120 124 126, also #33 #37 #39 gut empfangen. PRN 131, #44 über dem indischen Ozean hatte ich noch nicht gesehen. Kann ich diesen also ohne Probleme aus der Suchliste ausklammern? => Benutzerdefinierte PRNs angeben und nur 120,124,126 angeben?
• Bald gibt es ja auch noch den Astra 4B auf 5° Ost (Start Ende 2011/Anfang 2012). Wie schätzt Ihr das ein - ist hierdurch eine signifikante Verbesserung der Verfügbarkeit von EGNOS am Boden zu erwarten? Viel höher steht er ja nicht am Himmel. Bei uns so ca 34° Elevationswinkel. Die restlichen SATs stehen bei:

PRN 120 #33 29° Elevationswinkel
PRN 124 #37 33° Elevationswinkel
PRN 126 #39 32° Elevationswinkel
PRN 131 #44 14° Elevationswinkel




Soweit also erst einmal von meiner Seite. Ich werde noch eine runde Gassi gehen (niiiiict mit dem Hund, ... mit dem GPS! ) und bin schon gespannt auf eure Meinungen.


Viele Grüße,
Chris

Hallo Chris.

Nur mal eine Teilantwort. Bei meinen Sommer-Nachmittags-"Langzeit"-Tests konnte ich die letzten Jahre (3 oder doch schon 5???) bei aktiviertem EGNOS leider keine Verbesserung feststellen. Vielleicht liege das aber auch nur an meiner etwas südlicheren Lage...

Ich hänge Dir mal noch ein kleines Excel mit den Grundparametern von TMX an, ist manchmal etwas schneller als TMX immer wieder aufzurufen, außerdem sind noch ein paar andere Logger gelistet. Interessant, wie auch Wintec unterschiedliche Parametereinstellungen vornahm.

Dann schau mal auf meine HomePage, da liegt so einiges noch rum, vielleicht ist noch was brauchbares dabei.

Guten Abend Charly,
danke für Deinen beitrag und das Excel Sheet. Hatte mir das bereits von einem anderen Deiner Beiträge heruntergeladen. Auch die Homepage von Dir kenne ich bereits. Dennoch Danke für den Hinweis. Unter anderem aufgrund Deines Tests des 202ers bin ich auf diesen Logger aufmerksam geworden. So gut wie er bei Deiner "Teststrecke" abgeschnitten hat musste die Maschine schon was können.
Was EGNOS angeht muss ich mich noch einmal weiter vertiefen. Vor allem die Sache mit dem Test-Flag. Also die Sats 33 37 & 39 bekomme ich ohne Probleme rein. Aber wenn diese natürlich nicht benutzt werden, weil ich die Test Option an habe wäre das schade. Obwohl auch ich denke, dass es keinen wirklichen Genauigkeitsvorteil bringt bei den hochempfindlichen Empfängern heutzutage. Aber die Psyche spielt eben auch mit .

So, nun leg ich mich aber erst einmal hin.
Vielen Dank nochmals + viele Grüße,
Chris

Ui, es lässt mir doch keine Ruhe. Hab noch einmal geforscht und bin, erneut, im u-blox5_Protocol_Specifications(GPS.G5-X-07036) PDF fündig geworden. Somit kann ich zumindest die ersten beiden Punkte beantworten. Der dritte wird sich wohl zeigen sobald der neue Sat gestartet wurde. Also hier noch kurz die Antworten:

• Wenn das Testflag an ist werden auch Sats mit gesetztem Testflag in die Berechnung mit einbezogen. Also JA, es wird mit ihnen offiziell korrigiert. Ich habe es mal gesetzt. Aber seit 2009 dürfte das nicht mehr nötig sein, da EGNOS nun im offiziellen Betrieb ist. Es gibt aber wohl auch Empfänger die da immer noch durcheinander kommen. Darum lieber mal setzten, dann geht es auf alle Fälle
• Ich habe nun die PRNs manuell eingestellt. Und zwar auf 120, 124, 126 . Die 131 habe ich rausgenommen. Erstens steht dieser so tief (14°), dass man ihn sowieso so gut wie nie empfangen kann. Ich stehe immerhin nicht immer auf einer Bergkuppel. Außerdem wird er auf der EGNOS Status-Seite der ESA (http://www.egnos-pro.esa.int/I…h/imagetech_realtime.html) ebenfalls nicht aufgeführt. Daraus schließe ich einmal messerscharf, dass er evtl. keine für Europa gültigen Korrekturdaten hat. Er steht ja auch eine ganze Ecke östlicher. Also besser mal raus mit dem.
• ...wie gesagt das wird sich zeigen. Auf keinen Fall sollte man vergessen Ende 2011 / Anfang 2012, wenn der neue EGNOS Sat im Orbit ist und seinen Dienst aufnimmt seine PRN mit ein zu tragen. Spätestens dann kommt man nicht mehr an der manuellen PRN Liste vorbei, will man EGNOS mit allen möglichen Sats nutzen.

So, nun sind alle Unklarheiten beseitigt und ich kann beruhigt schlafen gehen

Viele Grüße,
Chris

Guten Abend.
Ein weiterer Tag WBT202 liegt hinter mir und neue Fragen kommen auf. Heute bin ich mit folgenden Einstellungen unterwegs gewesen:

- Automotive
- Auto 2D/3D
- PDOP Mask 23.0
- TDOP Mask 23.0
- PAccuracy 100m
- TAccuracy 300m
- SHT 0.0

- Min/Max SV 4-16
- Min C/N0 16 dbHz
- Init 3D Fix ON

Vom Track her war ich eigentlich begeistert. Dennoch werde ich einmal die Defaultwerte direkt von ublox testen. Hier ist das System etwas sensitiver für schwache und schlechtere Signale. In wieweit dies zu größeren Multipathproblemen führen wird werde ich noch sehen. uBlox schlägt als Default in Ihrem "System Integration Manual" vor:

- Automotive
- Auto 2D/3D
- PDOP Mask 25.0
- TDOP Mask 25.0
- PAccuracy 100m
- TAccuracy 300m
- SHT 0.0

- Min/Max SV 3-16
- Min C/N0 10 dbHz
- Init 3D Fix OFF

Die Navigationsschwelle von 10 dbHz ist dabei schon deutlich geringer. Aber ich werde ja sehen. Welche Erfahrungen habt Ihr so gemacht? Bzw. mit welchem WinTec Standardprofil habt Ihr bisher die besten Erfahrungen gesammelt?

Auf die folgenden Fragen habe ich in den Tiefen des Internet auch noch nirgends eine eindeutige Antwort gefunden:

• Ist der Fix wirklich stabiler und geht weniger oft verloren, wenn man Init 3D Fix anschaltet? Das sollte doch eigentlich nur einen Einfluss haben auf die Zeit bis zum ersten Fix, bzw. auf die Zeit bis zu einem Re-Fix, aber doch nicht auf die Stabilität??? Ob ich ein Signal habe und dies gültig ist, ist doch eher von Min/Max SV, den DOP Schwellen und Min C/N0 abhängig ?!
• Wo liegt genau der Unterschied zwischen den Profilen Fußgänger und Auto? Soviel wie ich bisher herausgefunden habe wird bei Fußgänger wohl mehr geglättet und die Verzögerung kann bei nicht eindeutigen Signalen schon einmal 3-4 Sekunden betragen. Auto hingegen sollte weniger geglättet sein und daher auch eine geringere Verzögerung in schlechteren Empfangssituationen haben (1-2 Sekunden) ....das was ich in meinem Bericht als "Hinterherhängen" bezeichnet habe. Ist dies soweit korrekt? Und ist das ganze nicht sowieso egal, wenn man sekündlich loggt? Dann kann ja keine wirkliche Glättung erfolgen, oder? Ich MUSS den Punkt ja dann ins Log schreiben lassen, egal mit welcher Einstellung. Was habt Ihr eingestellt? Momentan bin ich bei "Auto", da mir der Fußgänger zu sehr hinterher lief. Auf Glättung stehe ich auch nicht so.
• Wo wir gerade beim Loggen sind. Ist es eigentlich besser, wenn ich nur alle 3 oder 5 Sekunden logge? Weil dann der Track durch die interne Verarbeitung besser aufbereitet werden kann, bzw. überhaupt erst bearbeitet werden kann (siehe Punkt 2 mit dem sekündlichen Log)? Bisher logge ich sekündlich, da ich denke, dass das am ehesten an die Rohdaten heran kommt. Glätten, Kürzen,... lässt sich das Ganze später z.B. mittels GTA ja immer noch.

Ich bin gespannt auf eure Sichtweisen.
Viele Grüße + besten Dank,
Chris (der sein WBT202 schon am dritten Tag für nichts mehr eintauschen würde )

So, ein kleines Update habe ich noch. Die Empfindlichkeitseinstellungen habe ich wieder zurück gestellt auf die Einstellungen:

- Automotive
- Auto 2D/3D
- PDOP Mask 23.0
- TDOP Mask 23.0
- PAccuracy 100m
- TAccuracy 300m
- SHT 0.0

- Min/Max SV 4-16
- Min C/N0 16 dbHz
- Init 3D Fix ON

Mit 10 dbHz Verarbeitungsschwelle war das System einfach zu anfällig gegenüber reflektierten Signalen. Des Weiteren habe ich meine EGNOS Einstellungen noch einmal überarbeitet. Diese lauten derzeit:

- SBAS enabled
- Alle 4 Haken (also inkl. dem Testmodus) gesetzt
- Auswertekanäle: 2
- PRNs manuell angegeben zu: 122,124

Zum einen hat der ublox mit nur zwei EGNOS Trackingkanälen nun etwas mehr Luft für andere Berechnungen, und zum anderen sind Laut EGNOS Homepage http://www.egnos-pro.esa.int/index.html auch nur AOR-E (PRN120) sowie ARTEMIS (PRN 124) für den regulären Betrieb vorgesehen. IOR-W (PRN 126) wird momentan von der Industrie für verschiedene Testzwecke benutzt. Demnach interpretiere ich, dass bei Gebrauch von IOR-W (PRN 126) durchaus auch mal ein absichtlich "falsches" Korrektursignal verarbeitet werden könnte, was dazu führen könnte, dass es eher eine "Verschlimmbesserung" wird durch den Gebrauch von PRN 126. Hier ist auch noch einmal der Status eines jeden EGNOS Satelliten zu sehen: http://egnos-user-support.essp-sas.eu/egnos_ops/index.php . Vielleicht nützt diese Info ja jemandem.

Was mich nun aber immer noch brennend interessieren würde sind eure Meinungen zu meinen drei letzten Fragen aus meinem letzten Beitrag

Viele Grüße,
Chris

Hallo Chris,

sorry, bei diesen Deinen Fragen muss ich mich ausklinken, denn meine "Neugierde" betraf andere Dinge. So der Spur nach bin ich allerdings der Meinung, dass ublox nicht schönt, es nicht nötig hat, Tracks zu "bügeln". Übrigens ganz im Gegensatz zu einem (ältern) SiRF bei dem es ein "TrackSmoothin" gab, was zu einem Track führte (Tunnelausfahrten, Reaquisition) den ein anderer Forenteilnehmer treffend als "Pinkelkurve" bezeichnet hat. Dies - und nicht nur - führte eben auch zu meiner immer noch vorhandenen Begeisterung von ublox.

O.K., es kann natürlich sein, dass im Pedestrian-Mode hier evtl. doch eine Glättung - marginal - stattfindet. Wird aber schwer sein, dies so was wie zu beweisen.

Hm, Christoph hat sich offenbar auch ausgeklinkt? Wir sind doch nicht die Einzigen die Neugierde zeigen und etwas weiter in die Tiefe gehen?

Hallo Charly,
naja, vielleicht bin ich einfach 2 Jahre zu spät dran mit dem WBT202. Während alle ihn schon benutzen spiele & optimiere ich noch dran herum ...aber was soll's, Hauptsache es macht Spaß. Außerdem ist es ganz schön spannend so tief in die Materie zu gehen. Die EGNOS Erkenntnis war mir so jetzt auch neu. Aber noch einmal kurz zu den Profilen: Auf der Webseite http://www33.atwiki.jp/gpsgps/pages/50.html habe ich für das ältere Modell WBT201 eine kleine Beschreibung der Profile gefunden. Da heist es unter anderem (zumindest will mir das der Google Translator weis machen):


2-Pedestrian
Filters intended for human powered vehicle acceleration and low speed of pedestrians.
Generous time lag (3-4 seconds when the situation is bad positioning).
3-Automotive
Automotive. Less noise-like motion, the vertical acceleration is less expected filter.
Time lag (1-2 seconds in a bad situation when positioning).

Das System Integration Manual des ublox 5 sieht die Grenzen dieser beiden Profile wie folgt:


Pedestrian

• Anwendungen mit kleiner Beschleunigung und geringen Geschwindigkeiten

• Max Höhe: 9000m

• Max Geschwindigkeit: 108 km/h

• Max vertikale Geschwindigkeit: 72 km/h

• Gültigkeitsüberprüfung: Höhe & Geschwindigkeit

• Maximale Positionsabweichung: Gering

Automotive

• Anwendungen ergleichbar mit der Dynamik eines PKWs
• Annahme geringer vertikaler Beschleunigungen
• Max Höhe: 5000m
• Max Geschwindigkeit: 223,2 km/h
• Max vertikale Geschwindigkeit: 54 km/h
• Gültigkeitsüberprüfung: Höhe & Geschwindigkeit
• Maximale Positionsabweichung: Mittel

Vielleicht versuche ich mal unter einem 5 Sek. Log meine Teststrecke unter beiden Modi einmal abzulaufen. Mal sehen ob da was geglättet wird. Beim WBT201 gab es ja entsprechende Berichte:
[BT] Wintec WBT-201 Genauigkeit ok?

Im Produktiveinsatz bleibe ich aber derzeit bei den im letzten Beitrag erwähnten Genauigkeitseinstellungen, also im Modus Automotive.

Viele Grüße,
Chris

Hallo Chris,

Platform Settings steht fast genau so n der ublox5-Protocol-Speci. Übrigens gibt es auch eine Antaris-Protocol-Spezi, lade die auch mal - hoffe es gibt sie noch - da steht manches zum Vergleich. Auch interessant, GPS-Basics_(GPS-X-01006).pdf und das Manual zu ucenter. Überhaupt sind auf der ublox-Seite massig interessante Unterlagen zu finden.

Jean-Marie Zogg ist

University of Applied Sciences HTW Chur
Fachhochschule für Technik und Wirtschaft HTW Chur
Department: Telecommunication and Electrical Engineering

Professor for Electronics, Electrical Engineering and Mobile Computing
Speciality: GPS (Global Positioning System), GNSS (Global Navigation Satellite Systems), Galileo, Satellite Communication, Scilab

und betreibt an der HTW Chur eine GPS-Referenzstation... Google mal...