SiliconFiend

I've encountered the same problem with my Venture HC. I've tried at least a dozen times in the last three months to update and the software updates, but the chipset won't. I contacted the Garmin technical support about it and they thought it was my firewall, but after letting them log on to my computer and shut off all the security programs, it still didn't update. They also checked the data transmission to and from my Venture to their website and said eveything is working fine. They now think the problem is that I already have the most recent update. I guess I'll have to wait for them to post an update to verify that. Phynd You can check the software versions installed by going to the System setup page, then press the Menu button and selecting Software Versions.

Most Garmin handhelds (except the newest ones) do all three. My Vista HCx will show a nice tide chart for a selected tide station on whichever day I choose.

Here are a few tricks I use: Collapse the useless zoomed-out map to help ensure the "print-friendly" version will fit on one page. Print 4-up--4 pages tiled onto one. Print both sides. My printer happens to have both a 4-up feature as well as a duplexer, but you can accomplish the 4-up using Adobe Acrobat, too. I'm not a premium member, so I can't get a straight PDF from Groundspeak. But I do have the full version of Acrobat, so I can print the cache pages to PDF files, then combine the multiple PDF files into one for printing. Then you can use the scaling dropdown in the Acrobat print box to print 4 pages on one. That way you can get 8 cache descriptions onto one 8.5 x 11 sheet (4 front, 4 back).

Why would it matter? GPS receivers, are just that, radio receivers . . . passive devices. Their CPU's might radiate some EMI, but given their low power, not much. Clearly a case where "One test is worth, One-thousand expert opinions." Do one of your test tracks with all three rubber banded together, compare the tracks to previous single unit tracks, then you and we will all know. Besides, all that walking is good for your heart. Every radio receiver is also a tiny transmitter because the device has to generate a frequency that matches the carrier frequency it's trying to receive. That generated signal can leak out the antenna. That's the reason that airlines ask you to turn off even AM/FM radios in flight (to prevent any possible detrimental interference with the avionics). So, it's entirely conceivable that several devices tuning into the same frequency could interact with each other. Count me as another "expert opinion" I guess.

I don't think GPS Chipset version 2.70 was ever released. Anyway, you don't want 2.60--that's the one that's been causing the drift problems. You can download 2.50 (the last known good version) in the zip file linked here. But hopefully 2.80 will fix the drift issue and there will be no reason to downgrade.

Not true in the UK as I bought a Colorado and Oregon for my family and have not seen one yet. This is no good in the UK unless you have a previous MapSource [so no "Trip and Waypoint Manager" - NO Mapsource] unless you have CityNavigator/TOPO You could try downloading and installing Garmin's free Training Center software, then it should allow you to install the Mapsource upgrade. Then you would have a full version of Mapsource (with only the basemap). I'd recommend version 6.13.7 as people are having trouble with 6.14.1.

Neither Garmin topo US 3.02 or the newer topo US 2008 have any unlock codes. are you using a different version of topo? The Topo Great Britain versions are routable and require unlock codes.

Here is the quote. If it helps. Now, as a caveat, I also have loaded a customized transparent topo overlay (using Topo 3.02), so I'm sure searching through 2 map sets doesn't help. Although, hiding the Topo map does not increase the speed at all. Hey, I recognize that quote... This thread is the place to start. Specifically look at this post where I explain what I did. Topo 3.02 is the older version of Garmin's Topo maps. The trick I used to create this overlay may not work with Topo 2008 (some people have said they couldn't do it).

I used to have a version MetroGuide (hacked to make it routable) on my Vista HCx. It uses the uncompressed, older style map format like the non-NT version of City Nav. It was pretty quick and responsive. Since then, I got City Nav 2009 NT and installed it and it feels much slower. Identifying items on the map with the cursor takes maybe 5-10 seconds where it used to take 1-2 seconds. Calculating (and recalculating) an active route is much slower (sometimes too slow and I miss the turn for the detour) and sometimes the route calculation fails, even over a distance of 10 miles or so. Bringing up the recent finds list has a several second delay as well. In general, it just seems slower. Now, as a caveat, I also have loaded a customized transparent topo overlay (using Topo 3.02), so I'm sure searching through 2 map sets doesn't help. Although, hiding the Topo map does not increase the speed at all. However, the real advantage of the NT format is the space savings. Without the smaller size of the NT maps, I wouldn't be able to have Topo coverage of most of the continental US loaded in addition to my routable road maps all in a 2 GB MicroSD. So, I'm not happy with the slow speed, but I'll accept it to have my nice integrated topo + routable roads.

I will wait....... Wow, that's HUGE progress! They've actually recognized and admitted to a problem! Here's hope for us Vista HCx owners, too (although I've had reasonable success with 2.70/2.30).

I suspect what's happening there is that it's "seeing" more or fewer satellites. The colors are assigned to the slots. Since the signal strength display is ordered by numeric satellite ID, if it suddenly "sees" a new satellite, everything to the right of it will shift over and change color. I've seen it be a bit unstable before where one or more satellites are popping and and out of view, and that causes the color changes like you're mentioning. And to be really correct, the satellites that are shown are not based on signals it actually receives, but are the satellites it should be able to see, based on almanac data and your position.

They are. He is confused. Maybe he meant something like this: If you are outside the US, the WAAS corrections don't work as well because WAAS uses fixed ground stations in the US to calculate the corrections that are sent to your GPS via the geostationary satellites. Some of the corrections depend on location, while others do not. The ones that do won't be correct if you are, for example, in Europe. Not to worry; your GPS will adjust for that automatically. Europe has their own system called EGNOS, which works the same way (and on the same frequencies, etc.) as WAAS, so enabling WAAS will allow your receiver to use EGNOS satellites when they're visible (i.e., in Europe). In general, it's a good idea to leave it on unless you have compelling evidence that it's making your accuracy worse.

Yes, you have been able to do so for at least a couple years. But it's lots of work, it's not a piece of cake. You might have trouble with zoom levels, things might not look as good as the big buck software that you are paying for. there are a few groups in yahoo dedicated to making maps for Magellan, Garmin and Lowrance GPS's. I'm not sure about any others. Heck, I even think you can get OziExplorer to put some maps on some GPS's. No, this is different. What you're talking about is vectorizing a raster image with programs like Mapwel. From the screenshot and description, it appears that Garmin is finally officially supporting raster maps for display (without a vectorizing hack) combined with vector overlays for routing.

The 60CSx does not have drift issues, in the sense that most people understand it here (i.e., the occasional large, systemic deviations in reported position which are corrected by a power cycle). Whoever wrote that was confused. The Oregon does not have drift issues, either, but some people claim it doesn't seem as accurate.

When I first installed 2.70, I immediately experienced drift/track deviation, where I hadn't before (I have an early model). I did the hard reset as you suggested, and while I didn't see the drift again, it just seemed like the position was less stable--it was wandering more. The potential downside of using GPS firmware 2.30 is an inaccurate odometer, but whatever they did in software 2.70 seems to have fixed that problem. It does seem to have trouble recognizing motion below 2 km/h (a common symptom for GPS firmware versions before 2.60). I haven't paid attention to see if the trip computer shows an abnormally high stopped time vs. moving time (also a common symptom for 2.30) so if that's important to you, you might think twice about using it.

I'll add in one more account of my 2.70/2.30 combination here. Went hiking again this weekend, in slightly less challenging conditions. Still under tree cover for a significant portion, and in a valley (not quite a canyon like last time). We were walking with toddlers, so I was significantly slower this time. I forgot to reset the odometer at the start of the hike, but at the halfway point, I reset it before we started back. It read 1.55 km at the end, and checking the tracklog in MapSource, it read 1.60 km. No drift showed up in the tracklog. There was one minor deviation (maybe 20 feet off for a stretch of 100 feet) but otherwise the out and back tracks were very close together. So, everything seems to be working well. I won't complain about a 50 meter discrepancy, especially when I was walking so slowly.

If you really want to get into map-making, why not check out OpenStreetMap? There's a bit of a learning curve involved, but the data you enter is shared with everyone and can be used for online maps (like Google Maps) or for printing out your own map of your neighborhood or even creating a map for your GPS.

You would have had the same scratches on a Colorado or even a 60CSx or eTrex. The factory screens just aren't that tough. Aftermarket screen protectors such as the Zag InvisibleShield work great, though (but they might slightly impact the already-poor screen visibility).

Perhaps I will investigate including these roads on my topo maps since they at least start with the tiger data that I've been using. What language are you writing your program in? I've been contributing to a tool called Osmosis, which is written in Java. I'm planning on writing the OSM-to-cGPSMapper translator as a plugin for that, because it's a very well-designed tool and it has the XML parsing already done, as well as a bunch of handy utility classes. I have to write some other tools for it first, most notably a task to slice the planet file into tiles. (I know there's a tool called osmcut, but it's not flexible/configurable enough and doesn't cover all the scenarios needed).

I've tried them(V2 most recent), and really like the work being put into all these free map options, but at least in my state there were numerous errors that no other maps have, and whole sections of the state where it was just blank(at least mapsource never showed anything). It would be really cool if Ibycus or the other free map authors could use OpenStreetMap as the base for the road and trail data, and then as OSM improves, they could release new versions of their maps and they would get better and better. If I ever get my program written, that will be one possibility.

Well, I've had a project a long time in the works to create routable Garmin maps from OSM data, but unfortunately it's still stuck in the concept phase... Early on, I created a quick & dirty XSL template that wrote a cGPSMapper file, and it worked, but it died on even a moderate amount of data. Anyway, in the mean time, some Russians beat me to the punch and wrote a perl script that creates routable cGPSMapper files. I haven't used it myseld, and I don't like perl, so I'll probably still create my own. Nice to have options, right? I got into OSM because I wanted to have (free) routable trails and the only data set that was available even commercially was the Garmin national parks, which has limited coverage. And even the non-routable trails in Garmin's Topo products are lacking. So, I'm hoping OSM can be a good resource for cataloging trails.

No, I ran it on Vista with no problems. But the program was written for Topo 3.02, not Topo 2008. I haven't heard reports of success using it with Topo 2008, but at the least you'd have to create the gdb files to select the segments to combine.

Sort of, but not quite. The actual hike started at the Lazyman Gulch trailhead, i.e. where the yellow track started. The hike followed the road to the hairpin and then followed the trail east from there to a point on the sw side of the know on the righthand margin of the image. So, based on the path that I actually followed, the unit started deviating shortly after I started hiking. Then, the unit regard a major aberration. Then, it sort of caught up with itself and started recording a more normal looking track again. But, I think most of that track log is in error. After, I turned off the unit and restarted it, the unit showed I was in a spot that actually corresponded to the terrain and it led me right to the cache that I was looking for. I didn't post the log here, but after finding that first cache, I hiked another mile to the south to find another cache - through steeper terrain than the first leg and portions of it also were more heavily timbered. Then I backtracked to the trailhead. Throughout, the unit performed normally and laid down a track that was well within the standard error for the unit. There are a couple of other recent threads regarding the recent software updates for the Vista HCx that also discuss this issue. There is at least one post of a track log that shows an aberration similar to what I posted here. There also have been a couple of posts in which people have talked about a track that plots on the map/photo differently than the path that they actually walked. That may be an issue, but it's probably something different from what others have described as "drift". Make sure you tell them that this problem manifested itself only after a GPS chipset firmware update. I believe it was version 2.6 that caused it, according to this thread (at the least, chipset version 2.3 does not exhibit this problem). That might help them narrow it down.

Just a quick note that I installed GPS firmware 2.30 (kept software at 2.70) in my Vista HCx and went for a hike this weekend. Didn't see the drift (maybe... I reset it once when I was driving to the trailhead due to high error in a tight canyon). The conditions may not have been right to create the drift, though--I held the GPS in my hand the whole trip, with the screen facing up. There was some tree cover, but at least half the trip was exposed. The out and back tracks are very close together. The best part is the odometer, though. It read 11.8 km (7.3 miles) when I got back to my pickup, and analyzing the tracklogs later, it also showed exactly 11.8 km. So, software 2.70 seems to do the trick for the odometer, and 2.70/2.30 seems to be a good combo overall.

Just to let you know it isn't because you live in Alaska that you have to buy the maps, those of us in the lower 48 have to buy the maps too. And just a heads up for you. GPS street maps are off by about 60 feet in parts of the state around Ketchican and Sitka. This is because the map makers(not the GPS makers) have not updated their maps after a couple of earthquakes up that way. The maps are accurate as far as to what roads there are but everything is shifted. I had the issue with both a TomTom receiver and a Garmin receiver while I was up there. Is that really true? 60 feet is a huge distance for earthquake ground movement. I didn't think there had been anything big enough since the 1964 monster quake, and I doubt even that one shifted roads 60 feet. I would think it might be more like the problem seen with Garmin's Topo 2008 maps or the TIGER data, where they were based on aerial imagery and not yet corrected with GPS measurements.