Etrex Vista HCx wrong date...

[Kim]

I was about to say "what harm can it do?" - but actually, apart from one small detail, you do have a perfectly functioning GPS already ...

That's a fair point.  It wouldn't be much harder to post-process the files to have sensible dates, like we have to do to make Strava recognise the elevation data.

But I would trust GPSBabel, it's a well-known and long-established utility that loads of people use.

Indeed.

[andyoxon]

Thought I'd have a look...  Hopefully you can see the image.



Just returned error message.  Not really sure why - no doubt I didn't set something correctly.

[drossall]

Looks as though it couldn't talk to the Garmin? Was the GPS definitely communicating? No other GPS software grabbing the link and conflicting?

[Feanor]

Perhaps it needs the garmin USB drivers installed.
Are they?

[andyoxon]

I guess they're installed, as mapsource/basecamp works happily in communication with the unit, and I have used the garmin web/updaters via USB successfully.

[Kim]

Is there anything else sensible looking in the "Device name" field?  I'd guess probably just a list of COM ports, under windows.

Alternatively, it may not like reading from the Garmin and outputting back to the same Garmin, as you've instructed it to do.  Maybe try uploading a random GPX file or something?

[Feanor]

Not sure about a device of that vintage, but are there options related to Garmin mode / Mass storage mode on the device when you connect it to USB?

It probably needs to go into Garmin mode to support these commands.

Also, check in your control panel to see if the Garmin USB drivers are listed.
On devices which present as generic Mass Storage, they don't seem to be required, and mapsource finds them anyway.

Either way, it's now a google-fest on what GPSbabel needs to find for it's USB: device.

[fuaran]

The GPS Babel documentation seems a bit vague as to how to use the ressettime option.
Maybe try using the resettime option as the input, set the output to a GPX file (or any other format).

[iddu]

>>gpsbabel.exe -i garmin -f usb:-1
>0 3311840168 421 eTrex LegendCx Software Version 3.40

Right - so they talk...telling me correct version, found on USB0:

>>gpsbabel.exe -i garmin,resettime -f usb:0
>[ERROR] Send_Time: Unknown date/time protocol

Hmm, not a happy bunny...what's whinging...

(grabs source, grep "Send_Time:"...)

gpscom.cc -->

/* @func GPS_Command_Send_Time ******************************************
**
** Set GPS time
**
** @param [r] port [const char *] serial port
** @param [r] Time [time_t] unix-style time
**
** @return [int32] true if OK
************************************************************************/

int32 GPS_Command_Send_Time(const char* port, time_t Time)
{
  time_t ret=0;

  switch (gps_date_time_transfer) {
  case pA600:
    ret = GPS_A600_Send(port, Time);
    break;
  default:
    GPS_Error("Send_Time: Unknown date/time protocol");
    return PROTOCOL_ERROR;
  }

  return ret;
}

(grep "gps_date_time_transfer")

gpsapp.cc -->

::
static int32 GPS_A000(...
::
#if 0
  gps_date_time_transfer      = pA600;
  gps_date_time_type          = pD600;  /* All models so far */
  gps_position_transfer       = pA700;
  gps_position_type           = pD700;  /* All models so far */
#else
  gps_date_time_transfer      = -1;
  gps_date_time_type          = -1;
  gps_position_transfer       = -1;
  gps_position_type           = -1;
#endif
::

(dang, so compiled OUT, with consequent given error, by default...)

::
static void GPS_A001(GPS_PPacket& packet)
::
    case 'A':
      GPS_User("\nCapability %c%d:", tag, data);
      lasta = data;
      switch (data) {
      case 10:
::
      case 500:
        gps_almanac_transfer = pA500;
        break;
      case 600:
        gps_date_time_transfer = pA600;
        break;
      case 650:
        /*  FlightBook Transfer Protocol */
        break;
::

(So, [re]enabled if unit tells us it has capability 600...)

Hmm - via UI access, including Debug 1 level to get informational messages

gpsbabel -D1 -w -r -t -i garmin -f usb: -o gpx -F d:\temp\1.xml
Unit:   eTrex LegendCx Software Version 3.40
ID:   421
Version:   3.40
Capability A10:
Capability A100: D110
Capability A201: D202 D110 D210
Capability A301: D312 D302
Capability A400: D110
Capability A500: D501
Capability A600: D600
Capability A601: D601
Capability A700: D700
Capability A800: D800
Capability A801: D801
Capability A900:
Capability A902:
Capability A903:
Capability A904:
Capability A905: D900
Capability A907: D907 D908 D909 D910
Capability A908: D911
Capability A914:
Capability A916:
Capability A917: D917
Capability A918: D918
Link_type 1  Device_command 0
Waypoint: Transfer 100 Type 110
Route:    Transfer 201 Header 202 Type 110
Track:    Transfer 301 Type 302
cet_util: Converting from "US-ASCII" to "UTF-8", done.
options: module/option=value: gpx/snlen="32" (=default)
options: module/option=value: gpx/split="500000" (=default)
GPSBabel Version: 1.5.3
Waypoint type: 110
Chosen waypoint length 14

Translation successful

That appears to be saying (my CX & HCX) device has capability - but I can't see(*) why the short conversion on "Dxxx" is failing to process relevant 'case 600:' action(s), to flag ability to do time updates.  Any other code jockeys want to have a chase, or is it just quicker to have someone recompile with fixed enablement of required capability, by hacking the #if about...

(*) I ain't done C stuff for 3 decades...

[andyoxon]

eek!

Garmin, they say, "we have exhausted our available troubleshooting steps for this issue. Unfortunately, we no longer repair or replace this device due to its age."

At least if I need to use this HCx the GPS time is correct, and the YYYY-MM can be easily edited.

[frankly frankie]

Perhaps it needs the garmin USB drivers installed.

So is this Groundhog Day all over again?
From GPSBabel's Help pages
 "For models connected via USB, we recommend use of the usb: filename. For this to work on Windows, you must install the Garmin driver"
But Andy says Mapsource works so he must already have this.

Just for my own interest, I've just had a go at connecting a Vista HCx (in 'Garmin mode') to a freshly-downloaded GPSBabel (because it's years since I last used it).  Interestingly, I get a screen looking much like Andy's screenshot of the GUI, but the device name: dropdown is greyed out with usb: showing - as though either there's no connection or there are no options.  However I tried a simple operation (dump Waypoints from GPS to a GPX file) and it worked fine
 gpsbabel -w -i garmin -f usb: -o gpx -F D:/temp/output.gpx -o gpx -F C:/Users/***/AppData/*******/GPSBabel.hyl212
 Translation successful

I agree with Fuaran's suggestion above.  Set an output file and actually give GPSB something to do, such as copy Track to file.  Do the timesetting thing as an option on the input side.

GPSB doesn't support the newer Etrexes by the way, as these "don't support Garmin communication protocol".  Funny, I thought they did.  But it's true they don't play well with Mapsource.  GPSB mainly useful for File --> File conversions of course.

[Kim]

Perhaps it needs the garmin USB drivers installed.

So is this Groundhog Day all over again?
From GPSBabel's Help pages
 "For models connected via USB, we recommend use of the usb: filename. For this to work on Windows, you must install the Garmin driver"
But Andy says Mapsource works so he must already have this.

I'm not sure that follows.  If the unit is in USB storage mode the Garmin driver probably isn't required.  Mapsource can work with either the Garmin protocol or the USB Storage mode.

[iddu]

It's not going to die a death if you (re) install the USB drivers.

I think GPSB will report same as above (for same probes), indicating capability but rejecting option; don't have time ATM to play with  source as to the why, but could check after hollibobs, unless anybody else spots it quicker...

[solomon]

Apologies for the necro-thread, but this actually seems like the most comprehensive discussion of this topic online.

Following @andyoxon's excellent work, I discovered why current GPSbabel's don't actually send the time - the code which checks the parameter capabilities and initializes the variables isn't executed until AFTER the routine which sends time.  I've opened an issue for this in GitHub https://github.com/gpsbabel/gpsbabel/issues/350 but I don't yet have the capability to rebuild GPSbabel to test.

Also I suggest affected folks contact Garmin support again as the Chat agent for USA claimed today that Garmin is now aware of the bug and working on a fix.  He needed my serial # but then supposedly added my contact info to an already open issue tracker for a firmware patch he claims will be forthcoming… I'm going to keep pursuing GPSbabel in case that DOES fix the issue once it can send the time to the unit, but ultimately an updated firmware fix from Garmin would be ideal.

HTH anyone else and again apologies for reviving an old (but honestly very pertinent) thread!

[andyoxon]

Interesting, thanks. 

Sometime last month I noticed that my Etrex gps logs went from 2038 to 1999; so now 28-09-1999 represents 14-05-2019.  This appears to be '19.7' years behind current date now, and probably relating to the gps 'rollover week' in April.

The GPS system transmits the date and time as a 10-bit number that indicates the week and the number of seconds into that week. Your GPS receiver turns that into the day–month–year format you’re familiar with.  It’s a highly accurate system, but when the 10-bit number reaches its maximum—after 1,024 weeks, or 19.7 years—it ticks back over to the start.  The GPS system went live in 1980, meaning it rolled over for the first time in 1999, ending what was known as the first epoch of GPS time. 

https://www.galsys.co.uk/news/gps-rollover-week-2019-everything-you-need-to-know/

[frankly frankie]

Out of interest I just fired up an old Vista HCx that hasn't been used for well over a year - when it had settled it showed the correct location and the correct time and date - no hint of any rollover bug.

[solomon]

Also I suggest affected folks contact Garmin support again as the Chat agent for USA claimed today that Garmin is now aware of the bug and working on a fix.  He needed my serial # but then supposedly added my contact info to an already open issue tracker for a firmware patch he claims will be forthcoming… I'm going to keep pursuing GPSbabel in case that DOES fix the issue once it can send the time to the unit, but ultimately an updated firmware fix from Garmin would be ideal.

Never got anything from Garmin, but as of today (16-July-2019) Garmin WebUpdater offers an update for the GPS chipset (not the main unit firmware) which fixed my date issues!

[andyoxon]

Also I suggest affected folks contact Garmin support again as the Chat agent for USA claimed today that Garmin is now aware of the bug and working on a fix.  He needed my serial # but then supposedly added my contact info to an already open issue tracker for a firmware patch he claims will be forthcoming… I'm going to keep pursuing GPSbabel in case that DOES fix the issue once it can send the time to the unit, but ultimately an updated firmware fix from Garmin would be ideal.

Never got anything from Garmin, but as of today (16-July-2019) Garmin WebUpdater offers an update for the GPS chipset (not the main unit firmware) which fixed my date issues!

Yay, cheers for that solomon.  Date is fixed.  Nice one.   

My current HCx is probably not that waterproof owing to the 'rubber band' coming adrift at various points, so I bought another off ebay (looks like it's only been used for walking) and the 'rubber band' is intact, but it came stuck on 1999 too...      However because of this Chipset update, I've also fixed the date on this new ebay unit (and updated to v3.20 FW). 

[rogerzilla]

ICBA to read the whole thread but this is a known issue, fixed in the latest firmware.  My recently-acquired Legend HCx showed a day out but was fixed by the firmware update.

These devices are sort-of-unsupported now as Garmin don't sell maps for them (so you're on OSM or an old map) but Basecamp will still check for firmware updates and apply them.

[frankly frankie]

Not much wrong with an old map.  When we all carted OS or Barts maps around some of them were decades old.  My usual Garmin map is their final Metroguide release (2009 I think) so the data is probably rooted in about 2007.

Fairly recent new construction in north Cheshire has destroyed everybody's maps - cycle around the lanes in that area for any length of time and meet all the puzzled motorists who have been led up the garden by their satnavs.

[andyoxon]

ICBA to read the whole thread but this is a known issue, fixed in the latest firmware.  My recently-acquired Legend HCx showed a day out but was fixed by the firmware update.

These devices are sort-of-unsupported now as Garmin don't sell maps for them (so you're on OSM or an old map) but Basecamp will still check for firmware updates and apply them.

For me, reinstalling the latest Vista HCx firmware (v3.20) did not fix the date issue - had to be the recent chipset fix.  I've been using the OSM maps http://garmin.openstreetmap.nl/  for quite few years, do the job pretty well - no contours, but don't find I need these on the etrex. 

edit.  I also now have the option to go back to mapsource (to retrieve gps log from device), as it used to reject gpx files with the incorrect date, and I had to use basecamp.

[Androcles]

I've been getting these issues on my old Legend Cx.  Tried all of the hard resets to little avail and there don't seem to be any upgrades available through the Updater (either via Basecamp or the WebUpdater tool.  The date seems to be randomly set to either 2019 (good), 2038, 2058 or 2078.  The time seems to be OK, and navigation is spot-on so the unit is still usable.

One question I do have is about recording and validation.  I have to manually find and replace the date tags in the .gpx file in order to upload to Strava, but does anyone know whether such a modified .gpx file will be acceptable for validating a DIY by GPS?

[Kim]

One question I do have is about recording and validation.  I have to manually find and replace the date tags in the .gpx file in order to upload to Strava, but does anyone know whether such a modified .gpx file will be acceptable for validating a DIY by GPS?

I don't see how they'd know you've modified it.  It's not like the unit cryptographically signs them or anything.  There isn't even a checksum.

[frankly frankie]

Well - the datestamp of the file is a giveaway that it's been post-produced - but I get the impression that most people do that anyway for one reason or another.

[Kim]

Well - the datestamp of the file is a giveaway that it's been post-produced - but I get the impression that most people do that anyway for one reason or another.

Does that even survive the upload process?

But even if it does, it probably shows the date the file was downloaded from the GPS unit.  And it's trivial to manipulate with the touch command (I expect something similar exists under Windows).