iblue 747a+ : ungenaue Position durch Handy Strahlung ?

Zitat

Original von HSVMichi

Also zusammen gefasst: wenn ich "meine" Zeitzone verlasse, bin ich verlassen (keine Beziehung der geloggten Zeit zu einer bestimmten lokalen Zeit).

Ich wüßte auch gar nicht, wie das anders gehen sollte. Man hat zwar die Position aber es müßte ja immer noch hinterlegt sein, wo gerade auf der Welt Sommer-/ Winter- oder sonstige Zeit herrscht.

Und das müßte dann wohl über einen Internetzugriff realisiert werden. Wobei das für eine direkt implementierung zu kompliziert wäre. Aber für einen nachträglich Automatismus wäre es vielleicht keine schlechte Idee. So wie man heute z.B. in bt747 eingibt, dass man sich UTC+2 befindet.

Gruß Carsten

Zitat

Original von HSVMichi

Die Norm lasse ich mal außen vor: früher gab es Kilokalorien; heute misst man das Gleiche in KiloJoule.

Aber bitte doc h.

Und nicht vergessen: auch das ist Norm, und es sind nicht die einzigen Einheiten die umgestellt wurden. Außerdem gibt es zwischen diesen Einheiten eine feste Beziehung, dargestellt durch eine (Umrechnungs-) Konstante. Da gibt es keine Abweichung ob ich in D, F, Europa , Asien oder Amerika bin. Auch das ist ein Weltstandard. Zumindest unter den Physikern, wenn wir diejenigen Engländer mal außen vor lassen, die mmer noch auf Zoll, Yard, Pound etc verharren. Aber so weit müssen wir ja garnicht gehen, das (Gewichts-) Pfund ist auch keine Einheit in diesem Sinne mehr, und trotzdem sagt kaum einer "ein halbes Kilo"...

Wobei wir das nicht weiter vertiefen wollen, denn es heißt Kilopound und nicht Kilogramm.... Wobei, auf der Erde ist es im Durchschnitt und allgemeinen das Gleiche... :gap Aber ich will jetzt nicht auch noch den Unterschied zwischen Masse und Gewicht erläutern...

Nein, hat uns bei der Umstellung auf SI-EInheiten damals viele Mühe bereitet - und macht es heute noch.

Zitat

Die NMEA Datei, die bt747 schreibt und die Du zur Verfügung gestellt hast, ist aber ebenfalls fehlerhaft:

1) Die RMC Zeilen hören mit einem "A" Feld auf (vor der Prüfsumme)! Das ist falsch. Beispiel:

Code

$GPRMC,105009.653,A,5220.275826,N,01301.220943,E,4.306,,060609,,,A*41

http://home.mira.net/~gnb/gps/nmea.html#gprmc :
" for NMEA 0183 version 3.00 active the Mode indicator field is added"

Hi le_top,

danke, das ist sehr interessant. In dieser Auflistung stehen mehr Prtokolle, als ich bisher hatte (NMEA.de, kowoma, Rest weiß ich nicht mehr). Eben auch einige exotische, die vorwiegend von Garmin etc. benutzt werden.

Das Indikator-Felld in RMC ist allerdings in u-center schon gelistet, ebenso in kowoma.

Andreas: tut mir leid, wenn ich mir RMC näher angeschaut hätte, hätte mir das auffallen müssen.

Hallo Charly,

braucht Dir nicht Leid tun, habe das "neue" Feld kurz drauf, nachdem ich meinen Beitrag geposted habe, ebenfalls gefunden.

Das wirklich doofe ist, dass das NMEA Protokoll nicht wirklich frei dokumentiert ist, da man für den Standard zahlen muss. Alles was man so frei findet (ich zumindest), sind teilweise recht vage/unvollständige Beschreibungen insbesondere über die Semantik der einzelnen Werte.

Ausserdem scheinen sich auch die Versionsangaben zu widersprechen. Nach meinen Recherchen wurde das FAA Mode Indicator Feld bereits mit der Version 2.3 eingeführt.

In NMEA 2.3, several sentences (APB, BWC, BWR, GLL, RMA, RMB, RMC,
VTG, WCV, and XTE) got a new last field carrying the signal integrity
information needed by the FAA.  (The values in the GGA mode field were
extended to carry this information as well.) Here are the values:




FAA Mode Indicator
     A = Autonomous mode
     D = Differential Mode
     E = Estimated (dead-reckoning) mode
     M = Manual Input Mode
     S = Simulated Mode
     N = Data Not Valid




This field may be empty.  In pre-2.3 versions it is omitted. [NTUM] says
that according to the NMEA specification, it dominates the Status field --
the Status field will be set to "A" (data valid) for Mode Indicators A
and D, and to "V" (data invalid) for all other values of the Mode
Indicator.  This is confirmed by [IEC].

Grüße

Andreas

Hallo Andreas,

V2.3 ist auch von mir so gefunden.

Ja, schade, dass NMEA nicht wenigstens die Protokollerklärung frei veröffentlicht. So ist man wirklich darauf angewiesen zu suchen. So hatte ich vor Jahren, als ich mal die Garmin-Protokolle angeschaut habe, einfach über den /die Protokollnamen im Internet gesucht. War erstaunt, dass dabei doch sehr viel zu finden war. Ist aber tatsächlich mühevoll und geht halt auch nur für Protokolle, deren Namen man schon hat.

Das fatale dabei: wenn man mal eine Protokollerkärung hat, sucht man nicht wirklich immer mal wieder ob sich was geändert hat. So bin ich auf zusätzliche Felder (V2.3) auch nur gestoßen bei meiner Log-Untersucherei, als ein log auftauchte, das in einzelnen Protokollen mehr Felder hatte als mir bekannt war.

Und NMEA.de hat z.B. RMC noch nicht erweitert, resp.die Erklärung "E or W" ist falsch.

Äh, gibst Du mir mal den Link per Mail/PN für die gepostete Erklärung? Kommt mir so auf Anhieb unbekannt vor.

Zitat

Original von HSVMichi
OT - sorry

Da hast Du aber mächtig was durcheinander gewürfelt. Oder meintest Du Kilopond?

Na ja. Sowohl als auch.

Aber Du hast schon Recht, die deutsche Bezeichnung wäre sinnvoller gewesen.

Zitat

Original von karomue
Äh, gibst Du mir mal den Link per Mail/PN für die gepostete Erklärung? Kommt mir so auf Anhieb unbekannt vor.

Hallo Charly,

schau mal HIER

Grüße

Andreas

Zitat

Original von omega

Hallo Charly,

schau mal HIER

Grüße

Andreas

Alles anzeigen

Danke, in die Sammlung aufgenommen (bei der ich eh nicht mehr durchblicke :gap ).

Es scheint aber so, als ob ich das noch nicht gehabt hätte...

Zitat

Original von omega

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....

Kann es nicht auch sein, daß Du sehr leicht beleidigt reagierst? Ich kann nämlich nichts beleidigendes daran erkennen, wenn ich lediglich darauf hinweise, daß man mit dem Steine schmeißen vorsichtig sein soll, wenn man im Glashaus sitzt.

Es geht bei der Validierung von GPX (und damit ist eigentlich xml gemeint) nicht um igendwelche Teile einer Datei, sondern darum, ob eine Datei als ganzes korrekt und damit validierbar ist. Und wie ich schon schrieb weist die Fehlermeldung bei der Validierung darauf hin, daß selbst wenn man die Extension-Zeilen aus der Datei herausnehmen würde, das Ergebnis kein validierbares XML/GPX Format ist.

Das von mir zitierte Robustheits Prinzip (Postel's Law) führt sicherlich dazu, daß gut programmierte Programme auch schlechte GPX Dateien verarbeiten können, nur sollte man das nicht als Entschuldigung nehmen, schlechte Dateien zu produzieren.

Und was meinst Du mit "am selben Tag"? Ich habe noch keine neue Version entdecken können, in der die von mir gemeldeten Probleme behoben sind?

Zitat

Das sollte man nicht tun: auch GPX schreibt vor, dass die Zeitstempel in UTC sein müssen.

Das weiß ich ja (ich dachte, das wäre aus meinem Posting ersichtlich). Das Format des Zeitstempels ist ja auch weiterhinn das für UTC, aber dennoch wird der Wert um den entsprechenden Offset korrigiert. Und um diesen Offset für einen Benutzer zu dokumentieren steht er halt im Kommentar, weil GPX keine offizielle Alternative bietet.

Wers nicht mag, muß die entsprechende Option ja nicht benutzen, es ist ja nur für die Bequemlichkeit.

Ciao,
Steffen