Navilock NL-456DL EASY LOGGER

Hallo,

schade, dass die Diskussion bzw. Entwicklung von bibomator/thomasschaefer hier mittlerweile zum Erliegen gekommen ist. So hab ich mich mal schnell selbst dran gemacht, einen Ersatz für das Win-Tool zu entwickeln, der ohne so nervige Funktionen wie den IE-Autostart auskommt und zudem auch unter anderen Betriebssystemen als Windows einsetzbar ist. Navilock wollte (oder nach eigenen Angaben "aus rechtlichen Gründen" konnte) mich dabei nicht unterstützen, geschafft hab ich's trotzdem

Wenn man mal verstanden hat, wie die Datensätze aufgebaut sind und abgespeichert werden, stellt das auch eigentlich kein großes Problem dar. Zumindest mit der von mir eingesetzten Firmware 1.0.5.6 musste ich weder unter Windows noch unter Linux irgendeinen ominösen "Auslesemodus", wie von bibomator erwähnt, aktivieren, sondern konnte einfach so die Datensätze aus der NVPIPE.DAT auslesen.

Außerdem in der NVPIPE.DAT gespeichert sind die Konfigurationseinstellungen. Zumindest den Teil davon, der auch über das Win-Tool verändert werden kann, konnte ich dabei bereits nachvollziehen. Der Größe des belegten Speichers nach zu urteilen, gibt es da aber noch Platz für viele Optionen mehr. Ich nehme allerdings an, eine andere Konfigurationssoftware als das Win-Tool ist nicht zu bekommen, geschweige denn irgendeine Art von Dokumentation, was man da noch einstellen/auslesen könnte?

Im Anhang findet ihr nun den Quellcode (und für Windows-Anwender ne Binary) eines ersten kleinen C-Programms, das sämtliche Tracks im Speicher ausliest und als GPX ausgibt. Es erzeugt dabei wirklich nur die Trackpunkte, es berechnet im Gegensatz zum Win-Tool keine Geschwindigkeiten oder Richtungsangaben und es ignoriert derzeit auch alle Push-Log- oder Shake-Mode-Punkte (die Punkte sind natürlich im Track, werden aber nicht gesondert ausgewiesen). Einzelne Tracks werden jedoch korrekt separiert.

Getestet hab ich das Auslesen bisher nur mit meinen eigenen kurzen Teststrecken, weshalb es schön wäre, wenn ihr das ganze mal mit euren eigenen Logs probiert oder mir für die genauere Analyse eure NVPIPE.DAT zur Verfügung stellt (per Mail an naviread.20.webmeister@spamgourmet.com). Insbesondere von Interesse wäre:
- Logpunkte, die auf einem südlichen Breitengrad und/oder westlichen Längengrad liegen (da ich bisher nur die Kombination N/E testen konnte und nicht weiß, wie sich die Darstellung dieser Koordinaten möglicherweise unterscheiden)
- Logs von anderen Firmwareversionen (für den Fall, das irgendwann das Format geändert wurde)
- Einsatz mit einem Wintec WPL-1000 (das Gerät scheint zwar baugleich zu sein und die Firmware ist vermutlich auch nur ne Kopie, aber man kann ja nie wissen)
- Einsatz auf einem anderen Betriebssystem als Windows XP SP2 32-bit bzw. Ubuntu 8.04 64-bit, bei den beiden gab's bei mir keine Probleme

Bezüglich der weiteren Entwicklung ist geplant, noch ein zweites Tool zur Konfiguration des Loggers zu erstellen. Wie bereits erwähnt, konnte ich soweit nachvollziehen, welche Einstellungen wie abgespeichert werden und ein erstes Testtool, das zumindest die aktuellen Einstellungen wie im Win-Tool ausgibt, existiert auch bereits. Allerdings wäre es natürlich ungemein praktischer, die Einstellungen auch ändern zu können, hier fehlt allerdings noch etwas Entwicklung, zumal manche Einstellungen möglicherweise durch eine Art Checksumme geschützt sind (neben dem Byte, das den Wert der Einstellung repräsentiert, ändern sich da auch noch zwei andere, für eine ganze Gruppe von Einstellungen immer gleiche Bytes, bislang keine Ahnung, was das soll).

In die eigentliche Anwendung zum Auslesen der Tracks muss auf jeden Fall noch eine Möglichkeit zur Ausgabe der Push-Log-Punkte eingebaut werden, alle anderen Aufgaben (Auswahl eines bestimmten Tracks, Berechnen von Geschwindigkeiten, ...) dürften auch nachgelagerte Programme übernehmen können. Sollte euch aber noch sonst was praktisches Einfallen, guck ich gerne mal, ob ich das noch mit eingebaut krieg.

Und zum Schluss noch was für Bastler: neben der NVPIPE.DAT existieren noch drei weitere Dateien, die wohl irgendwie zur Interaktion mit dem Logger dienen. Bei SFIO.CTL und SFIO.RSP könnte man dem Namen nach irgendeine Kommunikationsschnittstelle vermuten, nach dem Motto "schreib deine Befehle nach CTL, les die Antworten aus RSP". Aus dem binären Kram, den das Win-Tool beim Start da in die CTL-Datei schreibt, bin ich allerdings noch nicht schlau geworden. Genausowenig weiß ich, wofür die VPIPE.DAT dienen soll. Wenn jemand da was rausfinden kann oder es vielleicht Dokus zu ähnlichen Systemen gibt, alle Hilfe ist willkommen.

Gruß
webmeister

PS: Was mir grad noch aufgefallen ist: Zu welchem Zweck auch immer enthält die Firmware-Datei 1.0.5.6 (NL456DL.img), die es bei Navilock zum Download gibt, ebenfalls einige Trackpunkte im gleichen Format wie sie der Logger benutzt. Zusammengesetzt ergeben sie eine Route durch Berlin und Umgebung, die laut den Zeitstempeln Ende September 2007 entstanden ist.

neue Version siehe Posts weiter unten

Zitat

Original von webmeister
Ersatz für das Win-Tool zu entwickeln, der ohne so nervige Funktionen wie den IE-Autostart auskommt und zudem auch unter anderen Betriebssystemen als Windows einsetzbar ist. Navilock wollte (oder nach eigenen Angaben "aus rechtlichen Gründen" konnte) mich dabei nicht unterstützen, geschafft hab ich's trotzdem

Ich überlege mir auch, so einen Datalogger zu kaufen. Aber das wirkt nicht gerade vertrauenerweckend. Gibt es einen Logger, der einfach nur das Standard NMEA-Format speichert? Dazu habe ich genügend Software zur Auswertung. Oder zumindest sollte das Datenformat gut dokumentiert sein, damit man die Daten selbst mit eigenen Programmen verarbeiten kann (ohne lästigen Umweg über Win-Tools).

Ich hab zu Hause schon massig Elektronik-Schrott liegen, für den es mal einen Windows-Treiber gab, aber jetzt mit aktuellen Betriebsssytemen nicht mehr funktioniert. Man kauft einen Scanner (Markenware) und 3 Jahre später darf man den wieder wegwerfen, weil die Firma keinen Support für eine neue Betriebssystemversion bietet. Wenn die Schnittstellen sauber dokumentiert wären, könnte man das zumindest unter Linux noch einsetzen. Aber so ist es einfach nur noch Schrott geworden. Ich achte schon länger bei Investitionen darauf, dass Schnittstellen dokumentiert werden, sowohl bei Software als auch bei Hardware.

Vorausgesetzt Navilock ändert das Format der Aufzeichnungen mit zukünftigen Firmware-Versionen nicht (warum sollten sie?), solltest du den Logger praktisch überall auslesen können, wo du nen FAT-formatierten Datenträger per USB angeschlossen bekommst und oben gepostetes C-Programm kompilieren kannst

Ansonsten gibt's zum Beispiel bei OpenStreetMap eine gute Übersicht über auf dem Markt befindliche GPS-Empfänger und -Logger.

Danke für die Info. Die Übersicht ist schön reichhaltig.

Also, Navilock verwendet das "USB mass storage device class (USB MSC)" Standardprotokoll mit FAT-Filesystem? Das ist gut so, kann überall benutzt werden, Linux etc. Ich frag mich immer wieder, ob GPS-Logger das können. Leider sind Produktbeschreibungen in solchen Punkten meist ziemlich uninformativ.

Als Datenformat des Logs wäre mir das NMEA am liebsten, weil dort auch Angaben zur Signalqualität drin sind. Weiterhin fehlt die Geschwindigkeit, die aus der Navigationsgleichung viel genauer herauskommt als durch einfache Ortsableitung aus den GPS-Fixes. Oder ist die doch noch versteckt irgendwo in dem Binärformat?

Zitat

Original von navtester
Also, Navilock verwendet das "USB mass storage device class (USB MSC)" Standardprotokoll mit FAT-Filesystem?

Ja, ich kann zwar nicht dafür garantieren, dass sie sich an sämtliche Spezifikationen halten, aber auf meinen Testsystemen (s.o., Windows XP und Ubuntu) gab es keine Probleme.

Zitat

Original von navtester
Als Datenformat des Logs wäre mir das NMEA am liebsten, weil dort auch Angaben zur Signalqualität drin sind. Weiterhin fehlt die Geschwindigkeit, die aus der Navigationsgleichung viel genauer herauskommt als durch einfache Ortsableitung aus den GPS-Fixes. Oder ist die doch noch versteckt irgendwo in dem Binärformat?

Nein, soweit ich das erkennen kann, loggt der NL-456DL nur Zeitstempel, Längengrad, Breitengrad und Höhe. Viel mehr Platz ist in den 16 Byte großen Datensätzen auch nicht.

Sehr schön Mangels Python-Kenntnissen meinerseits hab ich mal das C-Programm ebenfalls "etwas" erweitert:

Als größter Brocken ist es nun möglich, alle Einstellungen, die über das Win-Tool zugänglich sind, auch hiermit zu verwalten. Das Anzeigen stellt nirgends ein Problem dar, das Setzen der Optionen ist allerdings nicht überall problemlos möglich. Werden im Win-Tool irgendwelche der GPS-bezogenen Einstellungen geändert, ändern sich neben den Bytes für die Einstellung selbst auch noch die zwei Bytes an Position 0x38E. Ich hab keine Ahnung, was diese zwei Bytes repräsentieren (vermute mal eine Art Checksumme, wofür auch immer), und ob die GPS-Einstellungen auch ohne Anpassung dieser zwei Bytes geändert werden können oder ob das irgendwas kaputt macht. Wäre schön, wenn das jemand testen mag oder jemand ne Idee hat, was diese Werte da sollen und wie sie sich berechnen lassen.

Zweite praktische Funktion ist eine Analyse-Möglichkeit der NVPIPE.DAT, die alle Felder mit bekannten Wertebereichen daraufhin untersucht, ob dort bislang unbekannte Werte stehen und ggf. deren Position und Wert ausgibt. Das betrifft derzeit also ein paar der Einstellungen sowie die ersten zwei Bytes der Trackpunkt-Datensätze. Beim Test in meinem Datenbestand fanden sich da auch gleich zwei aufeinanderfolgende Datensätze mit recht großen Werten (251-255) in diesen beiden Bytes. Das Win-Tool scheint diese jedoch komplett zu ignorieren, ich konnte sie weder in den Google-Maps-Karten noch in der GPX-Ausgabe finden. Zudem haben die Punkte recht merkwürdige Höhenangaben (-13845m bzw. 32747m), was wohl auf irgendeinen Softwarefehler im Logger oder sehr schlechte Empfangswerte hindeuten könnte.

Daneben gibt's auch noch ein bisschen neuen Kleinkram:
1. Ausgabe der Push-Log-Punkte
2. Ausgabe der Metadaten "bounds" für die minimalen und maximalen Koordinatenwerte
3. höhere Genauigkeit der Koordinaten: Der Logger speichert hier wohl 7 Nachkommastellen, das Win-Tool hat als GPX aber gerundet und nur 6 davon ausgegeben, mein Programm also auch.
4. Unterstützung für negative Höhen: Die gespeicherten Werte sind einfach als vorzeichenbehaftete Zahl zu interpretieren. Ich vermute mal, analog wird auch bei südlichen/westlichen Koordinaten vorgegangen, sodass diese nun ebenfalls funktionieren sollten (testen kann ich das mangels Daten leider nicht).

Da ich fast den gesamten Code neu geschrieben hab, und er mittlerweile auch recht umfangreich geworden ist, kann sich da durchaus noch der ein oder andere Bug versteckt haben. Hinweise sind immer willkommen.

Zitat

Original von vboehm
Im Übrigen ware jetzt noch mal zu klären, was eigentlich passiert, wenn jemand den Buffer mit mehr als 94.000 Punkten vollschreibt. Laut Doku soll das Teil ja die ältesten Daten überschreiben; ist bloß die Frage, wie sich das dann in der NVPIPE.DAT niederschlägt.

Noch ein Fall, den ich bislang nicht bedacht hab. Vom Beginn des Logdatenbereichs bis zum Ende der Datei ist Platz für genau 94207 Datensätze. Ich denke kaum, dass der Logger so nett sein wird, und die Datensätze passend verschiebt, also der erste immer der älteste ist, sondern er wirklich einfach vorne wieder anfängt drüber zu schreiben. Entsprechend müsste man bei der Ausgabe erstmal den ältesten Datensatz suchen, um keinen Müll zu produzieren. Um das aber wirklich zu testen, fehlen mir noch knappe 40000 Punkte.

Zitat

Original von vboehm
Um jetzt vollständig von dem lästigen Windows loszukommen, fehlt nur noch ein zusätzliches kleines Tool, mit dem man die User-Log-Einstellungen ändern und vor allem den Speicher löschen kann.

Den Speicher zu löschen könnte schwieriger werden als es klingt. Ich hab mal testweise einzelne Datensätze wieder mit 0xFF überschrieben, sodass sie aussehen, wie normaler, unbelegter Speicher. Das klappt auch soweit problemlos, allerdings tauchen die zuvor gelöschten Datensätze beim nächsten Start des Win-Tools wieder auf, sind also nicht wirklich weg. Verantwortlich dafür dürfte vermutlich der Kommunikationsmechanismus über die SFIO-Dateien sein (siehe mein erster Post), von dem ich aber nach wie vor keine Ahnung hab.
Ich hab keine Idee, welchen Zweck diese "Wiederherstellung" der Datensätze hat und wo der Logger die Daten herholt. Da müsste es ja irgendwo einen von außen unzugänglichen, zweiten Speicher geben, der sämtliche Daten nochmal vorhält. Sehr komische Sache...

Gruß
webmeister

neue Version siehe Posts weiter unten

Sehr gut, danke für den Hinweis. Mit Byte 3 meinst du das dritte Byte in der Datei oder das Byte an Offset 3 (was dann das vierte wäre)? Möchte das bei meinem Logger derzeit nicht testen, da sammel ich grad Daten, um mal zu sehen, was passiert, wenn der Speicher vollläuft.

Gruß
webmeister