GPS Höhenangabe falsch

[Temar]

Erstmal schön, dass wir es doch nocht geschafft haben uns zu verständigen

Android fällt nun total aus der Reihe. Es liefert einen um 46 Meter falschen Höhenwert und auch keinen Korrekturwert ('Höhe Geoid minus Höhe Ellipsoid'). Offenbar findet im Android keine Geoidkorrektur statt, sondern es wird einfach der Wert des WGS84-Referenzellipsoids ausgegeben. Na super! :-( Was ist denn das für ein Murks-GPS!? Höhenmäßig kann man das Gerät also in die Tonne treten. Es sei denn, man weiß immer, wie gerade die Geoid-Korrekturwerte an der aktuellen Position sind. Da ist also dringend etwas zu tun und es sollte schleunigst eine Geoidkorrektur eingebaut werden...

Das ist genau der Grund warum ich sagte, dass du eigentlich die GPS-Firmware patchen müsstest. Android ist kein GPS-Empfänger, sondern ein Betriebssystem. Es ist nicht die Aufgabe von Android irgendwelche Korrekturen an den GPS-Daten vorzunehmen. Das ist der Job des GPS-Moduls, welches auch den Rest der Berechnungen durchführt. Da du die GPS-Firmware nicht austauschen kannst bleibt dir nur die Möglichkeit dein eigenes Rom zu bauen.

 

[fipsy]

Erstmal schön, dass wir es doch nocht geschafft haben uns zu verständigen

Ja, ich war etwas voreilig mit einigen Einschätzungen. Das Thema ist aber auch nicht so ganz trivial.

Das ist genau der Grund warum ich sagte, dass du eigentlich die GPS-Firmware patchen müsstest. Android ist kein GPS-Empfänger, sondern ein Betriebssystem. Es ist nicht die Aufgabe von Android irgendwelche Korrekturen an den GPS-Daten vorzunehmen. Das ist der Job des GPS-Moduls, welches auch den Rest der Berechnungen durchführt. Da du die GPS-Firmware nicht austauschen kannst bleibt dir nur die Möglichkeit dein eigenes Rom zu bauen.

Naja. Der "GPS-Empfänger" im Handy ist offenbar ein fertiger Chip, der nur die Höhe des Referenzellipsoids nach WGS84 liefert. Ich glaube, das tun alle fertigen GPS-Chips. Bin mir aber nicht sicher. Derjenige, der sie verbaut, ist dann eigentlich dafür verantwortlich, die Daten durch Zusatzsoftware entsprechend zu korrigieren. Deshalb könnte man jetzt darüber streiten, ob der Hersteller des GPS-Bausteins in seiner Firmware diese Aufgabe erfüllen muss, oder ob dies nicht viel eher ein Treiber im Android Betriebssystem erledigen muss. Ich tendiere zu letzterem, denn die Geoid-Korrekturdaten können sich im Laufe der Zeit ändern (z.B. durch Erdbeben u.ä.). Wenn die Geoid-Korrektur im GPS-Chip verbaut wird, kann man aber nichts mehr daran ändern. Deshalb sollte das wohl eher eine änderbare Software tun, also das Betriebssystem.

Mit einem einfachen "Patch" ist es da auch nicht getan, denn es muss ja das komplette WGS84 Geoid-Korrekturraster inklusive einer Interpolationsroutine implementiert werden. Also ein richtiges Stück Software. Ich denke schon, dass da die Android-Programmierer gefragt sind und weniger der Hersteller des GPS-Bausteins. So schwierig dürfte das nicht sein, denn die Korrekturdaten kann man sich im Internet ziehen und entsprechende Interpolationsroutinen ebenfalls.

Tschö, Volker

 

[Reiner]

Ich hab mir lange Zeit bevor ich mir mein Magic gekauft habe meine ziemliche genaue Höhe ausgerechnet in meinem Wohnzimmer.

Ich kam zu dem Schluß, wenn ich mich hochstrecke auf die Deckenhöhe meines Wohnzimmers müßte ich exakt 500m erreichen.

Wenn ich auf der Couch liege zeigt mir mein Magic 497m an.
Also entweder ca. 1m Ungenauigkeit oder 1m Rechenfehler von mir.

 

[fipsy]

Wenn ich auf der Couch liege zeigt mir mein Magic 497m an. Also entweder ca. 1m Ungenauigkeit oder 1m Rechenfehler von mir.

Ein Meter Genauigkeit in der Höhe ist schon EXTREM gut beim GPS-System! Also damit solltest du zufrieden sein. Wie sieht es denn an anderen Stellen aus? Ist da die Genauigkeit auch so gut? Oder verlässt du deine Couch nicht? *lach*

Wenn die HTC-Geräte im Gegensatz zu Motorola eine korrekte Höhenangabe liefern, obwohl sie das selbe Betriebssystem nutzen, dann korrigiert entweder die von dir verwendete Software die Höhenangabe (welche nimmst du zur Höhenmessung?), oder HTC verbaut ein anderes GPS-System als Motorola, welches die Geoidkorrektur beherrscht.

Es ist schon alles höchst seltsam! Was sagst du den dazu, Temar?

Gruß, Volker

 

[Reiner]

@Fipsy,

ich habs mit verschiedenen apps probiert.
Es ist zwar etwas träge wen ich von unserem Berg runterfahre, aber dann komm ich auch auf ungefähr korrekte 350m.

 

[Temar]

Wenn die HTC-Geräte im Gegensatz zu Motorola eine korrekte Höhenangabe liefern, obwohl sie das selbe Betriebssystem nutzen, dann korrigiert entweder die von dir verwendete Software die Höhenangabe (welche nimmst du zur Höhenmessung?), oder HTC verbaut ein anderes GPS-System als Motorola, welches die Geoidkorrektur beherrscht.

Es ist schon alles höchst seltsam! Was sagst du den dazu, Temar?

Das ist genau das was ich vermutet habe. Das GPS-Modul/Treiber korrigiert bei manchen Geräten die Höhenangabe korrekt. Daher darf sich Android da auch nicht einmischen und weitere Korrekturen vornehmen.

Egal ob es jetzt am Treiber oder am GPS-Modul liegt, das Ergebnis ist das selbe. Auch den Treiber wird man in der Regel nicht anpassen können, da die GPS-Berechnungen garantiert in einem Binary-Blog erledigt werden. Soll heissen, dass der Basis-Treiber an sich zwar oftmals OpenSource ist, die eigentliche Arbeit wird allerdings von einer Firmware erledigt, die vom Treiber geladen wird und nur binär vorliegt. Das ist ein beliebtes Verfahren von Herstellern um die GPL auszuhebeln.

Als letzte Möglichkeit bleibt also nur Android per Hand zu patchen und ein Custom-Rom zu bauen. Sollte an sich nicht zu schwer sein, da die Daten ja alle vorliegen und man im wesentlichen nur den aktuellen Wert aus einer Tabelle auslesen und abziehen muss. Wenn man einmal so nen Patch hat, dann kann man den ja auch den Rom-Entwicklern zur Verfügung stellen, so dass diese ihn dann in ihre Roms einbauen.

Hat jemand vielleicht mal nen Link zu den Korrekturtabellen? Wo kann man das Zeug denn runterladen?

 

[fipsy]

Auch den Treiber wird man in der Regel nicht anpassen können, da die GPS-Berechnungen garantiert in einem Binary-Blog erledigt werden. Soll heissen, dass der Basis-Treiber an sich zwar oftmals OpenSource ist, die eigentliche Arbeit wird allerdings von einer Firmware erledigt, die vom Treiber geladen wird und nur binär vorliegt. Das ist ein beliebtes Verfahren von Herstellern um die GPL auszuhebeln.

Jo, das macht sogar schon die DBox von Nokia so und die ist bald 10 Jahre alt. Die Hersteller spezieller Hardware wollen halt ihre Routinen nicht offenlegen. Warum auch immer...

Als letzte Möglichkeit bleibt also nur Android per Hand zu patchen und ein Custom-Rom zu bauen. Sollte an sich nicht zu schwer sein, da die Daten ja alle vorliegen und man im wesentlichen nur den aktuellen Wert aus einer Tabelle auslesen und abziehen muss. Wenn man einmal so nen Patch hat, dann kann man den ja auch den Rom-Entwicklern zur Verfügung stellen, so dass diese ihn dann in ihre Roms einbauen.

Ich verdiene meine Brötchen zwar als Software-Entwickler, aber meine Welt ist Windows und Visual Studio ;-). Mit Android habe ich mich noch nie beschäftigt. Ich weiß nicht, wie die Entwicklungsumgebungen da aussehen und vor allem, in welcher Sprache gearbeitet wird (Java?). Der Code zur Geoidkorrektur sollte die leichteste Hürde sein. Ist ja nur eine lineare Interpolation im dreidimensionalen Raum, also ein bisschen Vektorrechnung.

Wenn du da tätig werden willst, empfehle ich dir die Seite von Earth-Info (http://earth-info.nga.mil). Das ist der Ableger des US-Militärs, der das GPS-System betreibt. Die sind äußerst freigiebig mit ihren Daten. Dort gibt es umfangreiche Quellen, die keine Wünsche offen lassen: NGA: EGM2008 - WGS 84 Version. Ganz trivial ist es trotzdem nicht. Entweder benutzt man die harmonische Synthese mit Hilfe einer realtiv kleinen Koeffizientenmatrix oder man benutzt die einfache Interpolation mit Hilfe eines Geoid-Rasters. Die harmonische Synthese ist - bezogen auf die größe der Basisdaten - genauer als die Interpolation. Entweder nimmt man also die kleine Koeffizientenmatrix und die harmonische Synthese, oder ein enges Geoid-Raster (bis auf 1x1 Minute genau - das ist aber etwa 800 MB groß) und dann die einfache Interpolation. Man muss sich also für eine Kombi aus Rastergröße und Berechnungsverfahren entscheiden. Leider(?) sind die Quellen in Fortran, wie das früher so üblich war. Aber vielleicht hat ja der eine oder andere im Studium noch Fortran gelernt, so wie ich *lol*.

Gruß, Volker

 

[Temar]

Habe mir die Seite mal angeschaut.

... die harmonischer Synthese mit Hilfe einer realtiv kleinen Koeffizientenmatrix ...

Die "kleine Koeffizientenmatrix" ist entpackt leider auch schon 231MB. Dazu kommen noch die Daten vom Korrekturmodell, die nochmal 135MB gross sind.

Irgendwie kann ich mir nicht vorstellen, dass ein altes Nokia-Handy knapp 400MB an Daten für GPS-Höhenkorrekturen enthält. Da muss es irgendwie ein vereinfachtes Modell geben, welches dann eben etwas ungenauer ist. Bei solchen Größen kann man die nachträgliche Integration in "defekte" Android-Handys auf jedenfall vergessen.

Vielleicht sollten wir die Daten einfach im grossen Maßstab interpolieren und und dann auch nur die Landmasse berücksichtigen. Ob das dann noch sinnvolle Werte gibt ist halt die Frage. Was meinst du?

 

[fipsy]

Die "kleine Koeffizientenmatrix" ist entpackt leider auch schon 231MB. Dazu kommen noch die Daten vom Korrekturmodell, die nochmal 135MB gross sind.

Irgendwie kann ich mir nicht vorstellen, dass ein altes Nokia-Handy knapp 400MB an Daten für GPS-Höhenkorrekturen enthält.

Nee, ganz sicher nicht ;-). Ich habe irgendwo gelesen, dass die ein 10-Grad-Raster verwenden. Gegenüber dem 2,5-Grad-Raster ist das schonmal eine Datenreduzierung um den Faktor 16. Das ist dann am Äquator zwar deutlich ungenauer, als in Richtung Pol, aber so hoch ist die GPS-Genauigkeit ja eh nicht. Bei dem 1-Grad-Raster, das die US-Behörde im Angebot hat, geben sie eine Höhengenauigkeit von 1 Millimeter(!!!) an. Das ist natürlich für unsere Anwendung völliger Unsinn.

Ich habe bisher nirgendwo gröbere Rasterdaten finden können. Eventuell müsste man mit dem Extraktionsprogramm der Militärbehörde aus dem hochauflösenden Raster einfach eine Untermenge extrahieren, die Genauigkeit (Bitbreite) der Werte reduzieren und in eine neue Datei schreiben. Aus dieser könnte man dann die Daten zur Interpolation holen.

Bei einem 10-Grad-Raster, das den Bereich von 70 Grad südlicher bis 70 Grad nördlicher Breite abdeckt, hätte man dann 540 Werte. Bei einer Auflösung von 16 Bit pro Wert sind das 1080 Bytes. Da könnte man sogar problemlos die Bereiche bis zu den Polen abdecken, oder vielleicht auch das Raster noch ein bisschen engmaschiger machen.

Man müsste sich nur mal hinsetzen und das durchziehen ;-).

Gruß, Volker

 

[Temar]

Ich habe irgendwo gelesen, dass die ein 10-Grad-Raster verwenden. Gegenüber dem 2,5-Grad-Raster ist das schonmal eine Datenreduzierung um den Faktor 16.

Du hast dich aber bei den 2.5 Grad verlesen - es ist ein 2.5 Minuten Raster. Ein 10 Grad Raster wäre dann eine Datenreduktion um 57600. Daher meine Frage ob das dann noch sinnvolle Werte ergibt.

Bei einem 10-Grad-Raster, das den Bereich von 70 Grad südlicher bis 70 Grad nördlicher Breite abdeckt, hätte man dann 540 Werte. Bei einer Auflösung von 16 Bit pro Wert sind das 1080 Bytes. Da könnte man sogar problemlos die Bereiche bis zu den Polen abdecken, oder vielleicht auch das Raster noch ein bisschen engmaschiger machen.

Jo, ich denke alles unter 1MB ist in Ordnung für die Rom Entwickler. Mit einem 1 Grad Raster hätten wir 64800 Werte, somit ca 128 kb an Daten. Das könnten wir also sogar noch 8 mal genauer machen. Auf der anderen Seite wäre es schön wenn man die Werte nicht in einer Datei, sondern direkt als statische Tabelle im Code hinterlegt. Da wären die 128 kb Speicher bei einem 1 Grad Raster schon noch akzeptabel. Ein 1 Grad Raster deckt aber zumindest am Äquator ca. 12000km^2 ab. Fraglich ob da noch sinnvolle Werte rauskommen.

 

[fipsy]

Du hast dich aber bei den 2.5 Grad verlesen - es ist ein 2.5 Minuten Raster. Ein 10 Grad Raster wäre dann eine Datenreduktion um 57600. Daher meine Frage ob das dann noch sinnvolle Werte ergibt.

Ja, habe mich geirrt. Ich meinte auch nicht 10 Grad, sondern 10 Minuten. Wenn man besonders genau und trotzdem platzsparend sein wollte, müsste man Äquipotenziallinien erzeugen und dort, wo sie besonders dicht sind (=hohe Steigung / hoher Gradient des Geoids) mehr Werte in die Tabelle tun als in den Gegenden, wo die Steigung gering ist. Aber so eine dynamische Tabelle wäre wieder schwer auszuwerten.

Auf der anderen Seite wäre es schön wenn man die Werte nicht in einer Datei, sondern direkt als statische Tabelle im Code hinterlegt.

Man kann sie ja erstmal in eine Datei schreiben und dann in die statische Tabelle einfügen. Eine Arbeitsteilung wäre ja ganz gut: Einer extrahiert die Werte, der andere erstellt die Routine zur Berechnung.

Da wären die 128 kb Speicher bei einem 1 Grad Raster schon noch akzeptabel. Ein 1 Grad Raster deckt aber zumindest am Äquator ca. 12000km^2 ab. Fraglich ob da noch sinnvolle Werte rauskommen.

Ich bin sowieso unsicher bezüglich der Daten-Genauigkeit. Die Korrektur-Höhen des Geoids (=Quasigeoidhöhe) liegen in Deutschland zwischen 36 und 50 Metern. D.h. es gibt in Deutschland 14 Meter Höhenunterschied innerhalb des Geoids. Der Bezugspegel ist Amsterdam und alle amtlichen Höhen werden auf diesen Pegel bezogen. Dabei wird zur Interpolation in Deutschland ein Geoid nach einem neuen System GCG05 angenommen (Bundesamt für Geodäsie). Gerade in den letzten Jahren wird das Geoid-System europaweit umgestellt, weil im alten System noch keine Gravitationsunterschiede berücksichtigt wurden. Im neuen System (European Levelling Net UELN) hingegen schon. Deshalb weichen die amtlichen Höhenangaben in den topografischen Karten zur Zeit noch von den mit Hilfe der Quasigeoidhöhe nach UELN berechneten Höhen ab. Aber das wird sich in den nächsten Jahren sukzessive ändern. Die neuen Werte werden deshalb nicht mehr als Höhe über Normalnull (Höhe ü. NN) sondern als Normalhöhennull (NHN) angegeben. Deshalb sagte ich ja schon in einem früheren Posting, dass man für die Höhenkorrektur im Grunde genaueres über die im jeweiligen Land gültigen, amtlichen Höhenangaben wissen müsste.

Wie weit die von der amerikanischen Behörde zur Verfügung gestellten Daten mit denen nach UELN übereinstimmen, weiß ich nicht. Aber sowohl beim Bundesamt für Geodäsie, als auch bei der amerikanischen Behörde gibt es online-Rechner, bei denen man die Höhen nach den jeweiligen Systemen ermitteln kann. Auf diese Weise könnte man schonmal vorab gucken, wie weit das US-System auch bei uns passt. Man sieht also, die Sache ist doch alles andere als trivial.

Tschö, Volker

 

[Temar]

Eine Arbeitsteilung wäre ja ganz gut: Einer extrahiert die Werte, der andere erstellt die Routine zur Berechnung.

Routine zur Berechnung gibt's irgendwie nicht. Die vorberechneten Korrekturwerte kann man sich ja direkt runterladen. Wir müssen das 2.5x2.5 Raster nur noch reduzieren und schon haben wir die Tabelle für unser Raster. Das sollte ja eigentlich kein Ding sein.

Wie weit die von der amerikanischen Behörde zur Verfügung gestellten Daten mit denen nach UELN übereinstimmen, weiß ich nicht. Aber sowohl beim Bundesamt für Geodäsie, als auch bei der amerikanischen Behörde gibt es online-Rechner, bei denen man die Höhen nach den jeweiligen Systemen ermitteln kann. Auf diese Weise könnte man schonmal vorab gucken, wie weit das US-System auch bei uns passt. Man sieht also, die Sache ist doch alles andere als trivial.

Ja, aber die Anpassung der Tabelle für die Landeskorrektur können wir ja in einem zweiten Schritt machen. Erster Schritt wäre erstmal die WGS84 Daten zu reduzieren so dass wir auf die "offizielle WGS84-Höhe" kommen. Dazu liefern die anscheindend schon ein Fortran Tool mit. Werde das mal mit dem gfortran Compiler versuchen zu kompilieren. Wenn das für uns nicht taugt, dann heisst es erstmal Fortran-Code entziffern, da ja das Datenformat für die vorberechneten Tabellen irgendwie nicht dokumentiert ist. Meine Fortran Kenntnisse sind extrem rudimentär. Ich habe mal Fortran-Routinen einer Library aus C raus aufgerufen - das war's dann aber schon. Das einzige Fortran-spezifische dabei war die Konvertierung der Parameter.

Der eigentliche Einbau der Tabelle in den Android Source ist dann nicht so das Problem. Schliesslich müssen wir den Wert des aktuellen Sektors dann nur noch von der Höhe abziehen, die vom GPS-Empfänger geliefert wird.

 

[fipsy]

Sorry, dass ich mich hier so lange nicht mehr gemeldet habe. Ich habe zur Zeit sehr viel umme Ohren ;-).

Was Fortran betrifft, kann ich vielleicht behilflich sein. Ist zwar schon länger her, aber ich habs im Studium mal gelernt (allerdings Fortran 77) und früher auch viel damit programmiert. Ein paar Kenntnisse sollten wohl noch da sein.

Ich hatte auch jemandem geschrieben, der in einem GPS-Forum (weiß schon gar nicht mehr wo) geschrieben hat, er hätte C-Code zur Höhenkorrektur. Der hat nur leider nie geantwortet. Ich denke immer noch, dass es eine einfachere Lösung geben müsste, als die Konvertierung dieses Datenwusts und ein Umschreiben der Fortran-Routinen.

Gruß, Volker

 

[Oliver Beyer]

Ich hab übrigens das Tool "GPS Test" gefunden, dass den Geoid-Fehler kompensieren kann. Das tut es recht zuverlässig und die Höhe stimmt dann halbwegs. Erstaunt mich, dass kaum eine App das sonst berücksichtigt.