• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[Patch] gpsd: Unterstützung für neues Protokoll

T

Tblue

Geonewbie
Hallo,

als Cache-Anfänger wurde mir vor kurzem CacheWolf empfohlen. Das Programm gefiel mir dann auch ganz gut, jedoch wollte mein Garmin partout nicht mit CW zusammenarbeiten. Hier im Forum stieß ich dann auf den anscheinend bekannten Ewe-Bug bzgl. Linux + seriellen Ports (oder so ähnlich).

Na gut, als nächstes probierte ich es dann mit dem gpsd (v2.95). Das sah auch ganz vielversprechend aus, allerdings funktionierte es noch immer nicht. Etwas Recherche (gpsd-Homepage, siehe "Urgent news [...]") brachte zu Tage, dass sich das von gpsd verwendete Protokoll vor kurzem geändert hat. Und siehe da: CW versucht, mit gpsd über das alte Protokoll zu kommunizieren, der versteht aber neuerdings nur JSON.

Ich habe also die letzten Tage damit verbracht, CW so zurechtzuhacken, dass es mit den neuen gpsd-Versionen funktioniert. In der Theorie müsste das auch funktionieren, allerdings kann ich den Code erst nachher (d. h. heute) auch mit meinem GPS-Gerät testen (gerade kein Empfang und müde bin ich auch).

Ich hoffe, dass ihr Interesse an meinem Patch habt -- falls nicht, nun... Dann hatte ich immerhin eben etwas "Spaß" mit Java. Man lernt ja gerne etwas dazu.

Der Patch ist gegen die neueste SVN-Revision erstellt (r2717). Da ich eher selten in Java programmiere, ist mein Code sicherlich nicht perfekt und könnte durchaus noch etwas aufpoliert werden. Folgende Probleme gibt es noch:

  • Ich musste einen JSON-Parser für Ewe anpassen/portieren. Es scheint alles zu funktionieren, jedoch musste ich die verwendeten Java-Klassen durch ihre Ewe-Äquivalente ersetzen. Manche dieser Klassen sind nicht threadsafe und ich habe nicht genau getestet, ob das Probleme macht. Wie schon gesagt, bisher scheint aber alles zu klappen.
  • Der erwähnte Parser ist unter irgendetwas BSD-ähnlichem lizenziert. Wenn ich mich richtig erinnere, ist das mit der GPL kompatibel. Falls ich mich irre, habe ich ein Problem (oder muss einen GPL-lizenzieren JSON-Parser finden).
  • gpsd liefert neuerdings keine Bearing-Daten (auf Deutsch heißt das glaube ich Peilung?) mehr. Schade, schade. :/ Das Feld wird im Navigationspanel nun einfach ausgeblendet, wenn gpsd genutzt wird. [fixed, siehe v2]
  • Das Lesen vom gpsd-Socket kann den Thread blockieren. Da es aber im Normalfall immer eine Antwort vom gpsd gibt, scheint das kein Problem darzustellen. Mit etwas Arbeit kann ich das aber sicherlich auch entsprechend umprogrammieren (andererseits verwendete der alte gpsd-Code auch keine nonblocking calls).
  • Sollte es Nutzer geben, die noch alte gpsd-Versionen nutzen (mit denen CW funktioniert), müssten sie gpsd upgraden. Das ist eigentlich kein großes Problem, aber erwähnen wollte ich das trotzdem. [fixed, siehe v2]

Ich glaube, das waren alle Probleme. Vielleicht fällt mir ja später noch mehr ein...

Also, ich würde mich freuen, wenn der eine oder andere meinen Patch testet und/oder Kritik übt (hm, das klingt so furchtbar auffordernd. Soll es nicht, ich möchte einfach nur etwas zu CW beitragen :)).

Den Patch (v1) findet ihr unter: http://files.ax86.net/CacheWolf/cachewolf_gpsd-json-support.diff

Grüße,

Tblue
 
MiK

MiK

Geoguru
Wie sieht denn so ein JSON-GPSD-Datensatz aus? Braucht man dafür wirklich einen fremden Parser?
 
jennergruhle

jennergruhle

Geoguru
Tblue schrieb:
Ich habe also die letzten Tage damit verbracht, CW so zurechtzuhacken, dass es mit den neuen gpsd-Versionen funktioniert. In der Theorie müsste das auch funktionieren, allerdings kann ich den Code erst nachher (d. h. heute) auch mit meinem GPS-Gerät testen (gerade kein Empfang und müde bin ich auch).

[*] Sollte es Nutzer geben, die noch alte gpsd-Versionen nutzen (mit denen CW funktioniert), müssten sie gpsd upgraden. Das ist eigentlich kein großes Problem, aber erwähnen wollte ich das trotzdem.
Zum Vergrößern anklicken....
Vielen Dank für diese Anpassungen! Ich würde allerdings vorschlagen, dass man wahlweise alten oder neuen gpsd nutzen kann. Ich habe damals die erste gpsd-Anbindung für CW geschrieben, weil mein damaliges Handy (OpenMoko Freerunner, Linux-basiert) nur den GPSD anbot und keinen Seriellport. Allerdings glaube ich nicht, dass hierbei (und bei einigen anderen Linux-Installationen) der gpsd so einfach auf eine neue Version aktualisiert werden kann.
 
OP
T

Tblue

Geonewbie
MiK schrieb:
Wie sieht denn so ein JSON-GPSD-Datensatz aus? Braucht man dafür wirklich einen fremden Parser?
Zum Vergrößern anklicken....
Hmm, das ist eben... JSON. Ein Beispiel (Quelle):
Code: 
{"class":"POLL","timestamp":1270517274.846,"active":1,
    "fixes":[{"class":"TPV","tag":"MID41","device":"/dev/ttyUSB0",
              "time":1270517264.240,"ept":0.005,"lat":40.035093060,
              "lon":-75.519748733,"track":99.4319,"speed":0.123,"mode":2}],
    "skyviews":[{"class":"SKY","tag":"MID41","device":"/dev/ttyUSB0",
                 "time":1270517264.240,"hdop":9.20,
                 "satellites":[{"PRN":16,"el":55,"az":42,"ss":36,"used":true},
                               {"PRN":19,"el":25,"az":177,"ss":0,"used":false},
                               {"PRN":7,"el":13,"az":295,"ss":0,"used":false},
                               {"PRN":6,"el":56,"az":135,"ss":32,"used":true},
                               {"PRN":13,"el":47,"az":304,"ss":0,"used":false},
                               {"PRN":23,"el":66,"az":259,"ss":0,"used":false},
                               {"PRN":20,"el":7,"az":226,"ss":0,"used":false},
                               {"PRN":3,"el":52,"az":163,"ss":32,"used":true},
                               {"PRN":31,"el":16,"az":102,"ss":0,"used":false}
]}]}

Die Reihenfolge der Keys ist nicht festgelegt, kann sich also auch ändern. Natürlich könnte man sich jetzt auch seinen eigenen JSON-Parser schreiben, aber warum sollte man sich doppelte Arbeit machen, wenn es schon einen für Java gibt?

jennergruhle schrieb:
Ich würde allerdings vorschlagen, dass man wahlweise alten oder neuen gpsd nutzen kann. Ich habe damals die erste gpsd-Anbindung für CW geschrieben, weil mein damaliges Handy (OpenMoko Freerunner, Linux-basiert) nur den GPSD anbot und keinen Seriellport. Allerdings glaube ich nicht, dass hierbei (und bei einigen anderen Linux-Installationen) der gpsd so einfach auf eine neue Version aktualisiert werden kann.
Zum Vergrößern anklicken....
Oh, richtig, ich habe gar nicht daran gedacht, dass der gpsd ja auch auf Mobiltelefonen laufen kann... Natürlich, beide Versionen zu unterstützen macht da Sinn. Ich schaue mir das mal an.
 
MiK

MiK

Geoguru
Tblue schrieb:
Die Reihenfolge der Keys ist nicht festgelegt, kann sich also auch ändern. Natürlich könnte man sich jetzt auch seinen eigenen JSON-Parser schreiben, aber warum sollte man sich doppelte Arbeit machen, wenn es schon einen für Java gibt?
Zum Vergrößern anklicken....
Am Ende brauche ich davon aber doch nur lat und lon (und vielleicht noch 1-2 andere). Dafür brauche ich nicht alles parsen, sondern nur die paar Strings suchen, die mich interessieren. Das sollte dann auch schneller gehen und hält den Code kleiner.
 
OP
T

Tblue

Geonewbie
Das wird dann nur lustig, wenn ein Key sowohl im Objekt an sich, als auch in Unterobjekten vorkommt (wer weiß, wie sich das Protokoll in Zukunft noch ändert). Dann gäbe es da noch verschiedene Möglichkeiten, Zahlen darzustellen; die JSON-Arrays (die dann wiederum Objekte enthalten usw.) würden auch Arbeit machen. Landet man da am Ende nicht wieder bei einem JSON-Parser...? Ich verstehe dein Argument (macht sicherlich vor allem auf Mobiltelefonen was aus), aber am Ende macht man sich möglicherweise nur unnötige Arbeit.

Ich kümmere mich jetzt erstmal um jennergruhles Anliegen...
 
MiK

MiK

Geoguru
Ich weiß nicht, wie performant der JSON-Parser ist. Aber genau aus dem Grund benutzen wir an vielen Stellen keinen XML-Parser.
 
OP
T

Tblue

Geonewbie
Wie schon gesagt, ich sehe ja den Sinn deiner Äußerungen. :) Okay, dann ist die Performance also eine Sache, die man noch klären müsste -- nur wie? Praxistests? Habe leider kein Handy, mit dem ich das testen könnte.
 
OP
T

Tblue

Geonewbie
So, man kann jetzt zwischen dem alten und neuen gpsd-Protokoll auswählen. Peilungsdaten werden jetzt auch ausgelesen (entweder verstehe ich da was falsch, oder CacheWolf verwechselt in Bezug auf den Variablennamen 'Bear' Heading mit Bearing. Im Navi-Panel wird es aber der Definition nach angezeigt).

Der JSON-Parser ist immer noch der von JSON.org. Kann jemand vielleicht besser als ich beurteilen, wie es da mit der Performance aussieht?

Neuer Patch (quasi v2) hier: http://files.ax86.net/CacheWolf/cachewolf_gpsd-json-support-v2.diff
 
arbor95

arbor95

Geoguru
wie hast du die jar's für org.json.* bzw net.ax86.* erzeugt bzw die entsprechenden *.java im eclpise eingebunden?
 
OP
T

Tblue

Geonewbie
Ich nutze kein Eclipse, aber die Dateien in lib/ werden durch einen Aufruf von ./compile.sh nicht kompilliert. Das musst du also selbst erledigen, z. B. mittels:
Code: 
javac -source 1.3 -target 1.1 -cp ./lib/CompileEwe.zip:./lib/ -deprecation lib/{net,org}/*/*.java

Es gibt da bestimmt einen einfacheren Weg (Abändern von compile.sh/.bat?).

//edit: Du fragtest nach jars -- geht hier auch ohne, von Jewel werden die *.class-Dateien auch mitgepackt...
 
OP
T

Tblue

Geonewbie
Abgeänderte, funktionierende compile.sh:
Code: 
#!/bin/sh

ENCODING=${ENCODING:-windows-1252}

do_compile() {
	javac \
		-source 1.3 \
		-target 1.1 \
		-encoding "${ENCODING}" \
		-cp ./lib/CompileEwe.zip:./lib/ \
		-deprecation \
		-nowarn \
		"$@"
}

do_compile \
	-d ./bin/ \
	./src/CacheWolf/*.java \
	./src/CacheWolf/*/*/*.java \
	./src/CacheWolf/*/*.java
do_compile \
	lib/net/*/*.java \
	lib/org/*/*.java
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben