Yet Another Cycling Forum
General Category => The Knowledge => GPS => Topic started by: andyoxon on 18 April, 2016, 08:20:51 am
-
Yesterday when I started my ride and was down the road a mile or so, I noticed that my etrex was still on GMT (Daylight saving on auto), so I had a look at the TIME screen and the date is showing as 2 Dec 1935 (presumably default). I can't see what wrong. For the distance I did before returning home to get another GPS unit, a gpx with correct route was logged (so satellite connection OK) - but the track dates in mapsource are 2035...
Any ideas?
-------------------------------------------------
Update: * Fix available* Jump to p4 July 23 2019 (https://yacf.co.uk/forum/index.php?topic=97093.msg2412882#msg2412882)
Garmin webupdater page: https://www8.garmin.com/products/webupdater/howtoinstall.jsp
update with the GPS chipset for date fix
-
You were riding your DeLorean?
I'm guessing that the apparent jump of a century between the eTrex and Mapsource was due to the way it reads date. Some programs ignore the first 2 numbers of the year and use the "nearest" year matching the last 2 digits
-
:) My back-up HCx (swapped electronic gubbins + stuck down rubber outer) is fine date and year wise; it's the newer 'in good nick' unit where the date and time are outta wack.
-
Firmware version on the eTrex?
GPS tells the unit GPS time[1]. It doesn't tell it how to convert that to UTC or any other timezone - it needs a database to look that up, which will be part of the unit's firmware. I could imagine mysterious undefined behaviour if the database didn't contain a fudge factor for the current GPS time.
GPS time's epoch was 1980-01-06-00:00 UTC, so throw in a bit of millennium bug, and I can see how you'd get 1935.
Try upgrading the unit's firmware.
[1] A straight count of weeks and seconds since the epoch - no leap seconds, so it gets further out of sync with UTC as time goes on.
-
Firmware version on the eTrex?
GPS tells the unit GPS time[1]. It doesn't tell it how to convert that to UTC or any other timezone - it needs a database to look that up, which will be part of the unit's firmware. I could imagine mysterious undefined behaviour if the database didn't contain a fudge factor for the current GPS time.
GPS time's epoch was 1980-01-06-00:00 UTC, so throw in a bit of millennium bug, and I can see how you'd get 1935.
Try upgrading the unit's firmware.
[1] A straight count of weeks and seconds since the epoch - no leap seconds, so it gets further out of sync with UTC as time goes on.
Thanks Kim, unit in question was fine until Sun - will check software version tonight. Looks like this page: https://www8.garmin.com/support/download_details.jsp?id=3709
-
That sounds downright weird. If the gpx tracklog you created whilst riding looks OK (on the map that is) then the GPS knows the right time. That it's not displaying it correctly (at least to within a day, allowing for the time zone setting to have slipped somehow), or writing it correctly to the tracklog, is just bizzare.
-
That sounds downright weird. If the gpx tracklog you created whilst riding looks OK (on the map that is) then the GPS knows the right time. That it's not displaying it correctly (at least to within a day, allowing for the time zone setting to have slipped somehow), or writing it correctly to the tracklog, is just bizzare.
As I say, the GPS knows GPS time, which is what it needs for navigation. Converting that to UTC for the log and a local timezone for display requires a look-up.
GPS time is primitive precisely because you want the receiver to be able to get a position fix without access to a current UTC offset look-up table. Otherwise we'd have ships going off course because they didn't know about the latest leap second, and so on.
-
Yebbut surely that difference is a matter of seconds, not years. And the look-up data is presumably part of the GPS environment as well, the stuff that gets updated very slowly in the background.
-
The garmin units have a 'Time Zone Map' which maps GPS time to local time.
it's called gmaptz.img, IIRC.
Updates for this appear from time to time.
Is it possible this file is corrupt, causing crazy mappings to local time?
-
Yebbut surely that difference is a matter of seconds, not years. And the look-up data is presumably part of the GPS environment as well, the stuff that gets updated very slowly in the background.
Only the seconds difference from UTC, as far as I understand it. The Garmin will be doing a local look-up to get the UTC offset for the current location instead/as well. That'll be the bit that's broken.
-
Thought I'd try and replace the HCx software, so downloaded the v3.2, off here (https://www8.garmin.com/support/download_details.jsp?id=3709#Instruct) but get a dialog box...
Your current software version is newer than the update version.
Do you want to replace your current software version with an older software version? Y/N?
Any ideas? Why wouldn't the web page offer the newest software..?
-
What version does it claim to be running? (I think it's in the System menu somewhere - I've only got an eTrex 30 to hand, which has it under 'About')
-
What version does it claim to be running? (I think it's in the System menu somewhere - I've only got an eTrex 30 to hand, which has it under 'About')
Under "system setup" and find button, found this:
"Software Version 3.30 GPS SW Version 2.9"
-
Iiiiiinteresting...
http://forums.groundspeak.com/GC/index.php?showtopic=259533
-
It seems Garmin were shipping devices with 3.3 firmware, which was never made available online:
http://forums.groundspeak.com/GC/index.php?showtopic=259533
A bit more googling, and there seems to be a 3.4 in the wild too.
Someone's posted it here:
http://www.gpspower.net/garmin-receivers-firmwares/216226-etrex-legend-hcx-vista-hcx-software-version-summary.html
-
I think the HCx was bought (by prev owner) just before they were discontinued in 2010(?) I could just go ahead and roll it back to v3.2, probably wouldn't make too much diffs I guess, or, perhaps Garmin technical would email v3.3 to me.
I'm guessing that using a non-Garmin file link is a tad risky...
-
Have you tried a full reset? That often fixes problems with Garmins.
For the Vista, hold down the page button and the click stick while you switch it on. Then it will ask if you want to reset.
It might take a while to find the GPS position after a reset, so leave it outside for 10 minutes or so.
-
Have you tried a full reset? That often fixes problems with Garmins.
For the Vista, hold down the page button and the click stick while you switch it on. Then it will ask if you want to reset.
It might take a while to find the GPS position after a reset, so leave it outside for 10 minutes or so.
Can try this. Is anything deleted, apart from user settings?
-
It will delete any waypoints, routes and tracks stored on the Etrex. So backup them up first if you care about them.
It shouldn't affect anything stored on the SD card, ie maps or tracks recorded there.
-
Have you checked you have the latest Time Zone Map in Garmin Express? There was an update for my Garmins about a week ago. Can’t hurt to have that up to date. Who knows how it interacts with Garmin’s dodgy firmware!
-
It will delete any waypoints, routes and tracks stored on the Etrex. So backup them up first if you care about them.
It shouldn't affect anything stored on the SD card, ie maps or tracks recorded there.
Thanks, now tried this and date is still Dec 1935.
Re. GarminExpress - says HCx is not compatible.
Probably leaves reverting to v3.2...
-
So how do you update Time Zone Maps on this device? There must be a way, though this 1935 error is so weird I wouldn’t want to bet on an updated Time Zone Map fixing it.
Hmm.
I would be cautious about reverting to an earlier firmware than the one the device was shipped with. Garmin occasionally changes the hardware during production (famously away from SiRFstar III chips on an old model of the GPSMAP) and higher-numbered firmware unavailable for download may not be compatible with any device that was shipped with a lower-numbered firmware. Conversely, your device may conceivably not work with 3.2 if it shipped with 3.3. Did it have 3.3 from new?
-
You could try the Garmin Webupdater software, it should be compatible with the Etrex. http://www8.garmin.com/support/collection.jsp?product=999-99999-27
It will check for any firmware updates, or timezone updates etc.
-
You could try the Garmin Webupdater software, it should be compatible with the Etrex. http://www8.garmin.com/support/collection.jsp?product=999-99999-27
It will check for any firmware updates, or timezone updates etc.
Thanks
Interestingly:
New HCx: v3.30 GPS SW 2.90
backup HCx v3.20 GPS SW 2.10
webupdater, says they both have the latest software...
Still looking like a revert to v3.20
-
Did you catch my edit (new last paragraph) in my last post? Not that I’m an expert on Garmin firmware, mind you! Just scared you’ll brick your Garmin.
-
Worth contacting Garmin support to see what they say. There have been a couple of previous models that went weird after a few years, and displayed the wrong date etc. eg the Geko 201, a firmware update was released to fix that.
Anyone else using a Vista HCx, and does it still work? It seems some of these sorts bugs are only on specific hardware versions or chipsets etc, so it may not affect all of them.
-
Thanks Samuel / fuaran. Will drop garmin an email.
-
My HCx is fine (on 3.20). So is the OP's spare.
-
The garmin units have a 'Time Zone Map' which maps GPS time to local time.
it's called gmaptz.img, IIRC.
I could be wrong but I doubt if the Vista HCx uses this. Time zones offsets have to be set manually in that model. Bizarre but true - it can locate itself anywhere in the world to within a few metres, but it doesn't know what time zone it's in.
Andy could try altering the time zone to something outlandish - Bombay is good because the offset is not a whole number of hours, it's 5h30 - and see if the date comes right? Under Settings->Time.
Have just checked one of my stable of now-retired HCx's - seems fine, after a cold start. Firmware 3.40 software 2.90.
-
The garmin units have a 'Time Zone Map' which maps GPS time to local time.
it's called gmaptz.img, IIRC.
I could be wrong but I doubt if the Vista HCx uses this. Time zones offsets have to be set manually in that model. Bizarre but true - it can locate itself anywhere in the world to within a few metres, but it doesn't know what time zone it's in.
Andy could try altering the time zone to something outlandish - Bombay is good because the offset is not a whole number of hours, it's 5h30 - and see if the date comes right? Under Settings->Time.
Have just checked one of my stable of now-retired HCx's - seems fine, after a cold start. Firmware 3.40 software 2.90.
bombay no cigar. Date still 1935.
Apparently there is an executable available from Garmin called "timeset", and I also found out there is a super master reset (holding down the "Page, "Enter" and "Find" while powering up), which has worked for some... May be should wait for Garmin to respond.
-
Powering up while just holding the front click stick down brings you this diagnostic page (this is a Legend, the Vista shows more stuff than this)
(http://www.aukadia.net/gps/test.gif)
But, nothing to see there - maybe check for all 4 of those 'Pass' marks near the bottom.
-
Thanks ff. All = Pass.
Spoke to Garmin. v3.30 for the HCx seems almost to have the status of 'mysterious aberrant software' and "v3.20 is the most recent". Tech recommended doing a super master reset, 3 buttons + power up, then installing v3.20 if doesn't work.
super mst reset = 1935 still. So will have to do an install of v3.20 later I guess.
OK - update.
Did install of v3.20 and the date is still 1935, even after 30mins of unit outside! Very strange, what error would cause this incorrect date to persist?
After everything I've done from first noticing the date on Sun was 2 Dec 1935, it's now 4Dec 1935; so the time record still survives and advances.
meh...
-
I have found I can edit the gpx, by doing a replace all of 1935-12, with 2016-04. Not the best having the unit's date decades out, but could be a work around.
Here's a photo, I sent Garmin...
(https://lh3.googleusercontent.com/sh-03vtU9fsOHhFfUrn95aAvDElgs4RbY92WmuqMF2T2srcWELRSeCl5Ie8rcKJgk778Og9rpPWOFhwu6rEZkKTZ_k97yJkRX6UNAaGin3mvbAB-FDok_HaWsHVzsaWWE2ozH_TFIu4dB2sLfe8Z132wI1eATbUEL_r-XhbsRubPmTGs9I6fTW-zmr4nVa2em3lwOJNnGJwI53XbRo8LaYRyPaoc5jfFr2N0jPJ7jaaa-zxhHzbY3Lp1XQxKrpWbcU43au9KkO6Yr_4TYeMSUj0-qX_q_u4btnJcVsp9NlKMYATKbINADzSFhFl6ESG4qZLZKbOuHpKiLBERJNFW5AakuX8opx07byvmQ7ZCQqS7IcahWc3wJVCqQMDcy7Ev2jQxxNFgHA5YI_l5Muo6EnapqgCVplOgtILi9RKzyspqPnBSR4CHOqzk4zLWKO-06f-lebNoF-DCAI6tD7zdEtmlu4-eXWfNVCk-Mas0nDBhQeEYiwUGm4zLazh6xr2EbKZ3-VH4nHWbnoISYF4dBdFYDpRyE1M1rEcMC0ClQe5URhrlq7yAfWFEuxhYGEOZrY4K=w632-h780-no)
-
I have found I can edit the gpx, by doing a replace all of 1935-12, with 2016-04. Not the best having the unit's date decades out, but could be a work around.
Another method would be GPSBabel, with the 'move' filter. It can shift all of the timestamps by a specified offset.
-
Ah. I have an idea about what’s going on here.
Your device doesn’t think it’s December 1935; it thinks it’s December 2035! Which is … precisely 1024 weeks (2^10 weeks) in the future.
(That it interprets 35 as 1935 rather than 2035 when writing the GPX file just confirms that Garmin’s left hand doesn’t know what the right hand is doing.)
The problem must be that the GPS time signal is ambiguous to 1024 weeks and your Garmin thinks it’s in the wrong epoch. If there is a way to manually set the date on the device, that may fix it. However, it may be difficult to get it to stop fixating on the future while in range of a GPS signal. So if you can set the date manually, do so underground. Be careful; not being able to compute a position fix does not mean it isn’t receiving signals from at least one satellite.
If there is no way to manually set the date, I would try removing all batteries (including any clock battery if possible) and letting it sit for as long as you have patience and at least a day or two. Then power it up and let it bask in a field for an hour. You never know.
-
Ah, that makes sense!
Looking it up, the time signal only contains the 10 least significant bits of the week number, so you need an external source to tell it what epoch it's in. In the absence of anything better, the receiver can write the current date to non-volatile storage and assume it's in the same epoch on start up. Which works fine as long as you don't leave it switched off for 1024 weeks, or the non-volatile storage is corrupted.
Perhaps this is what the Garmin/.Position.gpx file on the eTrex 30 is used for?
Unfortunately, even if it is, I'm not sure how you'd access the equivalent on an HCx.
-
So, thinking this can't be unique, I did a bit of googling:
http://forums.groundspeak.com/GC/index.php?s=b97d3b6de27ec92f67362cbe4d6867b7&showtopic=177915&view=findpost&p=3169159
Coggins, thank you! The "super master reset" seems to have worked, at least for now.
Specifically, a normal "master rest" on the eTrex Vista is accomplished by holding down the "Page" button and "Enter" (i.e. the click stick) while powering up. You are prompted that a full reset will occur, and after confirming, the machine is reset. However, in my case, this achieved a full reset, but did not fix the date problem.
However, the undocumented "super master reset" on the eTrex Vista is achieved by simultaneously holding down the "Page, "Enter" and "Find" buttons while powering up. You have to hold all buttons in for about 5 to 7 seconds, and you DON'T get the warning message, but when the machine finally restarts, it is fully reset. After acquiring a satellite fix (took several minutes) - lo and behold - my time AND date both seem to be correct!
A later post suggests that a Garmin Protocol command to set the date on the unit exists, and hints at a mysterious tool for doing so.
Thinking about it, I'm not sure why the super master reset would solve the problem, unless it writes a default date that just happens to be in the current 1024-week epoch. Unless it can extract a full date from the almanac signal(?), and knows to do that on account of not knowing what date it is...
-
Now we’re getting somewhere!
-
I have found I can edit the gpx, by doing a replace all of 1935-12, with 2016-04. Not the best having the unit's date decades out, but could be a work around.
Sorry, I meant replace 2035-12 in the gpx with 2016-04... :-[ HCx Unit time = 1935, gpx time = 2035. Does that change anything?
I did the reset followed swiftly by 'super master reset' again. 1935 remains.
I can try draining the internal battery for a long period. To date only done o/n; though who knows it could take months to discharge...
Someone has looked at the circuit board battery for a HCx satellite issues:
This is a small ~6mm diameter coin cell located near the ribbon cable connector for the micro SD card. I'm not sure if this cell is rechargeable or not. I do know that I measured the cell's voltage at about 0.25V. I desoldered the cell, and briefly applied 3V to the terminals to charge it up past 2V. Once I soldered the cell back in, the unit immediately acquired satellites upon rebooting.
This is interesting, from t'interweb:
I had this problem when I first got my legend. The problem is (apparently) that when the almanac was downloaded from the satellites it got corrupted, and that causes a date offset. The almanac won't expire for something like 6 months, so until then, you will have the problem. What you need to do is a master reset on the unit, and that will force it to download the almanac again. However, you will lose all stored waypoints, tracks, routes, etc. (Strangely, you don't lose loaded maps).
Update - Garmin support option hit the buffers. Corrupted almanac/time can't be reset it seems, and they no longer take in units for repair (which I wouldn't do anyway).
So it's wait for the battery to discharge, or use & edit the gpx file.
edit.
Interestingly Garmin says 'there is no internal battery in the eTrex Vista HCx. ... It relies solely on the AA batteries inserted'.
That's it with this unit I guess (so edit 2035 in gpx to 2016).
In the course of reseting, I discovered that the test data screen can be made to change to multi coloured rectangular frames moving out towards the edge of the display. Funky.
-
+4 months
Thought I'd fire up the offending HCx to see if a few months without batteries achieved anything - unit now states 1936. ;) I left it in the garden all day basking under satellites, having done a uber-master-reset; still on 1936 later. If anyone else has further thoughts feel free to share... :)
In the meantime will probably get on and renew the DIY doublesided tape (under the 'rubber band') on my back-up HCx, and carry on using that.
-
Has it got a battery backed real time clock inside it, perhaps the battery is fubar? (long shot, but dont think I saw it in any of the above replies?)
-
Has it got a battery backed real time clock inside it, perhaps the battery is fubar? (long shot, but dont think I saw it in any of the above replies?)
I can't remember how the HCx woked, but on the eTrex 30 the RTC runs from the main battery. Remove the battery for more than a minute or so and the clock will be wrong on startup and it will take longer to get a first fix. It remembers what GPS epoch it's in, though, presumably by writing to flash memory (perhaps that position.gpx file).
-
That file contains a single timestamp and a single waypoint, marking the time and place it was powered down, eg
... (header stuff) ... <time>2016-02-13T10:00:56Z</time></metadata><wpt lat="54.383525" lon="-1.059999"/></gpx>
-
Surely it’s worth manually editing that file then? Since the device is useless as it stands anyway. Save a copy of the original file just in case.
If this fails, I think your last hope is to keep bugging Garmin until you get the attention of a bona fide engineer. I cannot believe Garmin doesn’t have a way to nudge these devices into the correct epoch. But the customer service reps may not know about it.
-
Thanks all.
Where would I find the position.gpx file to attempt an edit?
-
Where would I find the position.gpx file to attempt an edit?
On an eTrex 30.
-
There is a utility that Garmin support provided to some people in the past, called something like garmin_timeset.exe, but I've not had any luck tracking it down.
In the meantime, have you tried poking the GPS chipset software with this?
I know it's quite old...
https://www8.garmin.com/support/download_details.jsp?id=3731#Instruct
-
I get unreasonably excited every time someone, Feanor now, provides a glimmer of hope.
-
Where would I find the position.gpx file to attempt an edit?
On an eTrex 30.
ah yes.
-
There is a utility that Garmin support provided to some people in the past, called something like garmin_timeset.exe, but I've not had any luck tracking it down.
In the meantime, have you tried poking the GPS chipset software with this?
I know it's quite old...
https://www8.garmin.com/support/download_details.jsp?id=3731#Instruct
Thanks - may try this.
-
Garmin Express sees the HCx but states "does not support this device. Use Garmin Map updater". So downloaded and have GMU open (IE plugin) but can't see how to access the "eTrex HCx/HC Bravo2 GPS Chipset software version 2.30" update. Any ideas?
-
Hmm, that's stupid.
They have hidden their downloads behind the Garmin Express app, which does not support your device!
Googling, I get here:
https://buy.garmin.com/shop/store/downloadsUpdates.jsp?product=010-00630-00&cID=145&pID=8703
Which if you follow the links wants you to use the WebUpdater.
See if the WebUpdater tool can do anything for you.
-
Hmm, that's stupid.
They have hidden their downloads behind the Garmin Express app, which does not support your device!
Googling, I get here:
https://buy.garmin.com/shop/store/downloadsUpdates.jsp?product=010-00630-00&cID=145&pID=8703
Which if you follow the links wants you to use the WebUpdater.
See if the WebUpdater tool can do anything for you.
Thanks. Unfortunately I think it's a wild goose chase. Logged into garmin, installed webupdater, clicked download (on above link page), agreed to conditions, goes to a page v.similar to above link page, but with nothing to download. :-\
-
Ohh - have a dig around http://www.gawisp.com/perry/agree.html....
Mmmm http://www.gawisp.com/perry/etrex/vista/eTrexVistaHCx_230.exe & later...that updater lets you choose RS-232 or USB, which may be a good start...
Gawd bless packrats of the InterWebz ;)
-
Thanks iddu, I think that is firmware v2.30*, rather than the "Bravo2 GPS Chipset software version 2.30" to reset HCx clock.
* http://www8.garmin.com/support/download_details.jsp?id=3643
-
I was thinking more about whether you could shim the Chipset stuff in via the old updater...
-
OK have the link.
download.garmin.com/software/eTrexHCx_HCBravo2GPSChipset_230.rgn
If I drop the file on to the older updater.exe desktop icon, it sees my Etrex, and I can set USB mode.
https://www8.garmin.com/support/download_details.jsp?id=3731
This software update will reset your device clock to October 28, 2006, 23:59 UTC. You will need to acquire a satellite fix to correct the date and time before starting the timer. The first fix after updating the software may take longer than normal to obtain.
edit.
Nope doesn't fix.
-
Bah :(
-
Yes, Bah.
-
Used the unit on a short walk in the Chilterns today... What do you make of (top section of gpx below) the fact that the correct time/date is listed first up, followed by the 1936 + 100yrs i.e. 2036.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" creator="MapSource 6.16.3" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<metadata>
<link href="http://www.garmin.com">
<text>Garmin International</text>
</link>
<time>2016-08-29T15:45:42Z</time>
<bounds maxlat="51.587761407718062" maxlon="-0.961327347904444" minlat="51.575858183205128" minlon="-0.988298803567886"/>
</metadata>
<trk>
<name>ACTIVE LOG 030</name>
<extensions>
<gpxx:TrackExtension xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3">
<gpxx:DisplayColor>Magenta</gpxx:DisplayColor>
</gpxx:TrackExtension>
</extensions>
<trkseg>
<trkpt lat="51.575990365818143" lon="-0.988298803567886">
<ele>108.7662353515625</ele>
<time>2036-04-14T11:17:59Z</time>
</trkpt>
-
Interesting...
Oh, wait. That claims to have been made by Mapsource. The date in the header will be when it saved the file, but the ones in the trackpoints will be from the GPS.
What happens if you open a GPX log from the SD card directly?
-
Yes, you're right - mpsrce added metadata.
-
So, thinking this can't be unique, I did a bit of googling:
http://forums.groundspeak.com/GC/index.php?s=b97d3b6de27ec92f67362cbe4d6867b7&showtopic=177915&view=findpost&p=3169159
Coggins, thank you! The "super master reset" seems to have worked, at least for now.
Specifically, a normal "master rest" on the eTrex Vista is accomplished by holding down the "Page" button and "Enter" (i.e. the click stick) while powering up. You are prompted that a full reset will occur, and after confirming, the machine is reset. However, in my case, this achieved a full reset, but did not fix the date problem.
However, the undocumented "super master reset" on the eTrex Vista is achieved by simultaneously holding down the "Page, "Enter" and "Find" buttons while powering up. You have to hold all buttons in for about 5 to 7 seconds, and you DON'T get the warning message, but when the machine finally restarts, it is fully reset. After acquiring a satellite fix (took several minutes) - lo and behold - my time AND date both seem to be correct!
A later post suggests that a Garmin Protocol command to set the date on the unit exists, and hints at a mysterious tool for doing so.
Thinking about it, I'm not sure why the super master reset would solve the problem, unless it writes a default date that just happens to be in the current 1024-week epoch. Unless it can extract a full date from the almanac signal(?), and knows to do that on account of not knowing what date it is...
Right. Back to first principles.
Although you have done an (*thwack*) super master reset / (extended) wait, have you followed the embedded supplemental link from http://forums.groundspeak.com/GC/index.php?s=b97d3b6de27ec92f67362cbe4d6867b7&showtopic=177915&view=findpost&p=3169159 conversation to http://www.gpsinformation.org/dale/dgps.htm#waasalmanac ?
Not something like it's defaulting to base garmin, post-SMR, but attempting to find/apply non-collected WAAS almanac corrections??
-
Suppose a quicker test may be to set WAAS/EGNOS to disabled, and see what happens on 'pure' correction...
-
<time>2016-08-29T15:45:42Z</time>
<time>2036-04-14T11:17:59Z</time>
That looks like the 1024 week bug that some GPS receivers suffer from.
http://www.timeanddate.com/date/dateadded.html?d1=29&m1=8&y1=2016&type=add&ay=&am=&aw=1024&ad=&rec= (http://www.timeanddate.com/date/dateadded.html?d1=29&m1=8&y1=2016&type=add&ay=&am=&aw=1024&ad=&rec=)
It might be fixed by a total reset, but once the receiver thinks that the date is 1024 weeks forward, it regards current date as implausible, so it sticks.
I have no idea why the time is wrong by a few hours.
-
Right. Back to first principles.
Although you have done an (*thwack*) super master reset / (extended) wait, have you followed the embedded supplemental link from http://forums.groundspeak.com/GC/index.php?s=b97d3b6de27ec92f67362cbe4d6867b7&showtopic=177915&view=findpost&p=3169159 conversation to http://www.gpsinformation.org/dale/dgps.htm#waasalmanac ?
Not something like it's defaulting to base garmin, post-SMR, but attempting to find/apply non-collected WAAS almanac corrections??
I could pop up on to the Ridgeway and try and load the WAAS almanac...
-
<time>2016-08-29T15:45:42Z</time>
<time>2036-04-14T11:17:59Z</time>
That looks like the 1024 week bug that some GPS receivers suffer from.
http://www.timeanddate.com/date/dateadded.html?d1=29&m1=8&y1=2016&type=add&ay=&am=&aw=1024&ad=&rec= (http://www.timeanddate.com/date/dateadded.html?d1=29&m1=8&y1=2016&type=add&ay=&am=&aw=1024&ad=&rec=)
It might be fixed by a total reset, but once the receiver thinks that the date is 1024 weeks forward, it regards current date as implausible, so it sticks.
I have no idea why the time is wrong by a few hours.
Thanks for this. Samuel D mentioned this 1024 issue - interesting to see the calculation.
Diffs between dates is simply correct time /2016 when gpx uploaded to Mapsource vs GMT/2036 when the unit was turned on at start of walk.
Found this from NPL re. the 'rollover of doom'... http://www.npl.co.uk/reference/faqs/when-and-what-is-the-gps-week-rollover-problem-(faq-time)
When and what is the GPS week rollover problem? (FAQ - Time)
GPS, the Global Positioning System, has its own date and time scale for expressing satellite positions, based on counting weeks, and seconds within a week. To limit the size of the numbers used in the data and calculations the GPS Week Number is a ten-bit count in the range 0-1023, repeating every 1024 weeks. Week 0 started at 00:00:00 UTC on Sunday, 6th January 1980, so the week number 'rolled over' from 1023 to 0 at 23:59:47 UTC on Saturday, 21st August 1999. This was before midnight UTC because every GPS week contains exactly 604 800 s, to keep the calculations consistent. The 13 intervening leap seconds had put UTC behind GPS system time.
The problem is that some GPS-based equipment or software may be confused by the rollover event, which is similar to the year-2000 software problems. Anyone likely to be affected should seek advice from the manufacturer or supplier of the product concerned. The GPS week rollover next occurs on 2019 April 06.
-
Bah....
Google-fu led to http://www.portalgps.com.br/viewtopic.php?t=12706, which led to http://www.portalgps.com.br/download/file.php?id=1211&sid=e85fe64bfe690537cda4f05bcf3d973c, aka "garmin_timeset.zip"...
...but the .zip is corrupted for extraction purposes :facepalm:
Knowing that it did exist, you could poke Garmin TS to troll their archives for copy.
Why does one get the feeling they're in phone co mode (https://www.youtube.com/watch?v=CHgUN_95UAw), and come 2019 a shedload of serviceable devices will cease to work, in similar manner...
-
Yebbut the thing about the Millennium bug is that nothing happened ...
-
Yebbut the thing about the Millennium bug is that nothing happened ...
That's because fixing the Millenium Bug was shitwork, which only gets noticed when it isn't done properly. Critical systems were fixed or bodged in time for nothing to happen. Non-critical ones were fixed or failed in non-critical ways and were fixed later.
I don't think I personally saw anything more dramatic than time-telling devices failing to calculate the day of week correctly, or databases returning two-digit years and being interpreted by humans with common sense. But then I'm too young to have ever thought that two-digit years were a good idea, and what little date-related code I've worked on has mostly worked in Unix time.
-
I think I managed to get a lock (following hard HCx reset) on the EGNOS satellites (WAAS not visible apparently*), as the last two positions of 'satellite bars' were filled, one had a "D" in. given the amount of time that elapsed, I would have thought the almanac probably downloaded - though not sure.
No cigar on date fix, however.
*http://www.cnav.com/GeoSatelliteCalculator
-
Who Hoo - do we have a keeper?
GPSBabel: http://www.gpsbabel.org/download.html
"Garmin serial/USB protocol (garmin)
This format can...
• read and write waypoints
• read and write tracks
• read and write routes
This format has the following options: snlen, snwhite, deficon, get_posn, power_off, erase_t, resettime, category, bitscategory .
"
-->
"resettime option
Sync GPS time to computer time.
This option is experimental and was added to solve a very specific problem. Certain Garmin units (the
original black and white Vista is known to have this) will sometimes scramble their clock crazy far into the
future (like 2066). When this happens, the GPS itself may or may not work and later conversations with
GPSBabel may fail as the time overflows the documented range. The use of resettime brings the GPS's
internal clock back close enough to reality that the GPS itself can then 'fix' it when it has next a lock."
-
Thanks sounds hopeful; though the 3rd party nature is slightly more 'scary'. Will download and take a look.
-
GNU Public Licence - you can review & clean build if you're really paranoid, but I'd just take the relevant active binary...
-
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 ...
But I would trust GPSBabel, it's a well-known and long-established utility that loads of people use.
-
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.
-
Thought I'd have a look... Hopefully you can see the image.
(https://lh3.googleusercontent.com/INIpzMnq0OTlHy-GXz73TKiUjrN7q_mprwoc-6UCjZVQFhAK2tLu-RKtvImpyutXNlVtiURnHtBeUzlq61CD4xJnDwU2ThECefod5YV6MWUotLywl8-7-89WcaB-30J34lGimUrHuzyK39g1x-M-FfPUodkydpFkOgLs0Hkc07z8TzLaqkHcaXmSwyXky4PpTG5fey_vCxSP49N54q753DfkvZBcASmUdoTJ_uF2Hi4kZJkGWYQSnFN2XC2aUl1RmolT2OIwwKUdgcHVN5gbd2_7_B3BeqStyAISQnbCk98xyV8KAGleAba_TJW9wn6FqmhYt1RfH-wRlvB5nW-twd3TaxzfERva3YZqYQhXYEcvQhoe8l5sdcJ3V6CykA1d2SM5JUrQkQtnt6V_r59nmuUaIZxWyxATTv24gxQ6dIxDM4K0la0DRUFW4yWXvYU6nyRO2btpycOfAx0uRGXtg5TW3zC7feXELxcNKB50V6SCi8zkjaLJZ2GTTrHPVXnco5d-9rk1kplixrfClx1NUg8k-m9sdw-K44c6rQdSoPL1eCvtdz8-4loJXFp1b3Xm2qoFFeqrE6xWxf2AqbfWrxdWg1V0ALurMH7_P85Ncszo3ZYq=w688-h615-no)
Just returned error message. Not really sure why - no doubt I didn't set something correctly.
-
Looks as though it couldn't talk to the Garmin? Was the GPS definitely communicating? No other GPS software grabbing the link and conflicting?
-
Perhaps it needs the garmin USB drivers installed.
Are they?
-
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.
-
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?
-
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.
-
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).
-
>>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...
-
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.
-
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.
-
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.
-
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...
-
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 (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!
-
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/
-
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.
-
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!
-
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. :thumbsup: ;D
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... :o :o However because of this Chipset update, I've also fixed the date on this new ebay unit (and updated to v3.20 FW).
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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).
-
Well, well , well ... here is a geriatric beginning to pick up a little riding after a long time off .. who found that one of his Legend HCX had this problem ..I am sure that historically it was OK .. but maybe after a long layoff the garmin was scrambled.
This thread found the solution to the problem .. and I now have two correctly dated Legends .
Many thx to all those who went to work on this problem and finally solved it.
Roger
-
Thread resurrection.
Yesterday dusted down my two over-10-year-old Legend HCX's in preparation for next month's LEL only to find they were both showing the wrong dates.
Stumbled on this thread luckily. Downloaded WepUpdater and updated the software but this didn't fix the problem, but WebUpdater also offered a chipset update which did fix the issue.
Thank you all for posting your experiences here.