iblue 747a+ : ungenaue Position durch Handy Strahlung ?

Zitat

Original von Eumel153

VisualGPS habe ich und mit u-center komme ich noch nicht so zurecht. Ich fürchte, dass die Aussagefähigkeit auf dem Fensterbrett ohnehin etwas eingeschränkt ist. Sollte der Fehler allerdings dort auch auftreten, dann lasse ich mal VisualGPS mitlaufen. Dann sollte auch GSV und GSA dabei sein. Für eine Tour ist das aber ungeeignet, da ich nicht immer den Laptop mitschleppen kann.

Vermutlich werden aber erst wieder die nächsten Touren genauen Aufschluss geben. Von 3 Touren hatte ich bisher einen kurzen drastischen Höheneinbruch und einmal einen etwas Längeren. Beide Male mit deutlichen Positionsungenauigkeiten und Beide Male an sehr abgelegenen Orten. Die Mobilfunkverbindung könnte also schlecht gewesen sein.

Ich bin ja nur froh, dass mein Logger scheinbar nicht defekt ist. Jetzt habe ich Zeit den Fehler zu reproduzieren.

Gruß Carsten

Alles anzeigen

u-center ist das Auswertetool, vor allem auch wegen der vielfältigen Graphik. Im Artikel über die CR4-Maus und auf meiner HP steht schon mal was grundsätzliches über u-center, sonst einfach fragen.

Zu den Protokollen, da gibt es einen Thread, den ich leider nicht mehr benennen kann, der beschäftigte sich auch mit der Protokoll-Einstellung. War der nicht von Michi? Sollte unterm gleichen Forum stehen.

Zur Abweichung Deiner Tour: Du bist nicht zufällig irgendwie im Radarbereich eines Flughafens? Unter Hochspannungsleitungen gibt es übrigens auch merkwürdige Effekte.

Zitat

Original von HSVMichi

Warum?

Wurde halt so von NMEA festgelegt.... und, im übrigen, macht alles andere keinen Sinn, da man ja dann noch festlegen oder mitliefern müsste, welche Ortszeit den nun zur Anwendung kommen sollte.....

Andreas

Zitat

Original von omega

Wurde halt so von NMEA festgelegt.... und, im übrigen, macht alles andere keinen Sinn, da man ja dann noch festlegen oder mitliefern müsste, welche Ortszeit den nun zur Anwendung kommen sollte.....

Andreas

Erstaunlich, dass es immer noch Leute gibt, die SW für käufliche HW programmieren und von der ursprünglichen Konvention - wie z.B. hier von NMEA - offensichtlich keine Ahnung haben.

Wäre für mich ein Grund - wüßte ich es vorher - solch einen Logger nicht zu kaufen.

Natürlich ist es ein Problem, da jedes vernünftige Programm davon ausgeht, dass die Zeitstempel in einer NMEA Datei in UTC angegeben sind und dementsprechend diese in eine Lokalzeit umwandelt.

Wenn ich mit AVGPS so eine (falsche) NMEA Datei lese, stimmen halt einfach die Zeiten nicht mehr... und ich muss für den Track festlegen, dass dieser GMT ist, damit ich die richtige Zeit bekomme, obwohl er natürlich bereits in Lokalzeit ist.

Dadurch wird die komplette Zeitlogik verdreht.... und das nur, weil, wie Charly bereits sagte, Programmierer sich nicht an den Standard halten.

Andreas

Zitat

Original von HSVMichi
Hmm, ich erkenne das Zeitproblem immer noch nicht. Ist aber auch nicht weiter wild.

Ich jedenfalls bin froh, dass ich jetzt die Möglichkeit habe, die Logs mit "Originalzeit" (also die lokale Zeit, in der ich auch wirklich gefahren bin) zu schreiben. Und die Satellitenkonstellation wird mir in u-center auch anhand der geloggten daten angezeigt; also auch hier spielt die Uhrzeit doch überhaupt keine Rolle.

Vielleicht findet ja noch einer ein passendes Beispiel, wo die lokale Zeit Probleme macht...

Es ist schon wild. Du solltest Dich hier mal bei NMEA.de oder meinetwegen auch kowma schlau (-er) machen.

Es ist nun mal festgelegt, dass die Zeiten in den div. Protokollen in UTC anzugeben sind. Und ich will auch hier überhaupt nicht darüber nachdenken, was wäre, wenn ich in einer anderen Zeitzone Fotos gemacht hätte, wobei auch (am Ende der Reise z.B. noch Aufnahmen vom Flughafen im Lande - oder so -) dabei wären. Und in den Protokollen Ortszeit stände (welche denn??).

Wir liegen halt in UTC+1, im Sommer + 2. Gibst Du einem anderen z.B. ein log der in einem anderen Land wohnt, hätte der u.a. Probleme wenn die Zeit nicht (auf UTC) normiert wäre.

Das Ganze zählt einfach unter eine weltweite Normierung, wie es eben auch in NMEA genormt ist, WSG84 zu verwenden.

Mach doch mal den Spaß und erkundige Dich über das Schweizer Koordinatensystem, bei dem Bern (die Uni) auf 200000/600000 liegt. Dann wirst auch Du ( ) vielleicht erkennen, dass eine Normierung ihre Vorteile hat.

Ach ja, welche "Ortszeit" wird denn derzeit geschrieben? Sommerzeit? Die (alte) MEZ?

Schade, dass Du vorwiegend nach Norwegen und dso fährst und nicht z.B. an die Antlantikküste oder <England, wo schon ein Zeitzonenübergang überschritten wird. Was würde Dein Logger denn dann schreiben? Englische Sommer/Winterzeit? Hm, dort hätten wir ja Gleichstand mit UTC...

Zitat

Original von HSVMichi
Vielleicht findet ja noch einer ein passendes Beispiel, wo die lokale Zeit Probleme macht...

Hallo Michi,

bei jeder Änderung der Lokalzeit z.B. bei einem Transatlantik-Flug oder während der Nacht der Sommerzeit-Umstellung. Am Besten einen Transatlantik-Flug in der Nacht der Sommerzeit-Umstellung

Grüsse - Anton

Zitat

Original von HSVMichi
Vielleicht findet ja noch einer ein passendes Beispiel, wo die lokale Zeit Probleme macht...

Michi,

man braucht keine Beispiele um zu verstehen, dass es sinnlos ist Zeitstempel anzugeben, von denen niemand weiß, auf was sie sich beziehen.

Die Festlegung, dass alle Zeiten Lokalzeit sind, ist einfach Quatsch.
Man müsste dann auch den UTC Offset mit angeben, da man sonst nie eine Möglichkeit hätte, die Zeiten in eine andere Zeitzone zu verfrachten.

Ganz davon unberührt ist es einfach ein Bug, wenn Programme behaupten NMEA Dateien zu schreiben und sich einfach nicht an die NMEA Konvention halten, darüber kann man einfach nicht diskutieren. Dann müssen diese Programme ihr eigenes Format definieren (es hätte sicher noch ein paar Formate frei... :gap ).....

Grüße

Andreas

Hi Michi,

ich setz jetzt noch einen drauf, vielleicht hilft das:

Ich gehe mal davon aus, dass Du Dich nicht mit den SW-Entwicklern von Wintecs Gnaden identifizieren willst, bei denen wir über 1/2 Jahr gebraucht haben, sie davon zu überzeugen, dass das, was sie ursprünglich programmiert hatten, Essig ist und in keinster Weise NMEA zuzuordnen ist.

Und, davon hast Du mit Sicherheit gehört/gelesen: es gibt (auch heute noch in Gebrauch) Mäuse/Mäusehersteller, die den Zusammenhang zwischen Höhe und Geoidkorrektur sehr eigenwillig interpretiert hatten. Auch das ist eben NMEA-Konvention, und das Erstaunen war jedesmal groß, dass eine Maus rund 50 m daneben liegt...

Oh, hier ist ja richtig was los. Leider bin ich heute den Tag über nicht am Computer.

Ich hatte die Nacht über den Logger 13 Stunden auf dem Fensterbrett zu liegen, senkrecht und Antenne zum Raum. Keine Auffälligkeiten. Im Schnitt einen Radius der Punkte von 20m, bei ein paar wenigen Ausreißern bis 40m.
Ich werde es dann mal mit Handy probieren.

adisospl
Ein Teil der Probleme der bt747.bin könnten sich erklären. Scheinbar passt bt747 die Einstellungen schon in der *.bin an. Ich habe habe nämlich UTC+2 eingestellt. Wenn ich UTC+0 einstelle, dann wird mir als GPS Zeit auch die UTC Zeit angezeigt.
Ähnlich sollte es bei der Höhe aussehen. Da habe ich WSG84 nach MSL eingetragen. Zur Prüfsumme kann ich leider nichts sagen.
Ich schicke Dir gleich nochmal eine neue *.bin. Ich kann die nämlich nicht direkt ansehen.

P.S.: Ich sehe gerade, dass ich nachträglich gar nicht mehr an die *.bin herankomme. Ich werde das nächste Mal vor dem Auslesen auf UTC und Beibehaltung der Höhe einstellen.

SID, Azimuth und SNR werde ich mal probieren. Leider bleibt dann ncht mehr viel Logzeit.

quitschie
Das u-center werde ich mir mal genauer ansehen und die Threads auch.

Du hast übrigens Recht. Ich bin unter ein paar Hochspannungsleitungen durchgekommen. Aber das nicht zum ersten mal. Bisher ist mir da wenig negatives aufegfallen. Ich habe auch nicht so genau darauf geachtet.

Gruß Carsten

Zitat

Original von omega
Ganz davon unberührt ist es einfach ein Bug, wenn Programme behaupten NMEA Dateien zu schreiben und sich einfach nicht an die NMEA Konvention halten, darüber kann man einfach nicht diskutieren. Dann müssen diese Programme ihr eigenes Format definieren (es hätte sicher noch ein paar Formate frei... :gap ).....

Und das sagt ausgerechnet derjenige, dessen Programm GPX Dateien erzeugt, die sich nicht an GPX Konventionen halten (sprich: nicht validierbar sind)...

Und was nützt es, ein neues Format zu erfinden, wenn es niemand unterstützt?

Wenn ich mit meinen Tools die GPS Daten nach GPX konvertiere, um dann damit Fotos mit Geotags zu versehen, wobei die Uhr der Kamera auf die lokale Uhrzeit eingestellt ist, dann habe ich zwei Möglichkeiten:

Ich erzeuge eine GPX Datei mit UTC Zeiten, dann muß ich dem Programm fürs Geotagging den Offset zwischen UTC und der Uhr der Kamera manuell mitteilen (und den Offset erst einmal herausbekommen).

Oder ich ermittle die Zeitzone automatisch aus den GPS Koordinaten (das mache ich anhand der Position und der Zeit des ersten Punktes im Log und gehe davon aus, daß der ermittelte Offset zu UTC über das gesamte Log konstant bleibt. Wenn sich die Uhr in der Kamera automatisch bei Sommerzeit umstellt und der Log über diesen Umstellungszeitraum geht, dann funktioniert es natürlich nicht, aber ich denke die meisten Kameras machen das eh nicht) und schreibe dann die lokalen Zeiten in die GPX Datei und das ist Geotagging automatisch korrekt.

Leider unterstützt der GPX Standard keine Zeitzonen, so daß mir nur bleibt, den Offset in die Beschreibung zu setzen, so daß man zumindest beim Anschauen des Inhalts sieht, daß die Zeiten gewandelt wurden, aber eigentlich entspricht die Datei semantisch nicht dem GPX Standard (syntaktisch natürlich schon und was interessiert es GPX, ob ich zwei Stunden früher oder später an einem Punkt war

Für NMEA gilt das gleiche, nur das ich dort nicht einmal die Zeitzone als Kommentar ablegen kann.

Ciao,
Steffen

Zitat

Original von siebert

Und das sagt ausgerechnet derjenige, dessen Programm GPX Dateien erzeugt, die sich nicht an GPX Konventionen halten (sprich: nicht validierbar sind)...

Du hattest schon immer hier eine leicht beleidigende Art.... mehr als Fehler rausmachen, wenn man sie mir sagt (und das noch am gleichen Tag) kann ich auch nicht. Und das meine privaten GPX Extension nicht validierbar sind geht jedem ordentlich programmierten Programm an seinen fünf Buchstaben vorbei....

Zitat

Und was nützt es, ein neues Format zu erfinden, wenn es niemand unterstützt?

War als Witz gemeint.... siehe Smiley....

[/quote]
Wenn sich die Uhr in der Kamera automatisch bei Sommerzeit umstellt und der Log über diesen Umstellungszeitraum geht, dann funktioniert es natürlich nicht, aber ich denke die meisten Kameras machen das eh nicht) und schreibe dann die lokalen Zeiten in die GPX Datei und das ist Geotagging automatisch korrekt.
[/quote]
Das sollte man nicht tun: auch GPX schreibt vor, dass die Zeitstempel in UTC sein müssen.

Zitat

Auszug aus dem GPX 1.1 Standard
Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs.

Andreas