Preiswertes Geo-Tagging mit dem Royaltek RGM-3800
[UPDATE: Die gesammelten Erkenntnisse aus diesem Beitrag sind ab sofort unter: http://wiki.openstreetmap.org/wiki/User:Malenki/Royaltek_RGM-3800 zu finden]
Geo-Tagging ist der Trend bei Digitalfotografen. Im Urlaub, beim Fotoshooting in der Stadt oder beim Wochenendausflug nicht nur fotografieren, sondern auch gleich noch die Wegpunkte der Motive festhalten und den Bildern zuzuordnen ist eine sehr interessante und oft auch nützliche Sache.
Software wie Google Earth oder Angebote wie Flickr unterstützen diese “getaggten” Dateien und zeigen die Fotos an der korrekten Kartenposition an. Um an die notwendigen Standortdaten zu kommen ist ein GPS-Empfänger, der das Auslesen der sog. Tracks erlaubt und diese möglichst in einem gängigen Format (idealer Weise das KML-Format von Google-Earth) anbietet sowie eine Software, die den Fotos anhand der EXIF-Aufnahmezeit und der Zeit des GPS-Wegpunktes, die Geodaten als EXIF-Daten zuweist.
Da man aber oft das GPS- oder Navigationsgerät schon für andere Zwecke im Einsatz hat – eben als Navi oder beim Geocaching – die meisten GPS-Empfänger nicht das gleichzeitige Navigieren und Datenloggen erlauben oder man einfach eine ganz simple “immer dabei”-Lösung braucht, sollte man mal auf die Spezialisten unter den GPS-Empfängern schauen.
Recht bekannt ist der Datenlogger von Sony, der aber nicht mehr mit aktueller Technik arbeitet. Von Royaltek gibt es nun eine preiswerte Lösung in Form des RGM-3800. Dieser arbeitet mit dem bekannten SIRF-III Chipsatz, der für sehr gute Empfangseigenschaften steht (funktioniert teilweise sogar in Gebäuden), hat 64MB Speicherkapazität was bei der reinen Aufzeichnung der Zeit sowie des Längen- und Breitengrades für 650.000 Wegpunkte oder 112 Tage Tracking genügt (15 Sekunden Intervall).
Der Royaltek verfügt neben dem Einschaltknopf nur über eine grüne LED, die die Empfangsbereitschaft und den Betrieb signalisiert sowie eine Mini-USB Buchse, die zum Auslesen der Daten dient, aber auch den Betrieb als GPS-Maus an z.B. einem Notebook ermöglicht. Man schaltet also den RGM-3800 einfach ein, und verstaut ihn z.B. in einer Außentasche der Kameratasche oder des Rucksacks. Durch die guten Empfangseigenschaften ist aber sogar ein Betrieb in der Hosen- oder Jackentasche möglich.
Der RGM-3800 wird mit zwei AAA-Batterien betrieben, was gerade für den Einsatz bei Wanderungen und Touren praktischer ist als Akkus, kann man so doch einfach einige Ersatzbatterien mitnehmen und ist damit immer empfangsbereit, unabhängig von Netzstrom und Ladegerät. Die Batterien genügen für etwa 10 Stunden Dauerbetrieb, was meiner Ansicht nach absolut ausreichend ist.
Als Software werden “Data Log Data Downloader” der zur Konfiguration des Loggers und zum herunterladen der Tracks dient, sowie “Locr GPS Photo” zum Taggen und Anzeigen der Fotos mitgeliefert. Da derRoyaltek pro Tag nur einen kompletten Track liefert, es aber oft wünschenswert ist, einen Teiltrack zu erhalten, kann man sich mit der kostenlosen Software GPS-Track-Analyse.NET von Dietmar Domin behelfen, die auch sonst sehr gute Dienste leistet.
Insgesamt ist der Royaltek RGM-3800 eine einfache, aber leistungsfähige Lösung für durchgängiges Geotagging von Fotos, aber auch zur Nachverfolgung der wochenendlichen Wandtour in Google-Earth.
Den Royalteck RGM-3800 gibt es derzeit bei Amazon für günstige 64,90 €.
Weitere GPS- und Geotagging Artikel von mir, findet ihr HIER. Ein ausführlicher Erfahrungsbericht folgt demnächst.
Letzte Aktualisierung am 7.05.2022 / Affiliate Links / Bilder von der Amazon Product Advertising API
Die mit Sternchen (*) gekennzeichneten Verweise sind sogenannte Provision-Links. Wenn du auf so einen Verweislink klickst und über diesen Link einkaufst, bekomme ich von deinem Einkauf eine Provision. Für dich verändert sich der Preis nicht und du unterstützt damit meine Arbeit.
Hallo,
ich bin zum ersten mal hier und da ich leider nicht selber Fotofreak bin, sondern nur Fotofreak-Beschenker, hätte ich eine Frage: Meine Freundin wünscht sich für ihre Nikon D90 einen GPS empfänger. Da die Empfehlung des Royalteck RGM-3800 schon von 2007 ist, wüsste ich gerne, ob Du den noch immer empfiehlst, oder ob inzwischen was besseres auf dem Markt ist. Und: Kann sie den direkt benutzen oder sollte ich noch ein Zubehör (Software) kaufen? Verstehe leider nicht viel davon und blicke daher nicht ganz durch den Beitrag durch … Sie ist übrigens Windows-Nutzerin.
Würde mich über Hilfe freuen!
Grüße aus Köln!
Sigi
Ach ja, und wenn Du schon mal dabei bist: Gibt’s vielleicht auch einen Tipp für eine gute Panorama-Bild-Software? – davon hat sie auch mal gesprochen …
Hi!
Schau mal hier:
http://nachbelichtet.com/2012/05/30/so-funktionieren-geotagging-und-gps-logging-mit-dem-mac-problemlos/
und hier:
http://nachbelichtet.com/2011/07/25/vor-und-nachteile-von-geotagging-loesungen/
und hier:
http://nachbelichtet.com/2011/03/02/immer-dabei-gps-logger-navin-minihomer-2-4/
Der i-GotU und der Transystem sind echt gut. Der MiniHomer ist halt noch ein bisschen mehr als ein reiner Logger.
Achso, Panoramasoftware: Sehr gut und kostenlos ist das hier:
http://nachbelichtet.com/2011/07/27/kostenlose-fototools-von-microsoft/
Einfach nur mal die Suchfunktion auf meiner Seite benutzen 😉
Danke für die super schnelle Antwort!
verwende den Logger auch seit 2 Jahren. Da die Akku-Laufzeit doch recht gering ist (knapp 9 Stunden mit voll aufgeladenen Eneloops), habe ich heute getestet, wie sich der Logger verhält, wenn er mit voll aufgeladenen Eneloops an einer USB-Stromversorgung betrieben wird. Ergebnis: Die Laufzeit betrug 18 Stunden bei knapp 10 Stunden Stromversorgung über USB. Anschließend noch gut 8 Stunden über die Eneloops. Das eröffnet neue Möglichkeiten, wenn der Logger im Auto über einen 12V->USB-Adapter betrieben wird.
Grüße, Ingo
Hallo an Euch und Karsten Petersen insbesondere,
ich melde mich nun nach langer Zeit wieder. Viel im Beruf um die Ohren gehabt. Ich hab ein Programm für den Logger fertig und möchte einfach testen und sehen und verbessern. Könnt ihr mir helfen?
Hallo zusammen, hat den RGM-3800 schon jemand erfolgreich in Google-Earth als GPS-Maus angesprochen (idealerweise am Mac)?
Ich versuch das unter Tools->GPS und dort unter Echtzeit. Die dump-Ausgabe vom Logger mit dem Python-Skript bringt Daten. In Google-Earth kommt aber weder eine Fehlermeldung, noch wird irgend etwas angezeigt.
Hallo zusammen,
ich habe für Mac OS X eine grafische Oberfläche für Karsten Petersens Python-Skript “rgm3800.py” erstellt.
Erhältlich ist die Applikation, dank Karsten, auf seiner Google Code Projekt-Seite:
http://code.google.com/p/rgm3800py/
Direktlink zum Programm:
http://code.google.com/p/rgm3800py/downloads/detail?name=rgm3800-0.9.dmg
Grüße
Niels
Hallo zusammen, ich bin auf der Suche nach einem deutschen Manual (pdf) für den RGM-3800. Kenn tjemand eine Quelle?
Danke!
Thomas
@Julien: Laufzeiten findest du Wiki-Seite. Deine schlechten Erfahrungen mit den Ansmann-Akkus kann ich nicht nachvollziehen. Die “losen Drähte” kannst du ja mit Isolierband und 2-3 Schrumpfschläuchen stabilisieren.
Vielen Dank fuer Eure Antworten.
Ich habe jetzt auch verschiedene Testlaeufe gemacht, jeweils bis zum Ausgehen:
– Panasonic Batterien: ~10 Stunden
– Conrad 700mAh NiMH Billigakkus: ~8 Stunden (erste Ladung, Cellconn V-1000 mit 350mA Ladestrom)
– Ansmann 1100mAh NiMH, 6 Stunden aufgeladen in einem nicht-intelligenten Sony-Lader mit 150mA Ladestrom: ~ 5 Stunden
Bis jetzt bin ich davon ausgegangen, dass die Ansmann-Akkus wirklich eine sehr schlechte Entladekurve haben und auch das schnelle Aufladen nicht so gern moegen. Habe sie auch noch mal mit einem intelligenten Lader entladen und neu geladen… der dachte sie waern nach 30 Minuten voll, bei 300mA Ladestrom. Ja, nee. Die Conrad-Akkus sind super. Hab fuer 4 Euro ein 2er-Pack getestet. Vielleicht kaufe ich da noch mal die _groesseren_, oder die gleichen noch einmal. Am Ladegeraet scheint es auf jeden Fall nicht zu liegen. Wenn, dann hoechstens in Kombination mit den Ansmann-Akkus. Oder die sind wirklich einfach kaputt. Ich werde die noch ein paar mal laden und sehen was passiert.
So ein Umbau widerstrebt mir momentan noch ein bisschen. Lose Kabel in meiner Kameratasche oder in der Hosentasche ist mir zu wackelig, da hab ich Angst dass was rausreisst.
@malenki: wenn Du die GP-Akkus noch mal testen koenntest waer das echt super.
Mein letzter Kommentar scheint veroren gegangen zu sein -.- Also nochmal:
@N.Jung :
Ja. Wenn über USB angeschlossen, kannst du das Gerät komplett ohne Batterien betreiben.
@Julien:
Ich habe heute morgen einen Laufzeittest mit frishcgeladenen Ansmann gleichen Typs gemacht, wobei eine Laufzeit von 10h 47min 16s herauskam. Logmodus war der detaillierteste mit 1Hz, der Logger lag die ganze Zeit auf der Fensterbank (und hat dabei über 11km aufgezeichnet…=)
Für die ultimative Laufzeitoptimierung kann man den Logger so aufhübschen: http://malenki.ch/Touren/08/Sommer/tmp/DSCF9281.JPG – siehe auch die drei folgenden Bilder.
Mit den zu sehenden Batterien würde eine Laufzeit von über 25h erreicht, Parallelbetrieb von AA und AAA-Zellen wurde (noch?) nicht versucht.
Einiges Wissenswertes zum Logger ist unter http://wiki.openstreetmap.org/wiki/DE_talk:Datalogger_Royaltek_RGM-3800 zu finden. Um Korrekturen und Ergänzungen wird gebeten.
@ Paule:
habe auch davon gehört, kann leider keine Quelle nennen.
Ich hab mal gelesen, das Akkus erst nach mehreren Ladezyklen ihre volle Kapazität erreichen.
Evt. liegt die doch sehr kurze Benutzungsdauer da dran!?
@ N. Jung: An USB angeschlossen arbeitet der Logger ohne Batterien einwandfrei.
@ Julien: ich verwende die gleichen Akkus wie du mit dem Ladegerät eyepower epr 1200 und kann nicht über zu kurze Laufzeit klagen. Einen Dauertest habe ich mit diesen Akkus noch nicht gemacht, in diskontinuierlichem einsatz mit maximal 1,5h Aufzeichnung am Stück haben die Akkus ~8h durchgehalten. Wenn du vieel mehr Laufzeit brauchst, kannst du deinen Logger so verschönern:
http://malenki.ch/Touren/08/Sommer/tmp/DSCF9282.JPG (siehe auch vorherige und folgende Bilder)
Mit den abgebildeten Batterien allein lief der Logger 25h(!) am Stück. Parallelbetrieb von AA und AAA-Akkus habe ich (noch) nicht versucht.
Einen Dauertest mit den Ansmann und GP HR03 100AAAHC mit 970mAh werde ich bis zum Wochenende durchführen.
Unter http://wiki.openstreetmap.org/wiki/DE:Datalogger_Royaltek_RGM-3800 habe ich versucht, Wichtiges zusammenzufassen.
@Julien:
Vielleicht ist die Entladekurve der Ansmanns nicht flach genug, um in dem Tracker korrekt zu arbeiten – es kann schon sein, dass bei schlecht verlaufender Entladekurve die Spannung schnell unter den Schwellwert für die Nutzung sinkt und damit nur ein geringer Prozentsatz der vielleicht vorhandenen Leistung sich abrufen lässt. Ich habe gerade einen Frankreich-Urlaub hinter mir und meine GP-Recyko (sind ähnlich wie Sanyo Eneloop) haben durchaus 8 Stunden mitgemacht ohne dass das Gerät abschaltete…
mfg
Karl Günter
Moin,
ein paar von Euch haben mehrfach Akkus erwaehnt. Ich hab mir grade einen neuen 3800 gekauft. Dazu einen Satz neue Ansmann Akkus, AAA NiMH 1100mAh HR03. Voll geladen mit einem Cellconn V-1000 Ladegeraet halten die im Royaltek grade mal etwas unter 2 Stunden. Die Laufzeit variiert, nach dem ersten mal Laden nachm Auspacken der Akkus waren es gut 90 Minuten, dann ungefaehr 150 Minuten. Batterien teste ich grade.
Hab jetzt schon diverse Foren und vor allem englischsprachige Blogs durchgesucht und bin langsam am verzweifeln. Irgendwas muss ich falsch machen. Hatte auch die Vermutung, dass es an der zu niedrigen Spannung bei Akkus (1.2V statt 1.5V) liegt, aber ewnn es bei jedem anderen auch funktioniert…
Was verwendet Ihr fuer Akkus? Danke fuer die Hilfe. 🙂
Auch ich konnte das bei manchen Akkutypen bereits feststellen. Hier war nach nicht einmal 2 Stunden schluss, obwohl die Akkus vollgeladen waren. Wie mein Vorredner schon bemerkte, fällt wohl bei manchen Akkus die Nennspannung nach kurzer Zeit unter einen Wert, bei denen der RGM3800 einfach seinen Dienst quittiert.
Tatsächlich verhält sich der Logger mit Sanyo Eneloop sehr viel besser, als z.B. mit Varta Akkus
Paul schrieb am 13.04.2008
>Das Applescript findet ihr euch unter
>http://www.pnklink.de/RoyalTek_rgp:3800.zip
Der Link ist hin!!! Kann man das noch wo anders laden?
Hallo,
ist es moeglich, den 3800 per USB (12 Volt Autoadapter an Mini-USB) anzuschliessen und so ueber zB den ganzen Urlaub die gefahrene Strecke unterbrechungsfrei aufzuzeichnen (ohne dauernd Batterien zu wechseln) ?
Danke und Gruss
N.Jung
@Matze & Markus .. vielen Dank für Eure Unterstützung. … Ich muß zu meiner Schande gestehen, dass es in der Tat ein Zeit sync Problem zwischen Kamera und Rechner war. Jetzt klappt es zum größten Teil. … Vielen, Dank
…
Noch eine Frage … Wie macht ihr es denn auf Reisen mit dem Strom. Bei mir halten die Akkus immer (1100mAh) nur 8 – 10 Std. … Meine nächste Reise (6 Wochen) wird Probleme mit sich bringen an Batterien und Strom in allg. zu kommen.
Habt ihr ggf. Vorschläge mit welchen Batterien das Teil länger läuft?
Bei Fragen, Problemen und Ideen schreiben Sie bitte eine EMail an petersen.karsten@gmail.com
Wir wollen doch hier das Blog nicht mit Supportanfragen fluten 🙂
Aus dem Bauch heraus: USB Treiber fuer den PL2303 Chip installiert?
Hallo,
habe versucht meinen RGM 3800 am Mac ans laufen zu bekommen. Klappt aber leider nicht. Muss ich irgendetwas installieren, damit das Python Skript läuft?
Danke
Alex
Hallo Andre,
das Problem hatte ich bei Geotaggen mit meinen Thailand Bildern auch. Hast Du unter dem Reiter ‘Zeitkorrektur’ bei locr GPS Photo die Zeitdifferrenz zur Kamera eingestellt (vorrausgesetzt, Du hast in Südamerika die dortige lokale Uhrzeit in der Kamera verwendet?) Der RGM zeichnet ja die UTC Zeit auf, daher muss die Zeitkorrektur mit angepasst werden. Danach wurden alle Fotos an der richtigen Stelle bei mir ge-geotagged, allerdings hatte ich ein 2 sec Intervall.
Die Firmware gibts übrigens direkt bei Royaltek: http://www.royaltek.com/downloads_con.php?cid=1&p_cid=2
Gruß Matze
Ich lasse meine Kamera(s) übrigens immer auf GMT eingestellt, damit hat mein keine Probleme, wenn man in anderen Zeitzonen fotografiert (wer denkt schon daran, die Kamerazeit vor und nach dem Flug umzustellen?).
Hallo … ich hoffe ihr könnt auch einem Windoof Nutzer weiterhelfen.
Ich besitze seit 3 Wochen den RGM-3800. Was das mitloggen der Geo-Daten angeht, bin ich eigentlich sehr zufrieden. ich erkenne die Tracks durchaus wieder (trotz 30 Sek. Intervallen).
Was mich eher Unzufrieden macht die die Übertragung der Daten in meine Fotos. Führe ich die Übertragung mit der Locor Software durch werden zumeist nur für die hälte der Fotos Geo-Daten erkannt, obwohl die Bilder zum größten Teil an genau der selben Stelle fotografiert wurden.
Das selbe oder zumindest ähnliche Problem habe ich mit “GeoSetter” … setzte ich hier die Tolleranz der Zuweisung auf z.B. 120 Sek. was wahrlich flexibel genug sein sollte (Kamerauhrzeit stimmt genau) , können eine Menge Bilder nicht getagt werden. Gehe ich höher mit der Toleranz werden die Fotos zwar getagt, doch an irgend welchen Stellen auf dem aufgezeichneten Track.
Da ich das Teil geholt habe, um meine Südamerika Durchquerung aufzuteichnen und meine Bilder zu tagen, muss ich mich im Moment fragen, ob es überhaupt Sinn macht.
Ich hatte auch mal versucht den Track in GPS-Track-Analyse.Net einzulesen (als nmea-Datei), wird das Laden verweigert, da die Datei wohl nicht dem korkten Format entspricht.
Zum Schluß … ich hatte gelesen, dass es ein Firmware Update geben soll. Doch ich kann es auf der Hersteller-Seite nicht finden, denn es wäre in der Tat praktisch einzelne Tracks zu haben, als immer nur den gesamten Tag aufgezeichnet zu bekommen.
Ich hoffe ich kann den ein oder anderen kleinen Hinweis bekommen. Wäre echt super.
Vielen Dank
Andre
@Karl Günter Wünsch
Vielen Dank für die Info, darüber hatte ich bisher noch gar nichts gelesen. Irgendwie findet man im Netz auch immer nur Berichte über den 3800er und den Holux…
So wie es dann allerdings aussieht, bleibt mir ja eigentlich nur noch der Holux? Oder kennt jemand noch weitere Alternativen bzw. weiß von baldigen Neuerscheinungen?
@Smyio: Achtung der Royaltek 2300 mit Bluetooth hat nach c’t Test eine deutlich schlechtere Trackqualität als der 3800er…
Vielen Dank für Eure schnellen Antworten! 😉
@Markus
Die von Dir aufgezählten Punkte entsprechenden eigentlich auch meinen Anforderungen, ich würde mir aber gerne zusätzlich die Option offenhalten, den Logger als GPS Navigationsmaus fürs Handy etc. zu verwenden.
Aber wenn das Gerät auch nach einem Jahr noch überzeugt, macht mir dies die Entscheidung nicht gerade leichter 😉 -> warum muß der kleine 3800er auch ohne Blauzahn daherkommen und der “Große” 2300er mit integriertem Akku?
@malenki
Da Service heutzutage immer mehr an Bedeutung gewinnt, die Produkte werden ja einfach nicht mehr für die Langlebigkeit produziert (Objektive mal ausgenommen), ist dies natürlich eine halbe Katastrophe – wobei, bei diesem Preis kann man das Teil einfach wieder neu kaufen und sich die Nerven sparen…
Den Logger an sich kann ich empfehlen. Mit AA-Batterien huckepack läuft er 25h am Stück.
Allerdings hatte ich öfter mit dem rgm3800-client-script das Problem, dass einzelne Tracks partout nicht heruntergeladen werden konnten. Mit der Originalsoftware unter Windows klappte das trotzdem, allerdings sahen die Logs teilweise eigenartig aus, so dass man mit Hand nachbessern musste. Ob das am Gerät liegt, weiß ich nicht. Leider konnte ich das nicht näher überprüfen, weil der Logger bei einem Flash-Vorgang gestorben ist. 🙁 (Windows hatte sich derweil aufgehängt)
Der Support direkt vom Hersteller ist nicht existent – dreimal ein Formular ausgefüllt und hingeschickt, keinerlei Antwort erhalten.
Gemessen am Preis ist der Royaltek wirklich spitze. Mit entsprechenden Akkus hält er sehr lange durch, hat einen großen Speicher und ist unkompliziert in der Bedienung. Der Output ist Standard, sodass man nicht auf irgendwelche Spezialsoftware zum taggen angewiesen wäre.
Ob man eine zusätzliche LCD-Anzeige für LAT/LON oder Speicherkapazität braucht, ist Geschmackssache, ich habe den 3800er jedenfalls noch nicht voll gebracht …
Für einen GPS-Logger zählen für mich lange Laufzeit, großer Speicher, normale Akkus und hohe Empfangsempfindlichkeit und das alles hat der Royaltek.
Wie sehen denn die Erfahrungen nach ca. einem Jahr der Nutzung aus?
Ich stehe gerade selbst vor der Entscheidung eines Kaufs und bin leider noch nicht so ganz überzeugt. Abgesehen vom 3800er habe ich noch den 2300er, sowie den Holux n241 im Auge…
Würde mich sehr über einen akutellen (Langzeit-)Erfahrungsbericht/ Meinung freuen.
@frickelprofi: Erstmal für den rgm3800client vielen Dank. Dessen Existenz war einem meiner Entscheidunsgründe für den Tracker, den ich für Regatten verwende (dort sind keine Geräte mit einer Anzeige erlaubt),
Folgendes nur zur Info, vielleicht hilft es ja, einige Probleme zu lösen:
@linux:~> uname -srmo Linux 2.6.22.18-0.2-bigsmp i686 GNU/Linux @linux:~> ~/devel/src/rgm3800client/rgm3800-client -p /dev/ttyUSB0 ls 13 files in 524216 bytes 0 20080924 2 364 0 1 20080925 2 790 7280 2 20080926 2 1736 23080 3 20080927 2 383 57800 4 20080927 2 96 65536 5 20080928 2 3134 67456 6 20081002 4 284 130136 7 20081002 4 59 147272 8 20081008 4 3249 150812 9 20081008 4 138 345860 10 20081008 4 221 354140 11 20081012 2 3262 367400 12 20081017 2 4575 432716Jetzt habe ich die Loschtaste am Tracker betätigt und sofort ein Kommando abeschickt; Ergebnis:
> ~/devel/src/rgm3800client/rgm3800-client -p /dev/ttyUSB0 ls error: bogous response for record 12: LOG token not found: $LOG000,1*69 $LOG000,1*69 $PSRFTXTSFAM Test Report: Erase now*42 $PSRFTXTSFAM Test Report: Erase now*42Mach eine Weile liefert das Kommando dann wieder
> ~/devel/src/rgm3800client/rgm3800-client -p /dev/ttyUSB0 ls error: no response from device > ~/devel/src/rgm3800client/rgm3800-client -p /dev/ttyUSB0 ls -v $Id: rgm3800-client.c,v 1.23 2008/07/29 07:23:30 akurz Exp $ > ~/devel/src/rgm3800client/rgm3800-client -p /dev/ttyUSB0 status receive type 2 (time,long,lat,alt,vel) overwrite mode 0 (overwrite when full) interval 1 seconds receive status 0 (no RX) stored files 0 records in last file 0 unknown 1 -1 unknown 2 -1 unknown 4 0Wie gesagt, nur zur Info, ich sehe das nicht als Fehler.
Mir file übrigens auf, dass der Tracker trotz ‘overwrite when full’ den letzten Track einfach abgeschnitten hat.
Gruß, Martin
Kaum geschrieben, schon ist mir das Problem aufgefallen. Es scheint wohl so das der letzte Track bei mir nie vollständig heruntergeladen wurde. Ich hab es ein paar mal mit dem Royaltek Tool probiert und die Dateigröße war jedesmal die gleiche. Nachdem ich ein neues Log aufgezeichnet habe war die letzte Datei knapp doppelt so groß. Seltsam. Ich werd das gleich mal mit dem Tool hier probieren…
Hallo, mal eine ganze andere Frage zum Thema Royaltek RGM-3800. Habe das Gerät testweise im Sekundentakt loggen lassen. Nach rund 30 Minuten (1828 Waypoints) hört der Track seltsamerweise auf obwohl das Gerät noch rund 30 Minuten weiterlief. Das ist mir jetzt schon zum zweiten mal passiert und ich finde keinen Fehler. Danke
Hallo, es gibt eine neue Version http://www.kbdbabel.org/rgm3800-client.c mit zwei Änderungen:
1) der Satid/SatSNR-Bug ist repariert (Fredt Winkelmann, danke)
2) Endianess: uint32 und float-Rohdaten vom RGM-Logger gehen jetzt durch ntohl() durch, das sollte auch auf einem PPC-Mac funktionieren, habe das aber noch nicht testen können.
Wäre es auch möglich, eine GUI zu entwickeln und ein Programm, dass man ganz einfach starten kann, ohne Python etc zu installieren?
Ansonsten ein echt tolles Projekt.
Danke für die schnelle Antwort.
Ich habe auf dem MAC die Konvertierung in dieser Form durchgeführt
float fconv;
char *p = (char *)&fconv;
p[0] = *(uint8_t*)(bufp+k+7);
p[1] = *(uint8_t*)(bufp+k+6);
p[2] = *(uint8_t*)(bufp+k+5);
p[3] = *(uint8_t*)(bufp+k+4);
gs[i].lat = fconv;
und im “rgm3800-client.c” noch ein einen Fehler ausgemacht.
for(sat_record=0;sat_record<12;sat_record++) {
gs[i].satid[sat_record] = *(uint8_t*)(bufp+k+ /*28*/ 32 +sat_record*2);
gs[i].satsnr[sat_record] = *(uint8_t*)(bufp+k+ /*29*/ 33 +sat_record*2);
Nun läuft die Sache schon recht gut. Ich habe nun die Grundlagen, um in OBJC eine App draufzusatteln.
Ja, der Logger benutzt LE, genau wie i386, PPC ist aber BE. D.h. du musst alle mehrbytigen Eingabedaten auf PPC “in sich umdrehen”. Guck dir mal an wie in der libc “htons” und Konsorten implementiert ist, du brauchst es genau andersrum 🙂 (“Network byte order” = BE, also ist htons auf PPC ein nop…)
Ich habe rgm3800.py schon vor einiger Zeit so konfiguriert das es auf PPC funktioniert. Jedenfalls gab es damals einen Nutzer der mir das bestaetigt hat. Wenn das jetzt nicht mehr der Fall ist bitte melden.
Hallo Jan,
das NMEA-File sieht so aus:
$GPGGA,211146.000,50391380521820871687037328788534954295296.0000,S,42883064310092963117235958198566912.0000,W,1,00,,-16264573485056.0,M,0.0,M,,0000*6A
$GPRMC,211146.000,A,50391380521820871687037328788534954295296.0000,S,42883064310092963117235958198566912.0000,W,-1253199845407309586497763270341951488.00, 15.15,220808,,,E*63
$GPGGA,211151.000,49210332540840695006872391395053666304.0000,S,00000.0000,E,1,00,,5849461322680379754195489652736.0,M,0.0,M,,0000*55
$GPRMC,211151.000,A,49210332540840695006872391395053666304.0000,S,00000.0000,E,-00.00, 15.15,220808,,,E*7E
Ich bin auf der Spur. Es ist die Little Endian Schreibweise bei Float usw. Trotzdem freue ich mich über Lösungen.
Hallo Fredt, kannst Du mal ein Beispiel posten, bei dem die Werte abweichen?
Hallo miteinander. Bin auf die Seite gestoßen und hab nun den RGM 3800. Unter Mac G5 habe ich beides probiert RGM 3800.py und den compilierten Client. Dabei ist ein bei Lat und Lon die Darstellung unterschiedlich. Ich vermute Big und Little Endian haben ihre Finger drin. Ist es möglich, das C-Programm anzupassen?
Gruß Fredt
frickelprofi: Die drei Floatzahlen in RTDIST sind PDOP, VDOP, HDOP, also die (geschaetzte) Genauigkeit der Positionsangabe. Diese findest du beim Format 4 direkt vor den Satellitendaten ab Byte 26 als Short-Integers in der Reihenfolge HDOP, PDOP, VDOP. Sind als Fixkommawerte gespeichert, einfach durch 100 dividieren.
Ein paar der Felder beim Format 4 sind mir immer noch ein Raetsel, speziell die Bytes 24-25, ich tippe hier auf Flags zur Art des Satellitenlocks (2d/3d), sowie die Bytes 56-59.
Ich habe mein Auslesetool uebrigens in den letzten Wochen ueberarbeitet und nun “richtig” veroeffentlicht:
http://code.google.com/p/rgm3800py/
Es unterstuetzt jetzt die neuen Formate (mit Distanz und mit Satellitendetails), ist bei vielen Funktionen erheblich schneller als vorher und zeigt bei laenger dauernden Funktionen den Fortschritt an. Ausserdem ist der Code etwas aufgeraeumter und ich habe Tests hinzugefuegt.
>Die Dateien 1 3 und 5 würde ich gern auch als log_1, log_3 und log_5 abspeichern wollen.
kleine Einzeiler-Nachhilfe 🙂
for x in 1 3 5; do ./rgm3800-client get $x > log_$x; done
oder falls jemand z.B. die Daten 23 bis 42 haben will
for x in `seq 23 42` ; do ./rgm3800-client get $x > log_$x; done
Grüße!
Die Dateien 1 3 und 5 würde ich gern auch als log_1, log_3 und log_5 abspeichern wollen.
Für die anderen Sachen sag ich herzlichst “dankeschön!” 😉
Sobald ich mir einen neuen Logger (sicher wieder von Royaltek) gekauft habe, werde ich auf dieses schicke Script zurückkommen. Mein bisheriger wurde in der Slowakei geklaut. 🙁
Klasse das klappt ja richtig gut. Ich habe gerade einen der Tracks mal mit dem Originaldownload über Windows verglichen (Format 3 mit neuer Firmware) und es kommt mir so vor als hätte die Windowssoftware einige Daten anders behandelt oder gar unterschlagen… Über Google Earth betrachtet sind die Daten jedoch nicht zu unterscheiden.
Hallo, Update: http://www.kbdbabel.org/rgm3800-client.c
malenki:
> zum Einen würde ich gern z.B. log1, log3, log5 herunterladen.
> Kann man das so realisieren, dass ein rgm3800-client get 1 3 5
> diese drei Dateien herunterlädt?
ja, das geht, rgm3800-client get 1 get 3 get 5 > zusammen.nmea
> unknown 1 -1
> unknown 2 -1
> unknown 4 0
wie der Name schon andeutet, ich weiss es nicht,
vieleicht hat ja jemand anderes eine Idee.
> Löschfunktion
ist in der aktuellen Version drin.
Die neuen Kommandos sind “erase”, “date” und “fwversion”
Allgemein, geschätzte Sample-Kapazität
Laut Firmware:
> Capacity=8388608, Sector Size=65536, Sector No=128*64
also:
Mode*| Bytes | Samples
——+——-+——–
0 | 12 | 699008
1 | 16 | 524288
2 | 20 | 419328
3 | 24 | 349440
4 | 60 | 139776
* der Mode im mitgelieferten Datadownloader-Programm zählt
startend mit eins, also jeweils eins draufaddieren.
fred:
> neuen Formaten des Firmware-Updates
ist in Arbeit, Format 3 kann schon ausgelesen werden,
Format 4 ist noch unvollständig, der RTDIST-Datensatz enthält
drei Float-Zahlen die ich bisher nicht zuordnen konnte und
von denen ich nicht weiss, was die bedeuten,
Hallo, habe mir das Teil nun auch geholt, aber bei Installation der “Locr GPS Photo”-Software erhalte ich von Kaspersky Internet Security (Version 7) eine Fehlermeldung, dass ein Trojaner namens “Trojan-Dropper.Win32.Joiner.fd” gefunden wurde und die Installation wird abgebrochen.
Wer kennt dieses Problem und wie kann ich Abhilfe schaffen??
Danke für Eure Antwort.
Umh, also “selective availability” (das bewusste Verschlechtern des zivilen GPS Signals) ist IMHO seit 2000 abgeschaltet und mir sind keinerlei zuverlaessige Berichte bekannt das seither in unserer Region in irgendeiner Weise die Qualitaet des Signals herabgesetzt war. Das waere auch irgendwie kontraproduktiv wenn man weiterhin Lizenzabgaben fuer die Nutzung (bzw. Herstellung der Empfaenger) haben will anstatt das dies an Glonass oder Galileo gezahlt wird.
Wirklich massiv relevant fuer die Genauigkeit ist, wie viele Satelliten vom Empfaenger “gesehen” werden und in welchen Winkeln. Einen weiteren sehr starken Einfluss hat die Atmosphaere: Je nach “Wetter” der Ionosphaere koennen Signallaufzeiten schwanken und dies verfaelscht die Positionsbestimmung.
Die Qualitaet der Empfaenger ist damit sehr wohl wichtig fuer die Genauigkeit. Je empfindlicher der Empfangsteil um so eher koennen unter schlechten Gegebenheiten (Wald, Gebaeude, etc.) doch noch weitere Satelliten empfangen und damit die Position genauer bestimmt werden. Die SIRF III sind hier wirklich gut und so kann der RGM 3800 noch unter doch recht widrigen Bedingungen die Position bestimmen, z.B. im Inneren eines Passagierflugzeuges, in Gebaeuden oder im dichten Wald.
Als ich Ende Dezember an dem Ausleseskript gebastelt habe hatte ich meinen RGM 3800 oft Stundenlang an ohne ihn mehr als ein paar cm zu bewegen. Rund 80-90% der Messpunkte sind in einem 5m Radius, der Rest scheinbar chaotisch in alle Richtungen bis zu 50 Meter davon weg.
Danke für die schnelle Antwort.
Ich hab zuerst zwischen einem “Sony CS1” und “Wintec WBT-201” geschwank, habe dann aber die folgenden Praxistest gefunden und war dann doch ziemlich über die starken Schwankungen in den Tracks und somit auch der ungenauen Positionsbestimmung entäuscht:
http://www.stapel-ingmar.de/Sony_GPS_CS1_Tracker_Logger.html
http://www.stapel-ingmar.de/Wintec_WBT-201_Logger.html
Der Verlauf des Tracks scheint beim LGM-3800 ja wirklich sehr gleichmäßig ohne größere Ausbrecher zu sein soweit man das in Skyberts Bericht erkennen kann. Das Beispielbild ist ja leider aus recht großer Höhe aufgenommen.
Wichtig ist mir halt die relativ genaue Position. Bei einer Tagestour kommen bei mir schon mal 500-1000 Bilder zusammen. Die von Hand zu markieren wäre alles andere als Lustig.
Der 3800 ist mit der SIRF III Chipsatz ausgestattet, der sehr empfindlich ist. Die Genauigkeit der GPS-Ortung ist weniger von den Geräten, als von den Amis abhängig und wie gut bzw. schlecht sie das GPS Signal der Satelliten machen.
Zu den Hochzeiten des Irak-Kriegs, machte das US-Militär die GPS-Genauigkeit für die zivile Nutzung bewusst schlechter.
http://www.heise.de/glossar/entry/82aa53b7ffa8fba7
http://de.wikipedia.org/wiki/Global_Positioning_System
Die typische Genauigkeit liegt bei 1-5 Metern, das aber wie gesagt eher weniger von den GPS-Geräten abhängt.
Hi. Ich fotografiere gerne und veröffentliche häufiger Bilder z.B. auf Panoramio. Bis jetzt mach ich die Platzierung noch per Hand und würde mir gerne einen GPS-Tracker zulegen mit dem ich die Bilder referenzieren lassen kann.
Wie sieht den eure Erfahrung mit der Genauigkeit der Position beim RGM-3800 aus? 5, 10 oder 100 Meter? 🙂 Hab bis jetzt nichts dergleichen finden können.
Hi Frickelprofi !
Hast Du schon eine neue Version in Arbeit mit den neuen Formaten des Firmware-Updates ? Cool wäre in der Tat auch die Löschfunktion 😉
Gruss,
Fred
PS: eine Löschfunktion würde von den Nutzern sicher auch begrüßt 🙂
Danke für das C-Script, arbeitet wunderbar.
Nach zwei weiteren Features möchte ich fragen:
zum Einen würde ich gern z.B. log1, log3, log5 herunterladen.
Kann man das so realisieren, dass ein “rgm3800-client get 1 3 5” diese drei Dateien herunterlädt? (am besten fände ich ja, wenn das Script die Logs direkt auf den Datenträger schreiben würde)
Zur Zeit gebe ich für jedes Log “rgm3800-client get $Nummer > logNummer” ein
Oder sollte man sich lieber ein shell-script basteln, das diese Funktionen umsetzt?
zum Anderen gibt es seit dem Firmwareupdate drei neue Felder (oder sie fielen mir vorher nicht auf):
unknown 1 -1
unknown 2 -1
unknown 4 0
Ich würde gern wissen, was dort für Funktionen verborgen sind. Kann man das Script evtl in dieser Hinsicht aufbohren? 🙂
Auf Basis von Karstens Script und GSPbabel hab ich ein Applescript geschrieben, mit der der gewünschten Track vom RGM-3800 geladen und in eine klm-Datei umgewandelt wird.
Das Applescript findet ihr euch unter
http://www.pnklink.de/RoyalTek_rgp:3800.zip
um es auf eurem rechner verwwenden zu können müsst ihr am Anfang des scripts die “location” angeben wo das pythonscript und die gpsbabel-software auf eurem mac zu finden sind.
Ja, die Power CPU nutzt big-endian, Intel CPU und der RGM3800 verwenden little-endian Darstellung der Daten im Speicher. Ich habe das Python-Script so angepasst das es jetzt auf beiden Plattformen funktionieren sollte.
Ich hab zum Geburtstag den RoyalTek 3800 geschenkt bekommen.
Auf meinem iBook G4 funktioniert das pyton-script nicht korreckt.
Das c-programm kann ich leider auch kompilieren.
Liegt das evt. daran das mein Rechner noch kein Intel-Prozessor hat?
Habe auch das Tool ausprobiert, aber bei mir wollte es erst dann größere Tracks auslesen, als ich die packetsize verringert hatte (auf die Hälfte). Ansonsten lief wohl immer irgendein String voll, und es wurde am Ende abgeschnitten, was zu korrupten Daten führte.
Ich habe übrigens herausgefunden, was die letzte Zahl vor dem * in der $LOG108-Antwort bedeutet – es ist die Größe des aktuellen Files. Nach dem Stern steht dann wohl wieder eine Checksumme in Hex.
And now this again in English:
I finally found out what the last number just before the * in the $LOG108 answer means – it is the size of the current file. The number after the asterisk seems to be the checksum in hex.
Hallo Gabi,
vielen Dank für den Tipp, damit hat sich meine Frage ja schon erledigt 🙂
Werde mich auch an das Weiterfrickeln machen.
Gruß
Niklas
Hi all,
habe eben das nette kleine Tool von frickelprofi auf dem Mac ans laufen gebracht und dachte, ich teile mal meine Erfahrungen 😉
also: Kompilieren ging ganz simpel, .c Programm irgendwo ablegen, Terminal öffnen,
gcc rgm3800-client.c aufrufen und schwupps wird das executable a.out kreiert. Jetzt muss man nur noch seinen Port kennen, bei mir stellte er sich als tty.PL2303-0000101D heraus. Und los gehts…
./a.out -p /dev/tty.PL2303-0000101D status ./a.out -p /dev/tty.PL2303-0000101D ls ./a.out -p /dev/tty.PL2303-0000101D get 4 > 20080307-1.nmeamit gpsbabel nach kml umgewandelt und nun versuche ich mal, das bei maps.google.com hochzuladen… geht zwar irgendwie, und er zeigt auch den richtigen Kartenausschnitt an, aber keine Punkte auf der Karte… Stattdessen werden die Punkte in einer Liste links aufgefuehrt und haben komische grüne Dreiecke am Rand… da muss ich wohl noch ein wenig frickeln.
cheers
Gabi
Wer noch Software für den Mac / unter Linux sucht, um die NMEA-Files des RGM-3800 in ein anderes Format zu konvertieren, dem sei empfohlen. Auch mit graphischem Frontend für den Mac. Für die andere “Mausschubser”-Fraktion habe ich auch noch ein Bonbon:
Beides Programme, die entweder direkt unter der GPL-Lizenz stehen, oder “Donationware” sind.
Enjoy!
Hallo Markus,
danke für die rasche Antwort.
Ich habe halt nur keine Ahnung, wie ich den ganzen Kram (Compiler, Make usw.) dann einrichte. Ich habe früher schon mal mit Linux rumprobiert und auch versucht, Programme selber zu kompilieren, aber das hat irgendwie nie funktioniert 🙁
Das mit der Mailadresse wäre spitze.
Viele Grüße
Niklas
Da ich ja selbst keinen Mac nutze, aber das OSX ja mehr oder weniger ein FreeBSD ist, würde ich mal sagen, dass du eine C-Compiler (GCC) und ein Make Programm brauchst. Ich würde mal bei Frickelprofi anfragen, ob ich dir seine Mailadresse weiterleiten darf, wenn du möchtest.
Hallo,
ich bin seit heute Abend stolzer Besitzer eines RGM 3800. Unter Parallels funktioniert alles wunderbar, aber ich würde das Gerät auch gerne unter Mac OS zum laufen bekommen.
Eine ganz blöde Frage:
Wie kann ich denn unter Mac OS X einen C-Quelltext mal so eben kompilieren? Ich habe mal XCode installiert und da kann man den Quelltext von frickelprofi auch laden, aber wie wandele ich den denn in eine lauffähiges Programm um? Ich komme da irgendwie nicht weiter …
Vielen Dank für jede Antwort.
Niklas
Hallo nochmal,
vielen Dank Karsten für die Hinweise,
2*pi / 360 habe ich eingebaut, der Fehler mit den fehlenden Wegpunkten ist korrigiert.
Die Routine habe ich dazu umgeschrieben, daß nicht mehr der ganze Datensatz auf einmal angefordert wird, sondern nur ein Block von 456 Datensätzen (Wert durch Ausprobieren gefunden). Wenn dann in der Kommunikation ein Fehler erkannt wird, dann wird die Blockgröße reduziert.
There is a new version fixing some bugs:
http://www.kbdbabel.org/rgm3800-client.c
Mein Python-Tool fuer Mac OS X und Linux liegt hier:
http://www.kapet.de/rgm3800/
Ich sehe dieselben leichten Abweichungen der Gradangaben, wuerde aber inzwischen dazu neigen die Schuld auf das offizielle Windows-Tool zu schieben. (Nicht ausreichend genaue Konstanten oder sowas.)
frickelprofi: Der Logger speichert die Positionen intern in Radiant (“Bogenmass”), d.h. einmal rund um die Erde ist 2*pi. Der Faktor um auf Grad zu kommen ist also : 360/(2*pi) = ~57.3. Wenn du diesen Wert berechnest und generell double statt float verwendest wird es viel leichter die Schuld an den Abweichungen auf das Windows-Tool zu schieben 😉
Werte noerdlich des Aequators und oestlich vom 0-Meridian sind positiv, suedlich vom Aequator und westlich vom 0-Meridian sind die Werte negativ. (Ich wohne in Dublin, kann also zumindest einen zweiten Quadranten ausprobieren 😉
Die Geschwindigkeit in NMEA GPRMC Records ist wirklich Knoten, d.h. Seemeilen pro Stunde, mit 1sm = 1852m. Das passt schon in deinem Programm.
Noch eine Sache: Ich habe mehrfach, vor allem bei sehr langen Tracks, gesehen, das sporadisch Fehler eingestreut oder ein paar Bytes im Datenstrom fehlen. Ich will aber keine fehlenden Waypoints im Track haben, also lade ich jetzt die Wegpunkte in Batches zu ein paar hundert Waypoints herunter und wenn dabei was schiefgeht wird der ganze Batch weggeworfen und neu angefordert. (Die neueren Versionen vom Windows-Tool verhalten sich genauso.)
BTW: Es gibt hier neuere Firmware fuer den Logger:
http://www.royaltek.com/download/
Nach anderen Berichten im Netz ist das Update nicht ungefaehrlich, ich habs installiert und finde das es ein paar nuetzliche Aenderungen mitbringt: Log-Interval kleiner 5 Sekunden einstellbar und bei jedem Einschalten wird ein neuer Track begonnen.
http://aeropic.free.fr/RBT_2300/start.jpg
Hi All,
Here is a release of the PPC RBT_2300 dumper.
Here are the screenshots :
[img]http://aeropic.free.fr/RBT_2300/start.jpg[/img]
at start up : select the port number (default is GPSGATE or bluetooth)
[img]http://aeropic.free.fr/RBT_2300/dump1.jpg[/img]
during a file dump : >>> xxx / yyy
where xxx = current frame
yyy = number of frames to dump
[img]http://aeropic.free.fr/RBT_2300/prog.jpg[/img]
confirmation for configuration programming …
the screen bottom line is just for fun :
– it gives the current fix
– the green box is just to indicate that it is still alive (data comming in). if you switch off the GPS, the line indicates timeout ! and the box turns to red.
and the .CAB ;
http://aeropic.free.fr/RBT_2300/RBT_2300install.CAB
If you’re interested, I can release the source too
bye
Alain
Hi,
Rainer, thanks for the bugreport, the time-format-issue is fixed now.
I eleminated the worst hacks, large file download should not be a problem now. XOR-checksum-check is enabled now, thus the program will complain if checksum errors are detected.
There is a new command “dump” to download all track data at once, no need to write the usual one-line-scripts to do this.
Still not tested is the NMEA-East/West North/East-issue. I know the device behaviour here in germany 7E, 51N, but i dont know what data the RGM will store in the other three quaters of this planet. If someone has some bits of track data from there, this would be helpful, please contact me, rgm@www.kbdbabel.org
Yes, there are some deviations in lat/lon. For 7E/51N I assume this to be about +-1.5m N/S, and less E/W. I have no idea yet, how to fix this. If someone observes larger deviations, please contact me as well.
An other open issue is the speed. AFAIK the NMEA-speed-format is knots, but the conversion factor I have implemented is from km/h to mph, so the speed may be in mph format, as well in the vendor-supplied-program.
thats it for today, have fun.
http://www.kbdbabel.org/rgm3800-client.c
PS: its GPLv3 open source
Hallo frickelprofi,
nachdem ich mich heute wieder einmal sehr darüber geärgert hatte, dass ich zum lesen von Tracks aus meinem Royaltek immer Windows starten muss, habe ich nach einer Lösung für Linux gesucht und diese Seite gefunden. Habe Dein Programm sofort heruntergeladen, compiliert und getestet. Alles funktionierte auf Anhieb und ich konnte die Ausgabe mit gpsbabel in KML umwandeln und zu googleearth hochladen. Das Ergebnis sah in googleearth genau so aus, wie bei der Arbeit mit dem Windows Tool. Tolle Leistung! Allerdings sind die Werte für Longitude und Latitude nicht exakt identisch mit den Werten, die das Windows Tool schreibt. Besonders ist mir das falsche Format für das Datum aufgefallen. Dein rgm3800-client schreibt das Datum als DDMMYY während das Windows Tool korrekterweise YYYYMMDD schreibt. Trotzdem: Tolle Leistung. Danke.
Hello,
its me again. Its cold outside here in germany, so I did not use the RGM3800 for new data aquisition for openstreetmap.org.
So, i wrote a program to access the RGM3800 using my linux-box *yes*.
The program is experimental, alpha, full of bugs and dirty hacks but I dont want to leave the impatient ones among you waiting any longer.
The program can: *list files, *show the device configuration/status, *set some device parameters (interval, overwrite-behavoir, sample format) and most important *it can download your GPS-data (at least with some luck and “minor”?? errors).
The program cannot *check the XOR-sums, *download direction data (I have not found out, which bits they used to store this data, *download large files without error (known bug as a result of bad hacks)
Of course, its 100% command line and script compatible.
Thanks for your help!
http://www.kbdbabel.org/rgm3800-client.c
Hi sorry for my English but I cannot write in German. I just post here in English and in French !
If I understand well you want to develop a soft to communicate with the RBT2300/3800 under linux.
I’ve spend some time (too much !) to understand the comm protocol with my RBT and developped an equivalent software under .NET for my PDA.
Basicaly the RBT can be interogated via the serial port with
$PROY10x …….. * CS CRLF
it answers with
$LOG10x xx,yy,zz, ….. *CS CRLF
most answers are coded in ASCII and parameters are separated with comma
Only the LOG102 (dump) answer to PROY102 request includes binary parameters (sub-frames)
Each sub frame includes the following parameters (ddepending on the GPS mode):
– date en hexa HH MM SS each on a byte
– latitude en flottant IEEE DegrËs dËcimaux
– longitude en flottant IEEE DegrËs dËcimaux
– altitude en flottant IEEE m
– vitesse en flottant IEEE m/s
hope this helps ! I can provide a badly documented word document collecting frame dumps examples and the summurized syntax.
I can also distribute the .NET classes (in VB) if needed !
bye
Alain
Si j’ai bien compris vous cherchez à communiquer avec le RBT via le port sËrie.
Mon allemand est très très lointain je suis passË par une traduction automatique
Voulant dËvelopper un soft de dump du RBT2300 (le même en bluetooth) sur mon
PDA,j’ai passË pas mal de temps à analyser les trames du GPS et coder une appli
en VB .NET sur Win CE.
pour simplifier le RBT se commande par des trames :
$PROY10x …….. * CS CRLF
Il rËpond par des trames
$LOG10x xx,yy,zz, ….. *CS CRLF
La plupart des rËponses sont en ASCII avec paramètres sËparËs par des virgules
sauf la trame de dump (commande PROY102, rËponse LOG102 qui contient des donnËes
en hexa sous formes de soustrames)
Chaque sous trame contien selon le mode du GPS :
– date en hexa HH MM SS chacun sur un octet
– latitude en flottant IEEE DegrËs dËcimaux
– longitude en flottant IEEE DegrËs dËcimaux
– altitude en flottant IEEE m
– vitesse en flottant IEEE m/s
Hello frickelprofi,
First I’m sorry to write in English on this German forum.
I can’t read nor write in German, I used an automatic
translator to read your posts.
I’ve read your code rgm-3800-terminal.c and saw you can
write in English.
I’ll receive a GPS Royaltech RGM-3800 data-logger tomorrow morning.
I’m looking for a way to use it on Linux.
I’m not a serial programmer but I’m a programmer and I can
contribute by coding, testing, documenting etc.
Basically we need to read and set some parameters on the device,
and most important transfer data from it. I’ll be very happy
if we succeed.
Don’t hesitate to contact me directly my email is
gilles.lamiral@laposte.net
Thanks in advance.
Gilles.
Hi Karsten! Wollen wir daraus vielleicht ein Posting auf … nachbelichtet mit einigen Details machen?
Mein urspruenglich fuer den Mac geschriebenes Ausleseprogramm funktioniert auch unter Linux und scheinbar auch fuer den Royaltek 2300 (Bluetooth) Logger. Die fuer mich essentiellen Sachen funktionieren alle: Status, Liste der Tracks, Wegpunkte als NMEA Datei ausgeben. Evtl. baue ich noch ein die Konfiguration zu aendern, die Codes dazu habe ich schon. Bei Interesse bitte email an kapet@kapet.de
Hallo Leute,
RGM-3800 und Linux *MUSS* funktionieren (notfalls werde ich dafür sorgen):
Also, ich habe den Thread gelesen, ein Demo-Terminal-Programm gebaut
http://www.kbdbabel.org/rgm-3800-terminal.c
und siehe da, der RGM-3800 redet schonmal mir mir.
Eingabe: “$PROY108*2D”
Ausgabe: “$LOG108,2,100,100,1,0,5,0,5,519*6F”
Die Randbedingungen:
CONFIG_USB_SERIAL_PL2303=y
original linux-2.6.22
GPS-Tracker habe ich manuell vorher eingeschaltet.
Kann mir bitte jemand die mitgesniffte Kommunikation schicken, ich will und hab keinen Windows-Rechner um selbst zu sniffen,
vielen Dank schonmal.
Herzlichen Dank für den Tipp, den ich gerne aufgreife und in einem Posting veröffentlichen werde!
Auch für die die besten Wünsche für 2008!
Hallo Markus,
ich habe mir aufgrund Deiner Empfehlung nun den Royaltek RGM-3800 gekauft und getestet und bin mehr als zufrieden. Funktioniert wirklich 1A, ist super leicht und zuverlässig.
Was die Software angeht hätte ich da einen Tip für Dich. Schau Dir mal GeoSetter http://geosetter.de/index.html an. Ein starkes Programm, finde ich, das die GPS-Koordinaten sogar direkt in Kamera-Rohdaten schreibt. Und nicht nur das, er schreibt auch gleich die entsprechenden Ortsnamen in die Datei. Mit CR2-Fotos hab ich das ausprobiert und funktionierte bestens. Einfach den Bildern mit GeoSetter die GPS-Daten zuweisen und dann wie gewohnt weiterbearbeiten, z.B. in Lightroom, ohne Umwege wie GPS-Babel oder andere Programme.
Und man muß das Programm nicht mal installieren. Feine Sache.
Dir vielen Dank für all Deine wertvollen Artikel und die besten Wünsche für Dich und Deinen Blog im nächsten Jahr.
Hallo Tscherno,
danke für das Angebot, aber das Protokoll habe ich ebenfalls schon mit einem Sniffer in Windows unter die Lupe genommen. Das Binärformat scheint wohl jeden Datensatz als 12 Bytes zu übertragen, wobei LAT/LON und Zeit jeweils eine Gleitkommazahl einfacher Genauigkeit zu sein scheinen, habe ich aber noch nicht genauer angeguckt, weil der Rest ja erst mal gehen muß.
Ich brauche aber so einen Sniffer auch für OS X – um zu schauen, was nun tatsächlich über die Schnittstelle geht.
Ja, das könnte vielleicht helfen. Ein weiterer Ansatz wäre, wenn ich mir einen USBseriellen Konverter beschaffe, der den gleichen Chip benutzt wie der RGM-3800.
Damit ließe sich dann der Code testen, mit dem ich den GPS Logger auslesen möchte (man würde den Prolific 2303 dazu benutzen, sich mit einer seriellen Schnittstelle eines zweiten PCs zu verbinden – wenn sich mit den o.g. Parametern dann eine Kommunikation aufbauen läßt könnte das dann auch mit dem RGM-3800 gehen).
Wenn du möchtest, würde ich mal einen Aufruf starten. Vielleicht gibt es in den unendlichen Weiten des Internet ein paar Know-How Träger, die dir weiterhelfen können?
Ich habe seit ein paar Tagen auch einen RGM-3800 und wollte den auch unter Mac OS X benutzen und würde sogar Software dafür schreiben.
Mein Problem ist blos, daß weder der Treiber auf http://osx-pl2303.sourceforge.net/ noch der originale Treiber von Prolific sich dazu benutzen lassen, dem Gerät eine Antwort zu entlocken.
Wenn man unter Windows (läuft bei mir in VirtualBox – einer freien VM) in einem Terminalprogramm (ich benutze TerraTermPro) den Port auf 115200Baud, 8N1, keine Flußkontrolle einstellt und Zeilenenden als LF+CR sendet, bekommt man auch eine Antwort.
Auf $PROY108*2D antwortet das Gerät z.B. mit der Anzahl Tracks usw. Den String habe ich mittels eines seriellen Sniffers herausbekommen, leider habe ich keinen Sniffer für OS X gefunden, mit dem sich die Ein-/Ausgaben der von mir probierten Software überprüfen könnte.
Unter OS X und ZTerm oder minicom ließ sich diese Antwort mit beiden Treibern nicht reproduzieren. Ich bin aber auch nicht sicher, ob die Zeilenenden als LF+CR senden, wie das das Gerät erwartet.
Da ich sowieso ein Programm schreiben wollte, habe ich nach einem Beispiel für serielle Kommunikation gesucht und bin auf http://www.harmless.de/cocoa-code.php gestoßen. Das Testprogramm für die AMSerialPort Klasse habe ich so angepaßt, daß es 115200, 8N1 benutzt, LF+CR schickt und /dev/cu.usbserial benutzt – aber mehr als den Port öffnen und den String senden geht nicht.
Ich bin echt frustriert 🙁 Dabei finden sich im Netz jede Menge Erfolgsberichte, wo Leute mit dem Prolific 2303 (der USBserielle Konverter im RGM-3800) diverse Sachen machen, z.B. auch auf GPS Mäuse zugreifen.
Wow, Du bist ja schnell wie der Blitz.
Wollte gerade ergänzen, daß ich als 4. Kandidat noch den “QStarz BT-1000” entdeckt habe, der hat widerum einen MTK chipsatz und hält bis zu 27h.
Aber nun, da ich schon den ganzen Tag recherchiere, verliere ich langsam den Überblick und vor allem die Geduld.
Ich glaube, daß Vernünftigeste wird wohl werden, daß ich auf Deine geschätzte Meinung höre, mich für den Royaltek entscheide und schlafen gehe…
Ich selbst habe den Royaltek weil:
SIRF III Chipsatz: Geht zum Teil sogar in Gebäuden
Normale Batterien: Im Urlaub auch schnell mal in der Tanke oder im Supermarkt erhältlich und man kann immer ein paar dabei haben
Kein Klimbim: Einschalten und vergessen.
Loggt in normalen NMEA Datensätzen, die man z.B. mit GPS-Babel in alles andere konvertieren kann. Zusatztools zum taggen von RAW-Bildern gibt es kostenlos im Netz.
Großer Speicher
PREIS!!!!!
Ich bin sehr zufrieden.
Hallo!
Ich möchte mir einen GPS-Logger kaufen, um Fotos mit GPS-Daten zu versehen. Ich fotografiere meist in Canons CR2-Format (mit einer 20D). Für diese Ansprüche suche ich nun ein gutes Gerät und habe 3 mögliche Kandidaten gefunden:
– zum einen den oben beschriebenen Royaltek RGM-3800
– JOBO photoGPS
– Wintec WBT-201
Welchen findest Du am geeingnetsten? Hast Du Erfahrungen mit den Geräten?
Beim Royaltek gefällt mir, daß er normale Batterien benutzt. Beim Jobo photoGPS sollen die Akkus bis zu einem Jahr halten, die Frage ist aber, ob er auch kontinuierlich Daten loggen kann, wenn er nicht auf dem Blitzschuh montiert ist, weil beispielsweise eben der Blitz drauf ist. Der Wintec soll widerum einen Chip haben, der teilweise noch bessere Empfangseigenschaften haben soll als der SIRF-III Chipsatz.
Aber die Unterschiede sind vielleicht gar nicht so groß; die Frage ist, welcher ist am benutzerfreundlichsten und welcher unterstürtzt Software, mit der man auch RAW-Fotos taggen kann.
Jenö
Das einzige, was ich auf die schnelle gefunden habe, war “GPS Connect”, hier mal der Link: [a href = “http://www.chimoosoft.com/products/gpsconnect/” title = “Chimoosoft”. Hoffe der Link geht jetzt…
Aber vielleicht geht die Software auch direkt unter dem Mac, mein Royaltek kommt erst nächste Woche…
Soooo ich hab ihn eben ausgepackt und ne Testrunde gedreht. Unter Parallels funktioniert er auf jeden Fall. Mit dem Mac natürlich spontan nicht. Erstes Problem, nämlich USB-to-Serial-Bridge habe ich noch lösen können:
Hier gibt es nämlich die passende Kext für Mac OS:
http://osx-pl2303.sourceforge.net/
Was wir dann haben ist ein kleiner virtueller COM-Port der mit dem Receiver kommunizieren kann. Was wir noch nicht haben ist eine Software, die das Protokoll versteht. Hier würde es für den Mac schon ein paar Kandidaten geben, welche verschiedene Geräte unterstützen. Leider ist Royaltek wohl noch ziemlich neu bzw. einfach noch unbekannt. Ich hoffe dass sich hier bald was tut. Vielleicht mache ich mich auch mal selbst an die Analyse der Windows-Software. Recht komplex scheint es nicht zu sein.
Danke für die Blumen! 🙂
Keine Ahnung hab ich von Fußball – ehrlich!
So schlimm ist ja mein Dialekt gar nicht, ich kann halt meine Stimme nicht leiden, wenn sie wiedergegeben wird …
Auch zu mir ist einer unterwegs. Ich muss mal ein Lob für deine Seite los werden – die Tipps sind einfach klasse und der Mix aus Fotografie, Musik und den anderen Themen ist ziemlich einzigartig. In meinem Feedreader bist du ganz oben. Wovon hast du denn eigentlich keine Ahnung ? 😉
Ich freu mich schon auf die Videotutorials und keine Angst: Man versteht auch im Sauerland den fränkischen Dialekt 🙂
Beim Mac kann ich leider noch nicht mitreden, werde aber bald einen auf meinen Schreibtisch stellen – wird wohl erst einmal ein iBook werden, da ich mal ein neues Notebook brauche …
Danke für den Tipp – ist bestellt!
Ich hoffe, dass ich ihn mit meinem Mac zum fliegen bringe.