GPS Bricklet API

Das GPS Bricklet ist gerade in Arbeit. Nach einem Vorschlag von AuronX möchte ich dessen API hier zur Diskussion stellen. Hier als Beispiel C/C++ und ja die Beschreibung fehlt noch. Falls etwas nicht aus der Signatur ersichtlich ist einfach fragen

http://www.tinkerforge.com/doc/Software/Bricklets/GPS_Bricklet_C.html

In der Gefahr den Hinweis darauf übersehen zu haben:

Warum sind lat/lon jeweils arrays? Was bedeuten sie?

Erwartet hätte ich double ^^

edit: Ansonsten wäre ich schon noch dafür, dass es Getter für Einzelwerte gibt. Also auch GetSpeed, GetAltitude usw.

GetStatus als "Sammelgetter" finde ich zwar auch gut, aber halt unpraktisch wenn man nicht alles braucht ^^

Das parsen von den ganzen Werten ist leider vergleichsweise Aufwendig, daher ist das GPS Bricklet Plugin mit dieser API schon voll, einzelne Getter werden wir da unmöglich noch hinzufügen können . Sonst hätte ich das schon getan.

Ich denke das ist aber keine Katastrophe, das GPS Modul hat eine update Frequenz von 10hz, sprich man kann einfach beide Callbacks auf 100ms stellen und immer alle Daten zur Verfügung haben ohne irgendwas auch nur annähernd auszulasten.

In der Gefahr den Hinweis darauf übersehen zu haben:

Warum sind lat/lon jeweils arrays? Was bedeuten sie?

Erwartet hätte ich double ^^

Die Koordinaten werden in DD°MM.mmmm’ Format ausgegeben, dabei ist DD°MM im ersten Wert des Arrays und mmmm’ im Zweiten. Bei genauerer Betrachtung verwenden wir sonst eigentlich eine andere Darstellung für Floatzahlen. Ich werde das zu einem Wert ändern, der sich dann so zusammensetzt: DDMM * 10000 + mmmm. Den Wert hier wirklich als float zu übergeben ist nicht drin, da floats zusätzlichen Code brauchen und das die Größe des Plugins sprengt.

Das klingt ja alles sehr schade ^^

Das mit dem float habe ich mir fast schon gedacht, das mit den einzelnen Gettern habe ich tatsächlich nicht erwartet.

Ist eine Funktion geplant, um die Zeit abzufragen? Dann könnte man das GPS-Bricklet zur synchronisation eines NTP-Servers verwenden.

Uhrzeit und Datum sind mit im Status .

Wir haben noch mal das GPS Modul gewechselt. Das neue Modul bekommen wir dann auch mit einem Binärprotokoll, das einfacher zu parsen ist. Dadurch ist jetzt auch wieder Platz freigeworden und wir könne GetStatus aufteilen, wie das hier schon vorgeschlagen wurde.

Die aktuelle API ist hier zu finden: http://www.tinkerforge.com/doc/Software/Bricklets/GPS_Bricklet_C.html

Neben der Aufteilung von GetStatus gibt jetzt GetCoordinates auch den Estimated Position Error (EPE) zurück.

Das sieht doch schon schöner aus ^^

Was gibt es denn für restart-types?

Ich würde mir ja langfristig eine mächtigere Konfiguration für die Bindings wünschen, damit die API in einzelnen Sprachen schöner werden kann. z.B. unterstützung für enums (überall in der API werden zahlen rein und rausgegeben von denen nur ein paar werte gültig sind, z.B. restart-type, options in callbacks, etc).

Finde es auch schade, dass Python/C#/Java vermutlich nicht in den Genuss kommen werden bei get_date_time ein DateTime-Objekt zu erhalten :/

Es gibt Hot, Warm, Cold und Full Cold Start. Je kälter desto weniger zwischengespeicherte Daten wie die Satellitenflugbahnen und die Uhrzeit werden nach dem Neustart wiederverwendet.

Mit Enums für Magicnumbers geb ich dir recht und setzte es mal auf die TODO Liste.

Dass get_date_time ein DateTime-Objekt zurück gibt wird allerdings nicht passieren in absehbarer Zeit. Da ist das Feld der Möglichkeiten einfach zu groß als das man das im Generator sinnvoll unterbringen könnte.

Ich kann mit einigen der ausgegebenen Werte nichts anfangen. Ist vielleicht die aktuelle Genauigkeit bzw. mögliche maximale Entfernung vom gemessenen Standpunkt dabei? Wenn nein, dann würde ich das mal als weiteres Feature vorschlagen.

Insbesondere für Höhenangaben wäre das wichtig, die stimmen sowieso nie.

Das GPS Modul gibt die Dilution of Precision (DOP) aus. Darüber kann man etwas über die Genauigkeit der Position aussagen.

Besser ist wohl aber noch der Estimated Position Error (EPE) in Metern. Diesen gibt das Modul auch aus. Der sagt aber nichts über die höhe aus.

Über die Genauigkeit der Höhe kannst du wohl etwas aus dem PDOP (Positional Dilution of Precision) Wert ableiten, der sich auf die 3D Position bezieht.

Je mehr Satelliten empfangen werden um so genauer die Positionsbestimung.

Um die Höhe zu bestimmen sind mindestens 4 Satelliten nötig.

Je mehr Satelliten empfangen werden um so genauer die Positionsbestimung.

Um die Höhe zu bestimmen sind mindestens 4 Satelliten nötig.

So einfach ist das nicht. Mein Segelboot schwebt gern 50 Meter über der Ostsee trotz reichlich Satelliten. Die Höhenangabe ist immer viel ungenauer als die Koordinatenangabe.

Hängt damit zusammen, dass um die Erde, vereinfacht gesagt, eine normalisierte GPS-"Null-Hülle" gerechnet wird um die Eiform etwas zu glätten.

Daher gibt es für Geometer und Militärs andere Genauigkeitsklassen (Kryptographische Schlüssel für die GPS-Signale) als für Otto-Normalos. Die können dann "echte" Höhen verwenden, solange die Schlüssel nicht verändert werden (z.B. in Krisenregionen oder -zeiten).

@Plenz: Ich würde den Beitrag an Deiner Stelle wieder löschen. Bevor Du noch eine kostenpflichtige Verwarnung bekommst, wegen Fliegens ohne Fluglizenz.

Das nennt man dan gefährlichen Eingriff in den Luftverkehr.