Stive Gonzales

http://www.ign.fr/rubrique.asp?rbr_id=2179&lng_id=EN These are another option and pretty good for the most part with a few annoyances - primarily the poor colour scheme. I use Alps (1), Pyrenees (2) & Provence (3) for hiking, mountain biking, 4x4 etc. and haven't got horribly lost yet. They aren't great in cities due to the amount of detail (buildings) affecting the redraw speed - I generally use City Navigator Europe for driving. Many users use a custom TYP file to change the colour scheme and symbols to either look more like the IGN paper maps or just be more legible in general. See http://gpspassion.com/forumsen/topic.asp?TOPIC_ID=86043 (in french) for what's possible in terms of changing the look. There is however the question of whether these maps will ever be updated in the future. The status of the company that created them is somewhat unclear to me. Having said that, the cost does compare very favourably to the pile of 1:25000 maps you'd need to buy to cover the same area.

I fully understand your point - I make my own maps. However, if I have no maps enabled then it means I have the basemap disabled too. This is the situation where the circle should be smallest since there's no map (in)accuracy to consider. The circle does not match the EPE. Not even close. If I enable a map with 24bit precision Level0 (2.4m grid) then I would expect the circle radius to be EPE+2.4m. It isn't - again, it's much bigger. Ultimately, it's not a show stopper since it doesn't affect navigation in any way, but I think it's a bug nonetheless.

No Bugs How about: 1. Recording an ambient pressure value of 0 just when the unit is switched on. Screws the graphs up. 2. Not graphing pressure over time if GPS (not the unit) or Track Logs switched off 3. Displaying an EPE circle massively larger than the size of the claimed numerical EPE (with no maps enabled, so it isn't factoring the map accuracy into the circle). Which is correct? 4. Triggered proximity/speed alert POI icons not visible unless zoomed in to 80m 5. Huge red "Speed Alert" box that obscures most of the map screen, so even if the icon was visible at any zoom level (the way the older units do it) you wouldn't have much chance of seeing it anyway. Note: My Vista Cx would show the speed camera icons of a proximity warning at the 300-500m zoom levels I use when driving so you could see where the alert was. The HCX doesn't even let you establish if the POI triggered at 1000m+ is even on the same road you are. No Icon + huge red box = useless feature. 6. Unstable & laggy speed readout even at motorway cruising speeds (compared to Vista Cx). Sorry, but our car's cruise control doesn't do ±3kph on a flat motorway on a still day - not according to any GPS that's been in it (my Cx, a friend's TomTom & a couple of different Magellans) except the HCx. 7. Extremely poor rejection of multipath signals. I consider this a bug. If you're going to make a 'high sensitivity' receiver, then you should deal with all the implications of that. Maybe I'm nitpicking, but it wasn't cheap and most of those problems don't exist on the Cx. Personally I wish I still had a working Cx, but it died and disappeared in transit to Garmin UK, which is what prompted me to buy the lemon. Of course, if I hadn't owned a Cx, I wouldn't know any better and would likely be reasonably happy with the HCx. As it stands, however, I'm not impressed.

I'd just like the HCx to be as reliable, with respect to whether I'm moving or not, as my Cx was. Unfortunately, it isn't. They both cost the same, but the older model doesn't have an instantaneous speed readout that fluctuates constantly between zero and some random approximation of speed. I don't really care how they did it with the Cx. Perhaps it was simply averaging over several consecutive measurements. Whatever it was; it seemed to work. The moving vs. stopped times made sense and so did the speed, even when walking.

I just did my first walk out with my new HCx today and back at my laptop now I'm seeing the same thing. Trip Distance 7.67km Track Length 8.8km The unit spent quite a lot of time showing my speed as 0kph - especially on steep climbs - and as far as I'm concerned that's all that's required to explain the discrepancy. I notice that the "Speed Filter" that was on my Vista Cx (R.I.P.) is gone from the Marine tab of the Map setup screen on the HCx. It would appear that the HCx algorithm for determining whether you're moving or not isn't as effective or reliable as that in the older units. Having said that; I was under the impression that speed could be calculated without position measurement... ... so there's no excuse for a GPSr being confused over whether it's moving or not unless your're cutting corners and costs. Fix it Garmin. Thanks.

Strangely enough my Vista Cx (running firmware 2.6 reverted from 2.7) has just refused to power on. Seriously. Coincidence I'm sure, but not a happy one.

Just to see if it was my imagination, I reinstalled firmware 2.7 today and got a fantastic track log on the mountain bike. The highlight of the show (there were others too) was this : Again, 'Lock on Road' turned off. No routing of any kind active. I came off a forest road (far right - I'm travelling from right to left) and turned leftish up the hill on the D920. The tracklog shows me going the other way. The Estimated Accuracy at the time was 2m. The length of the segment highlighted in blue where it finally jumps to where I really am is 98m. That's nearly 50 times the displayed accuracy. It appears to me that the unit, despite being told not to, was trying to be clever and failing.

That, unlike 'Lock on Road', should have no effect whatsoever on where the gps displays your position in relation to the map. I've seen the same (apparently) jumping to a road and back zig-zag behaviour on my Vista Cx with firmware 2.7 but at the time put it down to multipath errors in the rather hilly area where I live. Looking at the track logs shows that it doesn't necessarily jump exactly to the road altthough at 'normal' 80m - 200m zoom levels on the GPS it certainly looks like it jumps to the road. Here's an example. Neither 'Lock on Road' nor Routing was active at the time. Curiously it never happened before and it hasn't happened since reverting to firmware 2.6. As a possibly subjective generalisation, the tracklogs I've recorded using firmware 2.7 are junk in comparison to older tracklogs in the same areas. It wouldn't be the first time that a firmware upgrade has fixed something and broken something else, nor would it be unheard of for undocumented changes to have unintended consequences.