also ich bin auf der Suche nach dem richtigen GPS-Logger. Der i–Blue 747A+ und der Wintec WBT-202 sind mir bis jetzt ins aufgefallen.
Allerdings habe ich zwei Probleme:
Kann man die Tracks beider Geräte ohne Probleme auf einen Mac übertragen (via Bluetooth oder USB wär mir egal)?
Ich hab vor eine dreiwöchige Radltour zu machen und will den gesamten Weg tracken. Reichen da die 32MB von dem i-Blue aus, und wie viele Stempel kann ich dann ungefähr pro Minute machen?
Gibt es vielleicht ne Möglichkeit die Tracks via Bluetooth auf nen Ipod Touch zu übertragen?
Wenn ihr noch Tipps für andere Geräte habt, wäre ich sehr erfreut davon zu lesen …
Die MB-Angabe bei I-Blue ist gelogen, der hat in Wirklichkeit nur 4 MB Speicher. Aber die Megabyte-Zahl ist eh egal, das ist wie wenn man den Benzinverbrauch eines Autos in Verbindung mit der Lackfarbe setzt. Entscheidend ist, wie viele Log-Punkte zu speichern kannst. Ich habe den I-Blue 747 (Ohne A+), da stand in den Beschreibungen, er kann “Bis zu 120.000 Punkte Speichern”. Wenn man vernünftige Einstellungen vornimmt (Qualität und Zeit z.B. auch mitloggt) komme ich auf 95.000 Punkte. Also ist mir egal wie viele MB das sind. 95.000 bleiben 95.000
Im Sekundentakt gelockt ist das etwas mehr als einen Tag.
Wenn Du 21 Tage lang je 12 Stunden am Tag auf dem Rad hockst, könnte mein I-Blue im 10-Sekunden-Takt loggen. Dann wäre der Speicher knapp voll. Der Akku hielt am Anfang ca. 24 Stunden durch, jetzt nach 1,5 Jahren hält der deutlich weniger. Wobei ich in letzter Zeit auch viel mehr mit Bluetooth arbeitet, was auch Akku kostet.
Möchtest Du loggen um jede Kurve nachher 100% korrekt zeichnen zu können, ist der 10-Sekunden-Takt zu wenig. Kuren werden dann viel zu sehr geschnitten. Um zu sehen, wann Du wo warst, oder zum (leicht groben) Zeichnen von wegen, ist das aber Ideal.
Alles klar. Ich hab mir noch den Tripmate 852 angeschaut, allerdings ist es echt schwachsinn jedes mal neue Batterien zu kaufen.
Mir wäre es lieber die Kurven ordentlich zu tracken. Deshalb tendiere ich eher zu dem Wintec. Auf http://www.kowoma.de/gps/geraetetests/wintec_wbt202/wbt202_p1.html heißt es, dass:
“Die Datenverarbeitung mit dem WBT_Tool ist gelungen, man ist allerdings auf Windows-Systeme beschränkt, zumindest solange bis jemand ein Tool zur Auswertung der .TES-Dateien für MAC oder Linux schreibt.”
Gibt es da inzwischen irgendwas neues?
Und zu dem I-Blue 747A+: Prinzipiell wäre mir dieser lieber. Gibt es denn keine Möglichkeit via Bluetooth die Tracks auf ein Handy oder Ipod touch zu übertragen?
Wenn ich das richtig deute gibt es ein Tool für Mac - Bluetooth Verbindungen. Irgendwie mit Umweg über gpsbabel soll es auch funktionieren Schau mal hier: http://www.hexten.net/wiki/index.php/WBT-201
Georg
Edit: Der 202 hat doch eine Speicherkarte! Kannst du die nicht auch direkt am Mac auslesen?
nur zur Klarstellung, im Manual zum Logger beim Hersteller Transsystem steht “32Mb serial Flash ROM” und Mb ist nun mal MegaBit also MB ungleich Mb. Der Hersteller gaugelt da gar nichts vor. Manche Verkäufer (wissentlich/unwissentlich?) schon.
Ich habe übrigens eine i-Blue 747 (ohne a+) und bin damit seit 2 Jahren hochzufrieden. Die Speicher-Way-Point Anzahl ist natürlich abhängig was man alles loggt. Angabe beim i-Blue 747 A+ 125000 Waypoints. Ich kann meinen Logger auf meinen PDA Asus 696 via Bluetooth mit bt747 (Java Programm) entladen und einstellen. Laufzeit > 20 Stunden
Der Händler von Ebay wo ich des Teil gekauft habe, hat “Megabytes” ausgeschrieben als Wort. Aber klar, wenn der Hersteller schon so bescheisst und den Speicherplatz als “Megabit” angibt, obwohl diese Einheit absolut untypisch ist, kommen die kleinen Ebay-Garagen-Händler und machen “Megabytes” draus.
Kleine Info am Rande.
Der im WBT 202 verbaute Chip u-blox 5 hat mittlerweile den Nachfolger u-blox 6, wird aber offenbar noch nicht verwendet.
Das dürfte sich aber schnell ändern, da der 6er pin- und funktionskompatibel mit dem 5er sein soll.
Die Verbesserungen u.a.
wesentlich geringerer Stromverbrauch
etwas größere Empfiindlichkeit (3 dB)
Vielleicht werden ja auch noch div. Schwächen des WBT 202 ausgebügelt - wenn Wintec wieder dabei ist.
Ich hab mir vor Kurzem einem i-Blue 747A+ (für 60 €) gekauft und bin sehr zufrieden damit. Funktioniert 1A, und nach ein Mal Aufladen und mittlerweile über 24 Stunden Loggen (alle Tracks zusammengezählt) hält der Akku immer noch …
Ich will die Speichermoeglichkeiten mal etwas weiter ausloten. Das Folgende sollte fuer alle MTK / MTK II basierten Geraete gelten, also z.B. den BT747A(+) oder den QStarz BT-Q1000X.
Man kann bei diesem Geraet festlegen, was es alles aufzeichnet (UTC-Zeitstempel, Validity-Flag, Latitude, Longitude, Height, …). Das laesst sich z.B. mit der BT747-Software (freies Java Programm, sollte also auf dem Mac laufen) einstellen. Die wichtigsten Groessen sind
UTC Zeitstempel: 4 Bytes
Latitude und Longitude, jeweils 8 Bytes
Willst Du ausschliesslich die Tracks, waere sogar der Zeitstempel egal. Dann haettest Du minimal (weniger geht nicht fuer Tracks) 16 Bytes pro Trackpunkt. Der Speicher von 4MBytes ist in 64 Sektoren aufgeteilt, jeder Sektor hat mindestens 512 Bytes Verwaltungsinformation. Damit kann man insgesamt maximal 4064 Trackpunkte in einem Sektor speichern, also 260096 Trackpunkte insgesamt. Bei einem Trackpunkt alle 5 Sekunden (ebenfalls einstellbar) waeren das etwa 361 Stunden, bei 21 Tagen also Platz fuer 17 Stunden am Tag. Bei einem Trackpunkt pro Sekunde alles um einen Faktor 5 weniger.
Dieses Optimum wirst Du aber nicht ganz erreichen. Bei jedem Anschalten wird weitere Verwaltungsinformation geschrieben, mindestens eine Einheit pro Vorgang, manchmal 2 – oder immer zwei? (brother, I forgitt). Eine Einheit verbraucht 16 Bytes. Wenn Du zwischendurch die Konfiguration nicht aenderst, ist das alles. Ansonsten werden auch beim Aendern der Konfiguration weitere Einheiten a 16 Bytes verbraucht.
Aenderst Du die Konfiguration also nicht und schaltest Du das Teil nur ein- bis zweimal am Tag an/aus, ist der zusaetzliche Verlust nicht signifikant.
Nimmst Du den Zeitstempel hinzu und rechnest erneut, kommst Du auf knapp 14 Stunden am Tag (wenn alle 5 Sekunden ein Punkt aufgezeichnet wird.)
Nimmst Du weitere Informationen hinzu (werksmaessig sind das bei meinem QStarz BT-Q1000X noch Validitaets-Flag, Hoehe ueber WGS-84, Geschwindigkeit und Recording-Reason), gelangst Du auf 32 Bytes pro Trackpunkt bei Werkseinstellung. Es gibt jedoch noch viele weitere Parameter, die aufgezeichnet werden koennten. Wenn ich richtig addiert habe, kannst bis zu 52 Bytes + 10 Bytes * Anzahl Satelites in view pro Trackpunkt im Speicher ablegen.
Plausibilitaetscheck:
Bei nur Latitude und Longitude komme ich auf max 260.000 Punkte, bei Werkseinstellung auf 130.000 – abzueglich der zusaetzlichen Verwaltungsinformation. Das passt etwa zu der Aussage von DennisB. Ich sollte mich also nicht grob verrechnet haben…
Es lohnt sich also, darueber nachzudenken, welche Information Du wirklich aufzeichnen willst.
EDIT: Kleiner Nachtrag: Ich habe bei Werkseinstellung gerade 99.275 Punkte im Speicher bei 81% Fuellungsgrad, macht also bei vollem Speicher 122.561 Punkte. Der Rest ist bei mir Verwaltungsinformation (z.B. haefiges An-/Ausschalten).
ich glaube mit deinen Berechnungen in Bezug und der Speicherbelegung liegst du daneben.
zumindest bei meinem i-Blue 747 wird das nicht so Speicherfressend abgelegt. Es wird ein “internes” Binärformat verwendet, was wesentlich Speicherschonender ist. Ich habe mich mal zwecks dowload vom Logger mal damit beschäftigt. Falls dich das wirklich interessiert schau mal bei GPSBabel nach, dort ist irgendwo das Formt beschrieben.
Brauche ich nicht. Ich habe nicht nur die Spezifikation von Mediatek, sondern auch ein eigenes Programm geschrieben, dass in der Praxis bestens funktioniert :-)) Es spricht das komplette API des MTK-Chips.
So sieht ein Log in meiner GPX-Datei aus. Klar, das ist nicht das Rohformat, aber da sieht man deutlich mehr. Die drei Qualitätsmerkmale (HDOP, VDOP und PDOP), die Uhrzeit, die Höhe, die Anzahl der Satelliten.
@DennisB: Wenn Du die angezeigte Information (mindestens) mit dem 747 speicherst, wird Deine Angabe von “nur” 95.000 Punkte verstaendlicher.
Allgemein gilt folgendes: Der MTK hat ein Formatregister, welches signalisiert, welche Felder aktuell gespeichert werden. In jedem 512-Byte Sektorheader steht u.a. so ein Formatregister. Sodann wird bei jeder Aenderung ein Verwaltungseintrag mit dem neuen Formatregister im Speicher abgelegt. Das jeweils zuletzt geschriebene Formatregister sagt also, wie ein Record zu interpretieren ist, und (eingeschraenkt, s.u.) auch, wie lang er ist.
Das Formatregister hat 32 Bit, von denen beim MTK aber nur 19 genutzt sind. Man hat also insgesamt 19 Angaben, aus denen man auswaehlen kann, was aufgezeichner werden soll. Diese sind im Folgenden mit Laenge und Datentyp aufgezaehlt, wobei die Zahl die Anzahl Bytes bezeichnet, und U fuer unsigned, R fuer floating point, sowie I fuer integer steht:
UTC, I4, Zeit und Datum im Format time_t (Sekundengenau)
NSAT, U2, Bit 0-8: Zahl der sichtbaren Sateliten, Bit 8-15 Zahl der verwendeten Sateliten
SID, U4, Bit 0-7 ID des Satelliten, Bit 8 in Gebrauch, Bit 16-23 Zahl der sichtbaren Sateliten
ELE, I2, Elevation in Grad des SID
AZI, U2, Azimuth in Grad des SID
SNR, U2, SNR des SID
RCR, U2, Grund der Aufzeichnung, Bitmaske, nach Zeit, nach Geschwindigkeit, nach Entfernung, durch Knopfdruck, herstellerspezifisch
MS, U2, Millisekunden, Ergaenzung zu UTC.
Ausgenommen der SID-Daten werden alle Felder je nach Konfiguration ein oder keinmal pro Record abgelegt. Die SID-Daten hat man einmal fuer jeden sichtbaren Sateliten. Sofern man diese Daten aufzeichnet, haengt die Recordlaenge also von der Anzahl der sichtbaren Sateliten ab. Das ergibt eine Maximallaenge pro Record (in Bytes) von 52 + 10 * (Anzahl sichtbarer Sateliten), wie oben schon einmal geschrieben.
Jetzt kann jeder nachrechnen, wieviel Punkte bei welcher Konfiguration in den Speicher passen. Wenn ich mich recht erinnere, kann man auch alle Felder einzeln mit der BT747 Java-Software an- oder abschalten.
vorneweg es geht nicht um Besserwisserei oder Rechthaberei. Was das Format des MTK betrifft hatte ich oben das
“…raw binary format created by the MTK …” Format gemeint was im Logger abgelegt wird und als Binarystream gelesen wird
und mit dem Original Downloadtool einen Binärfile aufder Platte ablegt. Das Binärformat ist hier beschrieben http://spreadsheets.google.com/pub?key=pyCLH-0TdNe-5N-5tBokuOA&gid=5 du redest glaube ich vom GPX-Outputfile. Oder habe ich da was falsch verstanden?
Hallo Achim, ich weiss nicht, was Dich auf GPX gebracht haben koennte, daher noch einmal ganz deutlich:
Ich rede in diesem Zusammenhang schon immer ** a u s s c h l i e s s l i c h **, d.h. nur, ueber das Binaerformat.
Schon immer schliesst auch alle anderen Beitraege, in denen ich mich zu MTK aeussere, vollstaendig mit ein. MTK hat schliesslich mit GPX nix zu tun.
Ich hatte auch geschrieben, das ich ein eigenes Programm erstellt habe, das mit dem MTK-Chip spricht. Wie haette ich das wohl tun koennen, ohne das Binaerformat zu kennen?
Und noch eins, die von Dir zitierte Quelle ist mir auch bekannt – schon seit langem.
ok. Da hatte ich wohl nicht richtig gelesen bzw. falsche Schlüsse gezogen…sorry. In welcher Sprache ist dein Tool geschriebn. Ist das im Source verfügbar?
Danke für den Link kannte ich schon aber doppelt hält besser!
Ist letztlich eine Abstraktion des ganzen MTK-API, durch die MTK-API-Calls als Methoden mit Java-Datentypen aufgerufen werden koennen.
In Bezug auf den Logger habe ich ein Interface fuer einen LogHandler definiert, mit einer festen Struktur fuer einen Logrecord. Erinnert etwas an SAX. Man kann dieses Interface implementieren und die abgerufenen Daten on the fly in gewuenschter Weise verarbeiten. Es wird also z.B. kein File im Binaerformat erzeugt, wie die BT747 Software das tut. Aktuell habe ich zwei Handler implementiert: einer schreibt zu Debugging-Zwecken auf die Console, ein anderer importiert die Daten direkt in eine Derby-Datenbank. Letzterer macht noch ein bischen mehr, er verwaltet Datenquellen, erzeugt automatisch Tracks etc. Das schoene: wie bei SAX kann sich jeder seinen eigenen Handler implementieren.
Neben dem LogAPI spricht der MTK-Kern auch alle anderen API-Calls, wie z.B. hier http://www.rigacci.org/wiki/lib/exe/fetch.php/doc/appunti/hardware/gps/mtk_nmea_packet_0.8_transystem.pdf beschrieben. Der MTK sendet (gemaess Konfiguration) im Sekundentakt NMEA-Saetze ueber die USB- und Blauzahn-Schnittstellen. Mein MTK-Kern bietet hier die Moeglichkeit, beliebige Listener zu registrieren, um diese Saetze online zu verarbeiten.
In mancher Hinsicht ist mein Programm der BT747 Software aehnlich, in anderer ist es ganz anders. Das sollte aus dem beschriebenen schon hervorgegangen sein.
Sind die Quellen verfuegbar? Nun, ich koennte sie unter der GPL oder LGPL veroeffentlichen, denn die Software ist mein Privatvergnuegen. Zunaechst eingeschraenkt auf den MTK-Kern. Der Rest muss erst mal fertig werden. Ich koennte dafuer auch – soweit meine Zeit dies erlaubt – Support leisten. Aber ich wuerde keine Webseite aufsetzen, um die Software dort anzubieten. Da muesste mir schon jemand was zur Verfuegung stellen.
Zu dem noch nicht fertigen Rest: Der ist teils aehnlich der BT747 Software, teils aber auch nicht. So operiert er z.B. voll auf einer (embedded) Derby-Datenbank, in der man alle seine Tracks und POIs verwalten kann. Wichtiger ist aber der modulare Aufbau, um den ich mich bemuehe: Er basiert naemlich auf der RCP Platform (Eclipse Rich Client Platform). D.h. man kann die Anwendung durch Plugins ergaenzen. Dafuer muss man aber die RCP kennen…
Ach ja, noch ein Unterschied: Die kartenbasierten Darstellung programmiere ich nicht selbst. Hier greife ich auf OpenLayers zurueck. Dazu wird ein Browser gestartet (aktuell noch nicht embedded, aber das kann die RCP auch). Da die RCP auch Jetty enthaelt, werden die Tracks etc (aktuell kann ich noch keine POIs) via Servlet zur Verfuegung gestellt. Also hier ein ganz anderer Ansatz als bei BT747.
… mmmh hört sich gut an und riecht nach viel Arbeit. Was eventuellen Serverplatz und freie Software betrifft ist der Autor von RouteConverter sehr kooperative, nur so als Hinweis…
gibt es ein Tool für Mac - Bluetooth Verbindungen. Irgendwie mit Umweg über gpsbabel soll es auch funktionieren Schau mal hier: 
