GPS-Daten per gpsd auslesen?

[jennergruhle]

Hi,

hat schon jemand gehört, wie es mit der Unterstützung in Cachewolf für das Auslesen der GPS-Daten per Netzwerk von einem gpsd aussieht? Ich habe dazu mal gesucht und nur wenig, z.B. dies hier gefunden:

http://www.freeyourphone.de/portal_v1/viewtopic.php?f=22&t=597

Da sich dort nix tut, nehme ich mal an, dass das nicht weiter verfolgt wurde.

Auch dies http://www.geoclub.de/viewtopic.php?f=40&t=22393&hilit=gpsd hab ich gefunden, aber auf gpsd ging da auch keiner weiter ein. Weitere Treffer sagten nur, dass gpsd läuft und man den Seriellport irgendwie mit diesem teilen muss.

Die Nutzung des gpsd wäre hervorragend geeignet für den Betrieb des Cachewolf auf Linux-Geräten wie dem Openmoko Freerunner, weil dort der GPS-Daemon gpsd ohnehin läuft und das GPS-Device belegt. Andere Applikationen zur Navigation wie z.B. TangoGPS greifen auch darauf zu, und können sich dann den Empfänger teilen (statt sich den Seriellport gegenseitig wegzunehmen).

Ich hätte durchaus Lust, sowas zu implementieren, aber würde es nur anfangen, wenn noch gar keiner verwertbare Ergebnisse dazu hat.

 

[greiol]

hat schon jemand gehört, wie es mit der Unterstützung in Cachewolf für das Auslesen der GPS-Daten per Netzwerk von einem gpsd aussieht?

es gibt sie nicht

Ich hätte durchaus Lust, sowas zu implementieren, aber würde es nur anfangen, wenn noch gar keiner verwertbare Ergebnisse dazu hat.

mit "richtigem" java ließe sich so etwas vermutlich recht einfach erstellen. du solltest aber berücksichtigen, dass das ganze auch noch einmal durch die ewe genudelt wird und deren tcp unterstützung ist eher mau

 

[pfeffer]

inwiefern ist die tcp-unterstützung in ewe mau?

Cachewolf kann die GPS-Daten an einen beliebigen Host weiterleiten, an TCP-Port 23 (oder was es 21)? (GPS-Einstellungen / foward to host oder so)

Du willst es umgekehrt? gpsd -> cachewolf?
das sollte in linux über irgendwelche pseudo-devices (PTTY?) kein Problem sein.

Gruß,
Pfeffer.

 

[Keimix]

Eine Anbindung an einen gpsd fände ich auch toll (leider kann ich nicht programmieren).
Sollte irgendjemand eine CacheWolf Anbindung unter Linux hingebastelt haben, so würde ich dazu gerne Tipps bekommen.
Mit CacheWolf komm ich auf keine Schnittstelle.
Bin dankbar für jeden Tipp.

@jennergruhle: solltest Du das umsetzen, so biete ich Testhilfe an.

MfG
Ralf

 

[jennergruhle]

Du willst es umgekehrt? gpsd -> cachewolf?
das sollte in linux über irgendwelche pseudo-devices (PTTY?) kein Problem sein.

Ja, der Cachewolf soll die GPS-Daten vom gpsd beziehen. Aber nicht über irgendwelche pseudo-Devices (Bastelkram per netcat o.ä. gibt es schon), ich will lieber einen echten gpsd-Client in Cachewolf. TCP-Verbindungen aufbauen sollte doch aber kein Problem sein, oder? Wenn das in ewe nicht geht, wäre es wohl nicht so schlimm - auf richtigen Linuxkisten wie Freerunner oder Eee kann man ja die normale Java-VM nutzen, und da geht es definitiv.

 

[pfeffer]

tcp ist überhaupt kein Problem mit Ewe.

ehrlich gesagt, erscheint mir gpsd als Zwischenstation grundsätzlich überflüssig --> verbraucht nur Akku und schafft zusätzlichen Delay.

Aber vermutlich ist es leichter, in Cachewolf eine TCP-verbindung zu gpsd aufzubauen als den serial-port-Bug der Linux-Version von Cachewolf zu fixen.

Wenn ich richtig liege, dann hat mirabilos das allerdings bereits getan. Am besten ihn mal im IRC auf #cachewolf im Freenode-Netz ansprechen.

man kann ja auch das eine tun, ohne das andere zu lassen... -> Also: rann an den Speck!

Gruß,
Pfeffer.

 

[Keimix]

Ja, bitte bitte bitte

GPSD hätte schon Vorteile (Zumindest auf Laptops o.ä):
Es kann mit fast allen GPSr einen konsistenten Datenstrom hinkriegen,
Cachewolf kann nur NMEA über seriell, was selbst wenn der Linux Schnittstellenbug nicht wäre z.B. alle neueren Garmin Geräte zur Benutzung ausschliesst, da die
nur noch binär im Eigenformat ihre Position ausspucken.

Gruß Ralf

 

[jennergruhle]

OK, dann nehme ich es mal in Angriff. Die nötigen Optionen kann ich schon konfigurieren, nun geht's an den eigentlichen Empfang. Ich habe mir das so gedacht, dass das GPSD-Häkchen in den Optionen ein Override darstellt, die GPS-Daten statt von einem Seriellport per Netzwerk zu beziehen.

Sehe ich das richtig, dass die GPS-Daten bisher ausschließlich in der Klasse GPSPortOptions ausgelesen werden? Dann müsste ich den gpsd-Empfang ja auch dort nachrüsten, oder? Klingt etwas komisch - eine Optionen-Klasse liest Seriell- odr Netzwerkdaten...

MIr scheint, dass die Verwendung der GPS-Daten, z.B. in Navigate, so passiert:

serThread = new SerialThread(pref.mySPO, gpsPos, (pref.forwardGPS ? pref.forwardGpsHost : ""));

und dann das serThread-Objekt für die Bestimmung der Posotion verwendet wird, ist das richtig?

 

[jennergruhle]

Yippie!
Es klappt!
Wenn ich jetzt den GPSD-Host und -Port in den Einstellungen angebe, und die Checkbox aktiviere, dann wird beim Navigieren in der Klasse Navigate nun ein GpsdThread statt eines SerialThread gestartet, und der gibt das Kommando "ADPQTV" über einen Socket an den GPSD, worauf dieser eine Antwort liefert wie diese:

GPSD,A=55.500,D=2008-08-05T17:23:44.0Z,P=54.051081667 12.194235000,Q=?,T=15.1500,V=7.880

Dann musste ich nur noch eine neue Parser-Methode in CWGPSPoint bauen, und schon kriegt CW schön die Daten vom GPSD.

Momentan hakt es noch etwas mit den Optionen, und ich habe noch keine Möglichkeit zum Auslesen der GPS-Empfangsqualität und Sat-Anzahl, aber das geht sicher auch noch irgendwie. Eventuell liegt es nur an meinen NMEA-Files vom Datenlogger, die ich jetzt dem GPS-Simulator vorwerfe (hab hier keinen Empfang gerade).

Nu geht's aber ab in die Falle...

 

[pfeffer]

ja, nen neuen Parser schreiben, oder GPSD in den NMEA-mode schalten.
Die Argumente dafür, dass gpsd sich nen eigenes Format gebastelt hat, haben mich bislang nicht überzeugt. Aber wenn Cachewolf ein zusätzliches Format/Protokoll lesen kann, umso besser

Du hast j aschon die richtigen Klassen gefunden.
geparst wird momentan in CWGPSPoint - da müsste man nochmal drüber nachdenken, ob das so sinnvoll ist, wenn wir einen 2. Parser bekommen.
Vielleicht sollte man dann eine Klasse machen:
GetPos
und von der GetGpsPos und GetGpsdPos ableiten.
In Navigate könnte dann einfach GetPos als Member eingetragen werden und je nach Bedarf GetGpsPos oder GetGpsdPos instanziert werden.

Gruß,
Pfeffer.

 

[jennergruhle]

Ja, klingt alles sinnvoll. Momentan sieht es noch ein bisschen komisch aus, dass die Klasse GPSPortOptions nun auch für die Verwaltung der GPSD-Optionen zuständig ist (und für die TEst-Anzeige der GPSD-Daten), aber man muss ja nicht mehr auseinanderreißen als sinnvoll.

Ich habe gerade noch mal die GPSD-Manualpages durchwühlt, aber noch nicht herausgefunden, wie man GPSD dazu bringt, komplette NMEA-Telegramme wie auf dem Seriellport üblich auszuspucken, nur ein O-Kommando habe ich gefunden, welches sowas ausspuckt:

GPSD,O=GGA 1234610937.000 0.005 54.079036667 12.096301667 93.700 ? ? ? ? 0.000 ? ? ? 3
GPSD,O=RMC 1234610999.000 0.005 54.079771667 12.089881667 80.200 ? ? 15.1500 8.720 0.000 ? ? ? 3

Also so ähnlich wie NMEA; aber mit Space statt Komma und ? statt 0 oder Leerstring.
Meintest Du dies?
Ansonsten gibt es noch das M-Kommando, aber das sagt nur aus, welche Informationen geliefert werden (auch Höhe und Geschwindigkeit).

Aaaah, ich seh gerade, es gibt den Raw-Mode (R1), dann spuckt GPSD die NMEA-Daten direkt aus. Dann kann ich ja auch diese nehmen und den bisherigen Parser...
Nur gibt es wohl auch einige exotische GPS-Empfänger, die gar kein NMEA können, für die wäre der GPSD im Nicht-Raw-Mode dann ja der Rettungsanker...

Andererseits könnte ich im Raw-Mode wieder die Daten weiterleiten, was momentan nicht geht (war zu faul, neue NMEA-Daten zu konstruieren - aber das könnte man auch zur Not nachimplementieren).

Was meint ihr, Raw-Mode und NMEA-Parser als Default beim GPSD, und den "Notanker" mit zweitem Parser nur per Option in der pref.xml einschalten? Man muss den Dialog ja nicht zu sehr überfrachten...

Ich habe übrigens noch einen Bugfix in myTableModel.java durchgeführt - da konnte es bei unpassenden Einträgen in der pref.xml zu Spaltenbreiten zu einer ArrayIndexOutOfBoundsException kommen, wodurch der Optionsdialog nie erschien. Diese Optionen (zu hoher Spaltenindex) müssen irgendwie beim Update der pref.xml hineingekommen sein - manuell hatte ich nichts drin herumgeprokelt.

Wenn ich jetzt noch die Qualitäts-Auswertung in den zweiten Parser eingebaut habe, bin ich eigentlich soweit mit allem durch. Ein paar nette Ergänzugen wären vielleicht noch das Deaktivieren der Seriell-Dinge (Port, Baud usw.) wenn GPSD angehakt ist.

Was ist denn jetzt der beste Weg, meine Ergänzungen/Korrekturen weiterzugeben? SVN-Schreibzugriff hab ich ja nicht...

 

[arbor95]

per pn oder mail oder über das Forum an mich, falls du es nicht schon weitergegeben hast. Die anderen sind zur Zeit wohl intensiv mit anderen Entwicklungen beschäftigt. Wäre ja schade, wenn das verloren ginge.

Entweder die Quelldateien oder als Patch (Eclipse/Team/create patch).

DfdE

 

[jennergruhle]

So, habe gerade noch mal hochgezogen und die neuesten Änderungen eingearbeitet, und nun einen Patch erstellt. Was noch fehlt, sind die neuen Texte in fr und nl.

Wo soll der Patch jetzt hin? Als Text hier posten? Auf irgendnen Webspace laden, wo er bald wieder weg ist? Oder will den jemand als Mail haben zum Testen?

 

[MiK]

Zippen und hier posten.

 

[jennergruhle]

Achja stimmt, hier gibt's ja auch ne Upload-Funktion. Hatte ich vergessen. Also hier der Patch.

Frohes Testen!

 

[motli]

Hallo zusammen,
bin schon ein paar Tage hier am mitlesen und verfolge mit Spannung die Entwicklung betreffend des gpsd-Problems mit Linux. Ich selber benutze den Cachewolf auf meinem Freerunner GTA02 Rev.06.
Nun habe ich heute morgen mit Freude festgestellt, dass ein patch für Cachewolf online gestellt wurde. Nur weiss ich leider nicht, wohin ich diesen patch kopieren muss.
Kann mir vielleicht jemand von euch einen Tipp geben.

Vielen herzlichen dank für dieses tolle Forum und den Cachewolf.

Freundlich grüsst
Tom

 

[jennergruhle]

Der Patch ist bisher nur eine Änderung für den Quelltext von Cachewolf und kann nur von einem Entwickler mit laufender Entwicklungsumgebung eingebaut werden. Wenn dan eine neue CW-Version exportiert wurde, kann diese weitergenutzt werden.
Altenativ könnte ich auch eine neue Version bauen, aber momentan habe ich da keinen brauchbaren Stand - es wird wohl gerade einiges umgebaut und meine eigene neueste Version läuft auch nicht richtig - sie hat z.B. Probleme beim Aktualisieren von Cachedaten.

Hat jemand der Entwickler schon Zeit zum Testen meines Patches gehabt?

 

[pfeffer]

ich habe ihn nicht ausprobiert, aber angegeuckt.
Du hast ja leider meinen Vorschlag der abstrtakten Zwischenklasse nicht umgesetzt - aber wenn es auch so geht - ich hätt's halt schöner gefunden, aber vielleicht hat Deine Variante auch Vorteile?

Ich habe Dich bei BerliOS freigeschaltet: noch mal selbst testen und dann mutig einchecken ;-)

Gruß,
Pfeffer.

 

[arbor95]

...Ich habe Dich bei BerliOS freigeschaltet: noch mal selbst testen und dann mutig einchecken ;-) ...

super, noch einer mehr!
Herzlich Willkommen!

p.s. : wer macht die Übersetzung NL und FR ?
Text:
4408=Konnte keine Verbindung zum GPSD herstellen:
4409=%0aM%f6gliche Gr%fcnde:%0a Adresse/Port falsch%0a GPSD l%e4uft dort nicht

Wird eine Anleitung / Dokumentation noch benötigt ?


pps: ich hab auch draufgeschaut. und ich hät es dann auch eingecheckt. aber so ist mir auch recht!

 

[jennergruhle]

Du hast ja leider meinen Vorschlag der abstrtakten Zwischenklasse nicht umgesetzt - aber wenn es auch so geht - ich hätt's halt schöner gefunden, aber vielleicht hat Deine Variante auch Vorteile?

Eigentlich bin ich noch nicht dazu gekommen, die Zwischenklasse zu erstellen und auszuprobieren. Ich werde mir das aber auf jeden Fall noch mal ansehen. Die GetPos-Klasse kann ja dann die CWGPSPoint-Instanzen befüllen.
Gibt es eigentlich einen besonderen Grund, dass ihr Getter und Setter meidet wie der Teufel das Weihwasser?

Ich habe Dich bei BerliOS freigeschaltet: noch mal selbst testen und dann mutig einchecken ;-)

Super! Ich werde es dann einchecken und weiter verfolgen, wie es sich so macht.
Ich habe auch noch geplant, dass die GPSD-Checkbox die Seriellport-Optionen deaktiviert, damit klar wird, dass beides nur alternativ geht.

Momentan frage ich den GPSD erst mal im Nicht-NMEA-Modus ab - so nutzt er auch denen, die keinen NMEA-tauglichen Empfänger haben - solange das Gerät vom GPSD unterstützt wird. Einige neuere Garmins sollen in diese Kategorie fallen.