Beiträge von Ronaldone

    Zitat

    Unterwegs war ich im Wiener Schloßpark Schönbrunn, von völlig freier Sicht bis tiefstem Wald sowie 1x mit dem Auto in Süden von Wien.


    Google Earth in Wien und Umgebung liegt definitiv daneben, ist mir auch schon länger aufgefallen. Nebenbei, auf www.flashearth.com unter "Ask.com (aerial)" gibts wesentlich bessere Luftbilder von Wien als auf GE. Auch mit Koordinatenangaben.

    Mir ist der Sachverhalt bisher nicht aufgefallen, weil ja offensichtlich die Auswertprogramme, die ich benutze (z.B. Gartrip) die Geschwindigkeit aus Zeit und Position selbst errechnen. Zum Beispiel war ich zu folgendem Zeitpunkt laut Gartrip mit 823 km/h unterwegs:


    $GPRMC,130000.000,A,4215.2520,N,02213.7855,E,188.00,0.00,190707,,*02


    Also ist dieser offensichtliche Fehler kein Problem für mich. Gott sei Dank, einmal kein Problem!

    Zitat

    Original von 900SS-97
    Aber der Empfaenger gibt im Feld9 die Hoehe ueber Geoid an,


    Wie macht er das eigentlich, wenn er nichts über das Geoid weiß? Es haben doch nicht alle GPS Empfänger Geoidhöhen-Tabellen und Interpolationsalgorithmen, oder doch? Ich bin wirklich sicher, dass die Fortuna Clip-On Ellipsoidhöhen ausgibt. Ich war auf etlichen Berggipfeln damit und hab's mit den Karten verglichen (auch wenn unsere österreichischen Karten die Höhe über Triest angeben und nicht über Amsterdam ;))

    Zitat

    Original von karomue
    Also besorge Dir eine vernünftige Topographische Karte mit WGS84 und einem Bezugspunkt NN und nicht "Wiener-0 über Adria-0". Wer sagt denn, dass Adria-0 = NN ist?


    Natürlich ist Adria Null nicht gleich NN, der Unterschied macht allerdings max. 30 cm aus, also ganz entscheidend für dieses Thema...
    Und zeig mir mal eine Karte, in der die Höhen auf 0,1 m genau eingetragen sind - so wie in der von mir angesprochenen Karte. Die übrigens sicher als topografisch zu bezeichnen ist und eindeutig definierte orthometrische Höhenangaben beinhaltet. Was will man mehr. Und diese Höhenangaben stimmen im Rahmen der GPS Ungenauigkeit gut mit den korrigierten Höhen von OziCE in Zusammenarbeit mit der Fortuna Clip-On überein. Jedenfalls eindeutig besser als mit den unkorrigierten. Ist das wirklich nicht zu sehen?


    Die Frage ist nach wie vor, woher kommt die Korrektur? Aber ich erwart mir eh keine Antwort mehr. Wenn ich das nächste Mal auf Reisen gehe, werde ich genauer schauen, ob die Korrektur von OziCE konstant ist, oder doch auf mysteriöse Weise von der Fortuna gesendet wird.

    Zitat

    Original von 900SS-97
    [...]ob da evtl. ein Fehler im LogFile vorliegen kann. Denn wenn ich jetzt keinen Knick im Gehirn habe, dann ist das LogFile mit etwa 210/220Meter so wie Ozi das auch anzeigt. Allerdings sehe ich die dazu gehoerigen Koordinaten nicht am adriatischen Meer, sondern in Wien im Bereich des Hochstrahlbrunnen.


    Ja, natürlich zeigen beide Logs den Bereich des Wiener Hochstrahlbrunnens, ich war ja schließlich da :), da ist schöne freie Sicht auf den Himmel. Wieso soll da ein Fehler im Logfile vorliegen? Außerdem habe ich das beschriebene Verhalten ja dauernd beobachtet und kann es jederzeit wiederholen, auch mit der iTrackU Maus. Aber die sendet ja die Geoid-Korrektur, da wundert es einen nicht.


    Die einzige Erklärung ist wohl, dass Des Newman (Ozi-Entwickler) diese ca. 43 m Korrektur fix einprogrammiert hat (vielleicht nur dann, wenn das NMEA Feld leer ist?), das ist nämlich auch ungefähr der Wert für Brisbane, wo er offenbar lebt. Man müsste mal Urlaub in Miami Beach machen, oder so, um den Gegenbeweis anzutreten... Tatsächlich bilde ich mir ein, dass die korrigierten Werte in OziCE auf meinen Reisen immer gepasst haben, aber so genau kann ich das jetzt nicht sagen.


    Oder gibt es irgendeinen anderen Weg, auf dem die Fortuna Maus Korrekturdaten an OziCE senden könnte? Warum heißt denn das "Apply SIRF Altitude Correction"?


    P.S: Die Höhe habe ich übrigens aus dieser "1:5.000" Wien-Karte (www.wien.at), wo die Höhen über "Wiener Null" angegeben sind. Und das Wiener Null ist 156,680 m über dem Adria Null. Also über dem adriatischen Meer - ist halt das nächste Meer von hier.

    OK, habe folgendes gemacht:


    An einer Stelle, deren Höhe über dem adriatischen Meer ich kenne (171 +-1 m) habe ich im OziCE einen Track aufgezeichnet (musste mich bewegen, weil OziCE mindestens 1 m Weg für Trackpunkte braucht - oder gibt es da einen Trick das zu umgehen?). Anbei als ceTrack.plt.


    Außerdem wurde von GPSGate ein NMEA-Log mitgeschrieben. Anbei als GPSGate_Log.nmea. Dort sieht man, dass keine Geoid-Korrektur geliefert wird.


    Zusätzlich habe ich dieses NMEA-Log mit GPSBabel ins Ozi-Format konvertiert und in Gartrip zusammen mit dem ceTrack.plt dargestellt. Siehe "Vergleich OziCE-NMEA.gif". Da ist dann wohl klar, dass Ozi die Höhe richtig ausgibt, während das NMEA-Log 43 m darüber liegt. Aber woher weiß Ozi, dass es korrigieren muss, und um wie viel? Übrigens ist auch noch ein Screenshot anbei, der zeigt, was ich in OziCE einstelle, um die Korrektur zu bekommen. Ohne diese Einstellung (das obere Häkchen) gibt es keine Korrektur, NMEA und ceTrack.plt liefern dann die gleichen Höhen. Das müsst ihr mir jetzt einfach glauben.

    >>Hast Du das mit dem leeren Feld selbst bei Deinem Empfaenger getestet, oder das aus der Tabelle gelesen?<<
    Ich sehe zum Beispiel das am PDA bei Verbindung mit der Fortuna Maus:
    $GPGGA,120855.490,4810.4815,N,01625.6010,E,1,04,12.5,205.3,M,,,,0000*3D
    Die angezeigte Höhe in Ozi ist dabei 162 m (was ungefähr der "Seehöhe" entspricht), "Apply SIRF Altitude Correction" ist aktiviert.


    >>Aendert sich denn die Hoehenanzeige in Ozi wenn Du "Apply SIRF Altitude Correction" aktivierst/deaktivierst?<<
    Ja, die Höhenanzeige ändert sich sofort, in beide Richtungen, je nachdem ob ich aktiviere oder deaktiviere.


    >>Kannst Du mal ein LogFile an einer moeglichst bekannten Hoehe erstellen und hier posten? <<
    Siehe oben. Oder genügt diese Zeile nicht?

    Zitat

    Die empfangen halt die GPS-Zeit (UTC).


    Nun ja, GPS-Zeit ist nicht gleich UTC, oder? Weil sie nämlich keine Schaltsekunden berücksichtigt hat. Ich frage mich gerade, ob all die Programme, die angeblich die Uhrzeit von Computern und PDAs von einem GPS Empfänger einstellen, diese Differenz (derzeit 14 Sekunden?) berücksichtigen. Oder rechnen die Empfänger schon von GPS-Zeit auf UTC um und geben daher von vornherein UTC aus?


    Jedenfalls wird wohl jeweils die Software (im Betriebssystem eingestellte) Zeitzonen berücksichtigen, um Ortszeit darzustellen.

    Die mitgelieferte Software ist ja wirklich erbärmlich. Ich hoffe für alle, die dieses Gerät erstanden haben, dass sie irgendwie in dieses Forum finden und dann hoffentlich auch den Link für die Alternativsoftware (derzeit http://www.dealcat.de/download/itracku.zip). Fragt sich nur, was die armen Menschen tun, die nicht deutsch sprechen.


    Nun zu dem iTrackU-Tool. Keine Ahnung welche Motivation hinter der Erstellung steckt, falls der Autor aber an Rückmeldung interessiert ist, hier mein Beitrag.


    - Ein Knopf, der Daten unwiederbringlich löscht, sollte eine Rückfrage beinhalten. Stell dir vor, du kommst von zwei Wochen Urlaub zurück, willst die Daten aus dem iTrackU downloaden und drückst versehentlich daneben, nämlich auf "iTrackU leeren" statt auf "LogAuslesen". Da sollte man schon gefragt werden, ob man das wirklich will, auch wenn solche Rückfragen oft nerven.


    - Ich brauche das "RAW" Format praktisch nie, habe aber nicht die Möglichkeit, die Erstellung dieser Datei zu unterbinden.


    - Die .ini-Datei enthält wenig mit dem man was anfange könnte. Gibt's da irgendwo eine Doku?


    - Wichtig wäre mir Einfluss auf die Dateinamen, mit dem derzeitigen Format kann ich gar nichts gescheites anfangen. Beim Datum sollte ein Format wie Jahr-Monat-Tag verwendet werden. Aber ich kann's natürlich auch immer händisch machen.


    -Die Klänge sind teilweise eher nervig, habe sie durch andere ersetzt. Das ging problemlos (Originale durch kurze 8-bit, 8 kHz WAV-Dateien ersetzen, <Einst. Speichern>). Allerdings klingen die 8-bit Dateien schlecht, vielleicht probier ich einmal ob 16-bit auch funktionieren.


    -Was bedeutet der untere, normalerweise nicht sichtbare Teil im Bediendialog?


    Bis dann

    Hallo,


    es scheint so zu sein, dass sowohl die im iTrackU geloggten als auch die per Bluetooth ausgegebenen Höhenangaben bereits korrigiert sind, d.h. die Angaben beziehen sich auf Meeresniveau und nicht auf das WGS84 Geoid. Zumindest weisen alle meine aufgezeichneten Daten darauf hin. Hier in Wien gibt das iTrackU übrigens eine Geoid-Höhe von 43,4 m aus.


    Kann das jemand aus Erfahrung bestätigen? Oder gibt es diesbezüglich sogar Information vom Hersteller (was allerdings bei dem miesen Support höchst unwahrscheinlich ist)?


    -Ron.