Holux M-241 gps weeks rollover issue - unlock track filter days option

[jonaszwojcik]

M-241 is not supported by Holux
http://market.holux.com/EDM/2019/0429/20190429_weekvalue.html

Official software is not working (ezTour, HoluxLoggerUtility) after gps weeks rollover
The software cannot read the log from device ("No data in device" error).
BT747 have the same problem.
But GSPBabel can read and convert the log from M241 :)
BIG THANKS!!!!
But the date is in 1999 ;)

Can you please add option to convert the time for M241.
something like you did for skytraq
https://www.gpsbabel.org/htmldoc-1.6.0/fmt_skytraq.html

I think it may be worth to add global weeks rollover option - not only per device/format

Thanks!

[mburnicki]

I also have a GPS tracker GT-730FL (skytraq type) which basically still works after the WNRO, but records a date in 1999, so currently 1024 weeks had to be added to get the correct date.

Another tracker is a MediaTek Inc. Qstarz BT-Q1000XT (mtk type) which actually still works correctly. However, as explained here
https://kb.meinbergglobal.com/kb/time_sync/gnss_systems/gps_week_number_rollover#a_simple_error_prone_approach

even devices that currently still work correctly can start providing a wrong date after an arbitrary week number hardcoded in the device firmware.

So I also vote for a general option in gpsbabel to fix this when downloading data from the device, or even read / update / write a .gpx file.

Eventually a good way to do this is to specify the GPS epoch number on the command line, which is currently 2, and make sure the converted dates belong to this epoch, or even ask/warn the user if the date read from a device belongs to a different epoch than the computer's current date.

[jonaszwojcik]

Yes. I think the better way will be to correct the output instead source. It will be one code fix for all outputs.

For now the workaround is to phrase the dates in gpx file and override adding 1024 weeks.

<time/>1999-09-24T17:06:00Z</time> ====>> <time>2019-05-10T17:06:00Z</time>'

I thinking about configurable option for the translation process to add 1024 weeks if gps date is before 4/6/2019 and actual time is after 4/6/2019

[tsteven4]

If we are talking only about track data will the track filter move option work for you?  For example:

./gpsbabel -t -i m241-bin -f reference/track/mtk_logger_m241.bin -x track,move=7168d -o gpx -F mtk_logger_m241.gpx

where 7168 days = 1024 weeks * 7 days/week Otherwise, please see https://www.gpsbabel.org/lists.html, particularly the NOTE:

*NOTE*: When asking a question, please include enough information to let us help you. Be sure to include version numbers, the name of the operating system, and details of any programs or hardware involved. If you're having a problem, describe it in enough detail that someone else can reproduce it. Include any needed data files. If they're more than a few kilobytes, please try simplifying the data first. (We really don't need 50,000 trackpoints to reproduce a crash or see if we support a file when 10 will do...) Of course, if you're reporting something that is large and does require a huge data set to reproduce it, please put it on a personal web site or use something like http://drop.io to share the file.

To reproduce the issue we need the input data and the command line you are using.  Many of the formats that read directly from loggers have the ability to write a binary file that we can later read without the device.  This methodology allows us to test the code without the device.  It is best if we build a test case and add it to our regression, for this a set of test data that isn't unnecessarily large is preferred.  Also adding it to our regression will make the data you provide publicly available through https://github.com/gpsbabel/gpsbabel.

…

On 5/12/2019 7:07 AM, jonaszwojcik wrote: Yes. I think the better way will be to correct the output instead source. It will be one code fix for all outputs. For now the workaround is to parse the dates in gpx file and override adding 1024 weeks. <time/>*1999-09-24*T17:06:00Z</time> *====>>* <time>*2019-05-11*T17:06:00Z</time>' I thinking about configurable option for the translation process to add 1024 weeks if gps date is before 4/6/2019 and actual time is after 4/6/2019 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#349 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHXMMLJ6CA4Q62AOEB22ZTPVAJCXANCNFSM4HMJGPJA>.

[jonaszwojcik]

Yes. it will work for me.
Sorry, I missed this option: https://www.gpsbabel.org/htmldoc-development/filter_track.html

but days value is limited to 2000 days:

Please update the days limit as a quick fix and consider to add weeks option to the filter for the future release.
Weeks option will be more convenient for fixing GPS weeks rollover issue.

Thanks!

[robertlipe]

I think the track move should be the official recommendation here. We really don't need another filter for this. The Holux and MTK devices provide time to us as UTC. If it's providing it incorrectly, the pressure to fix that really should go back to the device maker. ...who already has your money and no real incentive to do so. :-( Two of the four reports in my reading this morning have to do with firmware bugs in devices abandoned by their maker. I'm not sure I want to institutionalize us fixing device firmware bugs forever. This also makes me wonder if you're our only M-241 user at this point. Surely someone else would have noticed this, right?

…

On Sun, May 12, 2019 at 1:09 PM jonaszwojcik ***@***.***> wrote: Yes. it will work for me. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#349 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCSD35KSW62IVQWHHBG3H3PVBMMHANCNFSM4HMJGPJA> .

[tsteven4]

A potential issue with using track move is it only applies to tracks, not routes or waypoints. It would be trivial to add a time filter that moves everything like the track move option moves tracks.

…

On 5/13/2019 2:18 PM, Robert Lipe wrote: I think the track move should be the official recommendation here. We really don't need another filter for this. The Holux and MTK devices provide time to us as UTC. If it's providing it incorrectly, the pressure to fix that really should go back to the device maker. ...who already has your money and no real incentive to do so. :-( Two of the four reports in my reading this morning have to do with firmware bugs in devices abandoned by their maker. I'm not sure I want to institutionalize us fixing device firmware bugs forever. This also makes me wonder if you're our only M-241 user at this point. Surely someone else would have noticed this, right? On Sun, May 12, 2019 at 1:09 PM jonaszwojcik ***@***.***> wrote: > Yes. it will work for me. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#349 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACCSD35KSW62IVQWHHBG3H3PVBMMHANCNFSM4HMJGPJA> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#349>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHXMMMB73NQJ5K4PT6TPI3PVHEJBANCNFSM4HMJGPJA>.

[rwaldner]

No, @jonaszwojcik is not the only M-241 user - there is at least a second one :-)
And yes, I also noticed that the dates are now in the year 1999 :(

I agree that this cannot be your task to fix firmware bugs of devices built by others.

I use GPSBabel on the commandline and the move by 7168 days is a practical solution for me.

Roger

[robertlipe]

I hope everyone is writing and calling Holux and other makers that actually are selling the products that aren't working sensibly. This is just silly behaviour from their devices. I just find it uncomfortable a tiny free software project is expected to fix the defective projects of multiple multi-million $ (?) companies. But if nobody beats me to it, I probably will write that aforementioned filter, but it's going to be late summer at best.

…

On Sun, Jun 16, 2019 at 3:54 PM VlasProgulkin ***@***.***> wrote: And me too! I am user of Holux M-241. And I use GPSBabel on the commandline too and the move by 7168 days is a practical solution for me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#349>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCSD36BAKHBDQ4JWS5V6ETP22R7DANCNFSM4HMJGPJA> .

[Cypresslin]

M241 and other models are in the "not supported" list of their announcement.
But anyway, this company, Holux Technology Inc, has no longer exists since 2019 Jul. 16

Formosa TV English News - GPS provider Holux Technology to lay off entire workforce
https://www.youtube.com/watch?v=uv3tJ2bsT8w

[jetsun-666]

I have both Holux M241 and Transystem i-Blue 747.
I don't know the gps weeks rollover issue until today.
After April 2019, I thought my two GPS loggers were suddendly brorken, there is no GPS track can be extracted by using BT747 java utility, and the date is wrong when I use GpsBabel.
It seems the vendor will not provide a new firmware for no longer supported legacy GPS logger.
It will be very appreciated if Gpsbable can provide a workaround to fix the bug of legacy GPS logger.

[tsteven4]

Use the track filter as suggested above. If you are using the command line 1.6.0 should work using a shift by 7168d(ays). But if you are using the GUI you need a fix from after 1.6.0,
#363. There is a pre-release version that includes this fix at https://github.com/gpsbabel/gpsbabel/releases, either continuous for macos or continuous-windows for windows. The fix also adds the ability to shift by 1024w(eeks) with the command line.

[hongmao21]

It’s a pity that it’s bankrupt. I tried to log in to the official website and I have been unable to access it. This is the problem.

[billyauhk]

I am also affected by the rollover, but yesterday I found one could inject a PMTK335 message through the serial port to set the RTC time in the chip while it is early in the cold boot process, and then it works normally (even if I injected the year-month-day with a fixed 00:00:00Z while I was close to 16:00:00Z). Otherwise the device may tell me I am in 1980 or 2000 (two or one 1024 weeks before) due to the rollover.

I was on a wired USB connection, but I assume it is also do-able via bluetooth. Holux will not provide firmware updates (chance even slimmer since the bankruptcy), but an mobile app which would check, cold boot and fix the date through bluetooth if it is wrong would be a good triage solution (at a ~15 minutes cost due to the cold start). I have not done experiments for anything other then cold start (warm start, etc.) but will do that when I have time. A simple "fix the date, then insert a battery" trick to maintain the RTC could revive the logger.

Edit:

1. A PMTK335 followed by a PMTK101 (hot start) seems also work.
2. This PMTK335 trick will work until 20 Nov, 2038. Setting a date of 21 Nov, 2038 (the date of the next rollover) and beyond will fail to set anything. Correct date will still be displayed if the clock continues to run without any hot start. The earliest possible date shown on the LCD clock is 01 Jan, 2007 00:00:00UTC (05 Jan, 1980 if reading the NMEA).
3. The trick is already reported in May on a German blog: https://www.technologyblog.de/2019/05/gps-rollover-zerstoert-gps-logger/

P.S.

1. I suspect this trick would also work for all other devices with MT3318 chips, but I only own an M-241, so it may be better to spread the gospel and let everyone check their devices.
2. If someone want to try the hard way of reversing and working out a new firmware for everybody, I would be interested to know about the efforts and will be glad to share my backup of the firmware files for M-241 on the official website.

[robertlipe]

Interesting. ...and before the first person asks: "No" 😆

…

On Tue, Nov 5, 2019, 8:11 PM Bill Yau ***@***.***> wrote: I am also affected by the rollover, but yesterday I found one could inject a PMTK335 message through the serial port to set the RTC time in the chip while it is *early* in the cold boot process, and then it works normally (even if I injected the year-month-day with a fixed 00:00:00Z while I was close to 16:00:00Z). Otherwise the device may tell me I am in 1980 or 2000 (two or one 1024 weeks before) due to the rollover. I was on a wired USB connection, but I assume it is also do-able via bluetooth. Holux will not provide firmware updates (chance even slimmer since the bankruptcy), but an mobile app which would check, cold boot and fix the date through bluetooth if it is wrong would be a good triage solution (at a ~15 minutes cost due to the cold start). I have not done experiments for anything other then cold start (warm start, etc.) but will do that when I have time. A simple "fix the date, then insert a battery" trick to maintain the RTC could revive the logger. P.S. 1. I suspect this trick would also work for all other devices MT3318 chips, but I only own an M-241, so it may be better to spread the gospel and let everyone check their devices. 2. If someone want to try the hard way of reversing and working out a new firmware for everybody, I would be interested to know about the efforts and will be glad to share my backup of the firmware files for M-241 on the official website. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#349>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD37FG3RE7IXBKPBZGCTQSIRVFANCNFSM4HMJGPJA> .

[rowaard]

i hav a a holux GPSport 260 pro. can anyone tell if it is possible to fix the gps week rollover.

[GPSBabelDeveloper]

Pulling in issues ##363, #357, and #358, I think we have this about as fixed as is reasonable for us to do.

Solution TL:DR: Use the track move 1024w option

Thanx for all the good info in this post.