Differences

This shows you the differences between two versions of the page.

--- doc:appunti:hardware:gps_logger_i_blue_747 [2009/04/16 15:56] – niccolo
+++ doc:appunti:hardware:gps_logger_i_blue_747 [2019/10/10 22:47] – [Week Rollover Bug] niccolo
@@ Line 1: / Line 1: @@
 ====== MTKBabel ======
-:!: **NEW!** MTKBabel is now hosted on **[[https://sourceforge.net/projects/mtkbabel|Sourceforge]]**!
+MTKBabel is hosted on **[[https://sourceforge.net/projects/mtkbabel|Sourceforge]]**!
 **MTKBabel** is a Perl program to operate the **i-Blue 747 GPS data logger**. It should work also with other GPS devices based on the **MediaTek MTK** chipset. Starting with version **0.7** it offers also support for the **Holux M-241** data logger. It is free software released under the GPL license.
@@ Line 24: / Line 24: @@
 Options:
     -a                       Read all the log memory (overlapped data)
-    -b filename.bin          Do not read data from a GPS device, but rather read a
+    -b filename.bin          Don't read data from a GPS device, but rather read
-                             previously saved .bin file. Ignore -f option
+                             a previously saved .bin file. Ignore -f option
-    -c                       Create a gpx file with tracks and waypoints
+    -c                       Create a GPX file with tracks and waypoints
     -d debug_level           Debug level: 0..7
     -E                       Erase data log memory
     -f filename              Base name for saved files (.bin and .gpx)
     -h                       Print this message and exit
-    -i                       Ignore some error conditions and try to extract data
+    -i                       Ignore some error conditions, try to extract data
-    -l {on|off}              Turn loggin ON/OFF
+    -l {on|off}              Turn logging ON/OFF
     -m {stop|overlap}        Set STOP/OVERLAP recording method on memory full
-    -o log_format            Enable or disable log fields (FIELD1,-FIELD2,...), available fields:
+    -o log_format            Enable or disable log fields (FIELD1,-FIELD2,...),
+                             available fields:
                              UTC,VALID,LATITUDE,LONGITUDE,HEIGHT,SPEED,HEADING,DSTA,DAGE,PDOP,HDOP,VDOP
                              NSAT,SID,ELEVATION,AZIMUTH,SNR,RCR,MILLISECOND,DISTANCE
     -p port                  Communication port, default: /dev/ttyUSB0
-    -R                       Recover from disabled log: erase data and reset recording criteria
+    -R                       Recover from disabled log: erase data and reset
+                             recording criteria
     -r time:distance:speed   Set logging criteria (zero to disable):
-                             every 1-999 seconds, every 10-9999 meters, over 10-999 km/h
+                             every 0.10-9999999.90 seconds, every 0.10-9999999.90
+                             meters, over 0.10-9999999.90 km/h
     -s speed                 Serial port speed, default 115200 baud
-    -t                       Create a gpx file with tracks
+    -t                       Create a GPX file with tracks
     -v                       Print MTKBabel version and exit
-    -w                       Create a gpx file with waypoints
+    -w                       Create a GPX file with waypoints
+    -x                       Force reading Holux format
 Example:
@@ Line 61: / Line 65: @@
 If you encounter some problems, please run the program with the ''**-d 7**'' option and write me a mail with the output. You will find my address in the program itself.
-==== Credits ====
+===== Week Rollover Bug =====
+It turned out that several GPS based on the MTK chipset are affected by a **Week Rollover Bug**. You discover that your device is affected by the bug because the GPX files you save from it, will have a **timestamp badly in the past**.
+Actually I have two i-Blue 747 GPS data loggers. The older one is a **Model ID 001B**, which has already manifested the problem: today is **2019-10-10**, but GPX points logged have a timestamp of **2000-02-24**. If you do the math, you can find that there is a **difference of exactly 1024 weeks**. This means that the device internally stores timestamps using a **week counter of only 10 bits**. So exactly 1024 weeks after its //EPOCH// (the begin of the time it can handle), the timestamps rolls-back of that amount of time.
+The other logger of mine is a **Model ID 001D**, which instead is still recording correct timestamps today. I suspect that the week counter is nevertheless 10 bits, and just the hard-coded EPOCH is more recent. So the bug is **just to come in the near future**.
+===== Credits =====
 I wish to thank all the people behind the **[[http://sourceforge.net/projects/bt747/|BT747 project]]**: everything I made is derived from their work.