|
2012-01-26 10:54
|
geoLogs.2012.01.25.ZIP (7,630 bytes) |
|
|
Ich kann die Probleme mit den Holux-M241-Tracks nur bestätigen (.trl und .kml). Man bekommt beim Laden der Dateien die Fehlermeldung, dass die Tracks keine Zeitinformationen beinhalten (was natürlich nicht stimmt). Ich habe den Fehler erst bei mir gesucht und lange probiert, bis ich (glücklicherweise) hier im Forum gefunden habe, dass ich wohl offenbar nicht der Einzige bin. Der Workaround über das Konvertieren in eine .gpx-Datei funktioniert Gott sei Dank! Ist aber sehr zeitaufwändig, wenn man sehr viele .trl-Dateien besitzt, da man diese nur einzeln konvertieren kann (mit dem Holux-Utility). Ich hatte mich schon sehr gefreut, dass man die .trl-Dateien mit Geosetter direkt verwenden kann! Wäre schön, wenn der Fehler in der nächsten Version behoben wäre. Vielen Dank! |
|
|
[corrected to describe parity byte] The Holux TRL binary files come in two formats, depending on your device's firmware version. There used to be web pages describing this, but it seems like the English links may have gone stale. So here is what I have found. The file format uses a little endian (Intel) convention. For firmware versions 1.12 and older, the binary format was a 16-byte record as: [bytes 00-03] unix epoch time (uint32) [bytes 04-07] latitude (float32) [bytes 08-11] longitude (32-bit float) [bytes 12-14] altitude in meters (*1) [byte 15] parity byte (XOR even parity *2) For firmware 1.13, a speed field (m/s) was added, making a 20-byte record as follows: [bytes 0- 3] unix epoch time (uint32) [bytes 4- 7] latitude (float32) [bytes 8-11] longitude (float32) [bytes 12-14] altitude in meters (*1) [byte 15] parity byte (XOR even parity *2) [bytes 16-19] speed (m/s) (float32) (*1) This field is a 24-bit floating point number (an ieee-754 with the least significant bits of the mantissa omitted). The most significant bit of byte 14 is the most significant bit of the floating point number (the sign bit). One way to decode this field is to read bytes 12-15 as a little endian integer, then shift up by 8 bits. (*2) The parity byte is such that XORing all the bytes in the record will result in 0 (even parity) In my personal processing, I autodetect between the two formats by attempting to decode the data as each format, then seeing which one produces data with the most lat/long values that are within +-90/+-180 degrees. This seems to work pretty well. Some additional checks could be checking for appropriate file length, and checking that the timestamps increase by a small amount each record. I am attaching logs demonstrating tracks in each of the two firmware versions, along with KML files to allow you to unambigously verify the data. See also: http://hi.baidu.com/7hi7r09o3k/blog/item/5e1da2043769da3f6b60fb51.html |
|
2012-05-01 21:20
|
m241_samples.zip (32,978 bytes) |
|
|
Please try my new GPSBable-Version with fixes for Holux TRL-files. I hope it solve the problem. Please report See: http://www.geosetter.de/mantis/view.php?id=965 I am sorry but I can't read this chinees or japaneese web page. I've tested the files from the atteched TRL-Files and it works. See speed in the hardcopy "Holux-TRL-Test.jpg" |
|
2012-09-09 11:08
|
Holux-TRL-Test.jpg (219,330 bytes) |
|
|
I also have had problems with retrieving good data from my Holux M-241. In my case, the retrieved files, even after a day's logging, were only about 5K and consisted of the beginning and ending waypoints and perhaps one or two intermediate ones. The solution that works for me is to have the appropriate Silicon Labs USB driver(eg, the correct one for Win 7) but to roll the logger utility back to the one that came with the logger, v1.1.0.46 rather than the latest version (v1.1.0.48). That combination seems always to work flawlessly with Geosetter. Hope that helps. |
|
|
I use GPSBabel (GUI) exclusively to read directly from the M-241 and write GPX files containing all tracks. No need to use crappy Holux utility and proprietary TRL file format. |
- Anonymous
