List of gps incompatible with 2019-04-06 roll over bug

Discussion in 'Mapping & Navigation' started by dddd, Apr 13, 2019.

  1. readonly24

    readonly24 Been here awhile

    Joined:
    Jun 5, 2015
    Oddometer:
    512
    Location:
    In the dirt
    #41
  2. ohgood

    ohgood Just givver tha berries !!!

    Joined:
    Sep 21, 2010
    Oddometer:
    10,250
    Location:
    alabama
    pssssst, hey, they screwed up their support forum, too !

    Screenshot_20190511-034344.png

    i guess being a few months (or years) behind on software fixes is acceptable practice nowadays.
    #42
  3. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    It depends on priorities. Delivering a core patch that affects so many clients isn't something to handle casually. Meanwhile I can't mind if they give priority to bugs fixes on aviation, military, marine and newer models; it's only fair, for bugs.

    I just hope they don't give priority to new "features" until the models they intend to fix are all fixed. Product managers are often self-centered, stubborn and want to hit the market with new stuff to get their bonus rather than interrupting current schedule to fix a bug probably as old as (or older than) the 2006 zumo 550. The cost of not fixing a bug is sometimes less than the benefit of releasing new features. It's sad but that's reality. Dunno if Garmin has such an old "finite game" enterprise culture but it's the 2nd most likely cause for delays.

    If they cannot give ETA, that's because it's not scheduled, perhaps not yet evaluated nor prioritized. You have to hope that it's a quick fix so that it may slip ahead of the queue for padding a release cycle. That's how most software companies (if agile at all) work. I am confident this is a quick fix for devs and QA. So it's a matter of handling on the mgmt side.
    #43
    ohgood likes this.
  4. ohgood

    ohgood Just givver tha berries !!!

    Joined:
    Sep 21, 2010
    Oddometer:
    10,250
    Location:
    alabama
    they knew (or should have) known about the rollover date issue when they wrote the firmware back in 06. my guess is they didn't intend to support it for that long, or to ever fix it.
    #44
    Menhir and webmonstro like this.
  5. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    I made a fix for the TomTom Rider 2013. Will post a link once I find someone to host it.
    #45
    ohgood likes this.
  6. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    I don't think any fool will install a firmware made from just any dude. You might want to explain what you did and why you should be trusted with upgrading expensive devices. You might want to contact tomtom and have them qa your fix and vouch for it, assuming they don't have one.
    #46
  7. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    Hahaaha sure...qa by TomTom for something they didn't make themselves...not that there aren't quite a few modifications out there for TomTom devices that people install without any hesitation. Of course that doesn't make my file any more or less trustworthy. But it's quite easy...I am not forcing anyone. Whoever wants to stick with a partly broken device - I couldn't care less. Then I'll leave it for the "brave" people...

    I sure won't be going to TomTom. It would've been much easier for them anyways, they don't need all the effort I put in because they have all the sources.

    But for the sake of it, this is what I did:
    TomTom's NavKit (the user interface) expects the location and time data to be presented as NMEA0183 messages. It does this on all devices, no matter the GPS chip. The AR1520 in the Rider 2013 puts the old date (now Oct 1999) into these messages. My patch changes the output location of the GPS driver, reads the NMEA messages from there, corrects the date, and writes proper NMEA back into the original file (not really a file, but a named pipe). Also some startup scripts to initiate my process.

    Surely too much for TomTom for an unofficially abandoned product. So it's quite easy. That TT doesn't have a fix just means they don't care. Why would they qa something then. And I'm not a coder. I'm just a geology PhD student who enjoys riding and sometimes a bit IT.

    Anyone who is still interested can either contact me or look for it somewhere else.
    #47
    ohgood likes this.
  8. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    I meant to deliver the fix for free to TOMTOM so they review and release it.
    It's probably your only way out of a lawsuit for reverse engineering illegally their device and intellectual property.

    You are about to learn one more important thing about software that is seemingly not in your geology curriculum.
    #48
  9. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    They sure won't do that, because they especially will not want to vouch for something they didn't develop. If they want to publish a fix they can develop it now on their own or pay me for it.

    There's no illegal reverse engineering. The older TomTom devices use Linux and source code is freely available under GPL. The only thing proprietary is the GPS driver and the navigation application. I didn't touch any of them (except for changing the .ini-script for the driver to change the output fifo). The layer in between - the operating system - is GPL. And that's where my fix sits as well. It's not more than an application that runs in the background.
    #49
    flexiflyer and ohgood like this.
  10. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    That is very interesting. Can you provide links to this open platform spec/doc?
    Otherwise (if not open) I would remain cautious because even if a system (like a TV, or dvr, etc) uses opensource tech, the integral system remains copyrighted. I know because I worked on appliance systems integrating things like gpl and linux.
    #50
  11. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    Sure, here's the official GPL page of TomTom for NavCore 9 (which the Rider 2013 uses):
    https://www.tomtom.com/en_us/opensource/go-version-9/
    I even used the GCC-toolchain from there to compile my little tool.

    There used to be an opensource project at OpenTom.org, but the site is defunct. You can still find it via archive.org. Another opensource project is "Navit", which developed an own navigation software working with OSM maps: https://wiki.navit-project.org/index.php/TomTom

    The original disclosure and background on the lawsuit to force TomTom to release all GPL-related source (and even made TomTom to embrace OSS for some time) is documented (although in German) here:
    Video recording of the talk "Hacking into TomTom" at Chaos Communication Congress in 2005:
    https://media.ccc.de/v/22C3-603-de-hacking_tomtom_go
    Slides used in the talk:
    https://events.ccc.de/congress/2005/fahrplan/attachments/696-slides_hacking_into_tomtom_go.pdf
    #51
    ohgood and dddd like this.
  12. ohgood

    ohgood Just givver tha berries !!!

    Joined:
    Sep 21, 2010
    Oddometer:
    10,250
    Location:
    alabama
    i remember when Tom Tom stuff was getting hacked on weekly to make things better... mp3 players, better refresh rates, etc were a great addition to the units. i love that they were open source, stuff was fixed so much faster by the community than Tom Tom. great stuff! thanks for tidying up their mess !
    #52
    treysis likes this.
  13. Menhir

    Menhir Been here awhile

    Joined:
    Mar 11, 2017
    Oddometer:
    232
    Has anyone heard anything from anybody that knows if and when Garmin plans on issuing a fix for the Zumo660 and other related affected devices?

    It's June already...and it's not like they didn't see this coming.
    #53
  14. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    Well, they have firmware working well as long as the battery is there, it seems, but it is very possible they didn't see this particular onboard clock reset bug coming. QA is not perfect for sure. Keep asking them; put pressure; ask for ETA.
    #54
  15. ohgood

    ohgood Just givver tha berries !!!

    Joined:
    Sep 21, 2010
    Oddometer:
    10,250
    Location:
    alabama

    I highly doubt a team of gps firmware engineers didn't know how long they had before a date issue would crop up. Time stamps is is what the whole thing revolves around after all.

    I just think they aren't intending (it never did intend) to support the device this far out.
    #55
  16. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    Yeah, the situation is a plausible mix of both planned obsolescence and neglect. We will never know. I think it's more on the neglect side.

    Let me rephrase what I wrote. The firmware is partially supporting dates beyond april 6th 2019 (some zumo 660 users have it working just fine). So they did think of that. What they might not have predicted is that once the battery is removed, the onboard clock will reset while being in the wrong fallback era. I'm also saying that despite the advance knowledge of gps math and relativity, electronics and all, there are many devs (not all engineers) don't require much genius to write middleware code and they may have dropped the ball on that use-case to recover the date upon power outage. They may have been simply negligent facing the future, as you wrote, not expecting that a gps released in 2009 (and designed before that) would be around 10 years later.

    More likely, I can easily believe that back in 2009, their QA didn't even have the means (or forgot to try) to set the clock past april 6th 2019, to watch it get lost and get reset to 1999. If they could, some QA guy should LEAK THIS TRICK to us...

    Staff came and went. Design flaws got forgotten in a dormant firmware not touched since june 2014. Neglect is very plausible to me. Shit happens. Worst negligence has happened in many softwares. Garmin looks bad, regardless of the reason. I don't think they are evil nor planned that obsolescence. They just failed and they have a chance to correct it and to keep a customer base happy. We'll see. If it isn't solved next spring, it will never be (big bugs usually get priority or end up in "wontfix", they are not typically overlooked in bug review meetings for that long).

    I think they are also unsure how to tell us if they wouldn't fix it. Telling us right away means we get angry, bad press, buy other brand, etc. Telling us later means we wait and still don't go buying the newer device; no extra sales. I don't think they can wear us with time, because if we endure a year with the bug, we will endure it forever, so no extra sales. They can only try to avoid pissing of the customers so they should fix it.

    For me, fact is, the 660 is the only device that has FM traffic for free (well, lifetime single purchase). This is making the device unique and not replaceable, anyway. I don't care for XM traffic plans of zumo665 or cellphone link with data plans (especially roaming).
    #56
    treysis and ohgood like this.
  17. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    @dddd
    Exactly that. Also, I don't think Garmin develops the GPS chip itself, but buys it from suppliers like Qualcomm, Broadcom, or whoever produces GPS chips. Depending on how the implementation works, it's very well possible Garmin doesn't have any influence on the WNRO and depends on the supplier's firmware for the GPS chip.
    #57
  18. dddd

    dddd Long timer

    Joined:
    Jan 15, 2012
    Oddometer:
    1,495
    Location:
    Montreal, Canada
    Interesting hardware concerns.

    But ultimately, the date ends up in software, so they can workaround whatever value they get to hack it to the proper era (usually relying on the firmware files date as a hint). I think there can be an interception of every call the to API to get the date. But that is possibly very intrusive.

    Otherwise, I would have created a fix like this: given a filename convention (which garmin express could produce for reliability), the software would detect a file with a with a date in it, to allow setting date (given the UI doesn't). Upon use, this file is renamed to become the hint for the era. This way, a user can set date or set the era from a simple file. Of course it would be nicer to have the UI support it, but it's probably a lot more work to produce a UI than to silently read a couple files on start.

    I wish I could talk to a garmin dev... Unfortunately they are behind a wall of clueless support staff.
    #58
    treysis likes this.
  19. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    Yep, that's more or less what I am doing with my fix for some TomTom devices: I intercept the NMEA-sentence with the wrong date, correct it according to the current GPS era, and feed it back to the navigation software (they don't use the week number, all the translation is done by the proprietary firmware of the different GPS chips).

    The interesting part is that the authority responsible for the operation of the GPS system already said before the 1st WNRO in 1999 that there is no definitive solution based on the GPS data alone and that manufacturers will have to find a way to handle the ambiguity (and also that they have a solution themselves and their devices will be fine):
    http://www.leapsecond.com/notes/gpswnro.htm
    Especially this paragraph is of interest:
    The company "Meinberg" published a very nice and informative knowledge base article how some systems might handle the WNRO, how it can be dealt with in a proper way, and especially which approach they are using so that customers can have confidence that they use a meaningful way to prevent any issues from occurring:
    https://kb.meinbergglobal.com/kb/time_sync/gnss_systems/gps_week_number_rollover
    #59
  20. treysis

    treysis Adventurer

    Joined:
    May 2, 2019
    Oddometer:
    12
    Location:
    Germany
    Important news:

    Supposedly Garmin rolled out an update to fix the date for the Zumo 660 just a couple of hours ago!
    #60