Hertzog

The Eneloops and the Rayovacs are pretty much equivalent, and one is as good a choice as the other. I've been using the Eneloops simply because I found them before the Rayovacs and like to stick with one product. The Rayovacs and Eneloops don't have quite the capacity of some of the other Nimh's (they advertise 1900 to 2000 mAh vs upwards of 2600 for some of the others), but have the advantage of much slower discharge times in storage. So if you are normally using batteries within a day or so of charging them you may want to stick with the higher capacity batteries; but if you want to have batteries that are still good a few weeks to a year after charging, then the new ones are a better choice.

I thought I had seen the 0.5m granularity in the gpx data as well as the active track data, but in looking at my previous tracks I see this isn't the case. So the 0.5m granularity appears to be only in the active track data downloaded from the gps. Since I use G7toWin to port the data to Excel, it might even be something G7toWin is doing; maybe you could download an active track directly from your gps to OziExplorer or GPS Utility and see how they treat the data (or is that what you did?) . I guess the best bet is to rely on the gpx data and forget about my original statement! OK, answered my own question; turns out I recently downloaded GPS Utility, and it shows the same granularity as G7toWin (when opening a gdb file). So I would say the granualrity is in the active track data coming from the GPS, and not an artifact of the program reading it.

Interesting ... I've got over 5 years worth of track logs from my old Venture in OziExplorer format which records altitude in feet (only to one decimal place though), and what you're describing does indeed seem to be apparent. You can see it most clearly on sections of the track that are largely flat(ish). I've only used my Vista HCx twice so far, and on reasonably hilly terrain, so maybe the effect isn't obvious in those logs, so i may have to eat my words when I said it wasn't apparent on this unit I'll try that test you suggested. I just followed my own advice and retested; I am NOT seeing it today (on my 60CSx). Maybe they have done something with the latest firmware update (maybe I'm crosseyed, today or before). I'll look at my own results again later; now I'm going for a walk!

What makes you think that? Certainly in the GPX tracklogs that the Vista HCx writes to the memory card, there's no indication of anything like that and I see altitudes (in metres) with significant digits down to 3 decimal places both there and in the track logs I download into OziExplorer. If what you say is true, I'd only see multiples of 0.5m (which is what I assume 1.572 feet is!) I've seen it in my 60CS and 60CSx data, and (I think) my old B&W Vista data; could be they have changed it in the newer models. Yes, it's close to (but not quite) 0.5 meters; I've been puzzeling about the underlying cause for about 2 years, haven't come up with anything. It would be very interesting to confirm that the HCx does or doesn't have it. To see it, record about a minute's worth of data at the 1 second rate, then plot the altitude data against time. There should be enough sample to sample noise to see different levels, but it doesn't hurt to move it up and down a little while recording

On scaling versus threshold: I first thought scaling... Looks like you've pretty much anticipated and already looked at most of my ideas; I think you are correct in that it's a threshold problem. One thing you want to be aware of in using the altitude data (you may have already observed this yourself): There is an underlying granularity of 1.572 feet in the track log altitude data. This is hard to see if you get your data to Excel via MapSource since MapSource rounds it to the nearest foot, but is evident if you use the gpx data directly in Excel or port it through a program such as G7toWin. This probably isn't significant in your results, since you are talking about 7 foot thresholds, but I'm guessing you are using auto or at least something other than the 1 second logging rate for your results. At 1 point/sec it can add quite a bit of error without filtering the data.

I think you are right about the velocity being used for the odometer and total ascent calculations, but I am suspecting the total ascent problem to be a scaling error rather than a threshold problem. The main reason is you seem to be getting consistently the same results from run to run - if it were a threshold problem, I would expect the errors to be more variable. Another thing you might want to look at is the total descent results; since you are probably going faster on the downhills there should be less variablity if the threshold is the culprit. I like your plots. I've done similar ones using Excel, but it looks like you've got it down to a production. One thing you could do is apply a threshold to your Excel total ascent calculation, and see what threshold matches the tracklog total ascent to the trip computer total ascent. One thing to be careful about here is this would involve derivatives of noisy data, but since the altitude data is primarily the barometric I would expect that short term variations would be real and not noise.

I just checked this on my 60CSx; it does seem to be the case.

If you turn on "lock on roads" it will go away; there is no way of turning it off independently of the lock on roads setting. (This is the case for the 60's and 76's; should be the same for other recent Garmins as well.)

You might want to make sure you aren't set for kilometers instead of miles. No, that's not it (I made a quick erronous calculation). But double check your units anyway; can't hurt.

The radius of the circle is about 3.4 times greater than the accuracy number - apparently to go from about a 50% confidence level to a 99% (Garmin doesn't say exactly what they are doing, but this seems to make sense). They also add in an extra error to account for the inaccuracy of whatever map is being used. You can see this if you switch to the basemap; there the map error dominates and the circle gets very large (0.2 miles is what you get with the basemap).

It is on mine, didnt know you could turn it off. will have to look into that. You can't turn it off indenpendently, but if you use the "lock on roads" setting it goes away. (This applies to the old Vista, 60CS and 60CSx; it's possible they have made it possible to turn it off on some of the other models - should be simple enough, and a lot of people don't like it - but I doubt it.) I personally like it - gives you a good idea of how much to trust your displayed position - but each to his own.

Good information; I wasn't aware of this. Technically, the AA lithiums are not the same as the lithium ions they are targeting (in fact, as I understand it the AA lithiums are more evionmentally friendly than alkalines), but the average checker probably wouldn't know that (I don't think some people at Garmin know it )

Probably the alkaline is better, but it doesn't really matter (I happen to have lithiums in mine right now, and I didn't think to change from the NIMH setting). The lithiums are fine if they work at all; some 60CSx's (mine included) will not turn on with most fresh lithiums - voltage is slightly too high for the sensor circuit - the unit momentarily comes on and then the display slowly fades away. If you put them in and the 60CSx turns on you are good to go (the higher voltage doesn't do any damage). The lithiums last a long time - 50 to 100% longer than alkalines - but when they go you don't have much warning (the discharge curve is very flat, with a sharp cutoff at the end). So you want to make sure you have some spares with you.

Google Earth is generally more accurate than that, but I've seen instances where it was clearly off by that much. You should check your datum (make sure it is set to WGS 94), but most likely it's just the Google Earth registration at that particular area.

That's an interesting plot, but if I may make an observation: The red curve looks like the integral of the blue curve. If the blue line is your instantaneous altitude, then the total ascent will be the accumulation of all the altitude increases, not the integral of the altitude. OK, on looking at it further, maybe it is the cumulative increase :-) The increase at the end had me fooled.

I recall having a problem like this in the past; I think you need to have track logging turned on to get an elevation profile.

Although we've talked about the memory size issues, another thing you need to consider is how the Topo 2008 will look on a gray scale display. I'm not sure how you can evaluate this short of loading a sample on your unit; maybe you can get an answer to this from Garmin support, or maybe someone that has actually tried it on a B&W unit can chime in.

The "pre-x" units draw less power, except when the compass is on (compass draw is negligible on the x models but wasn't on the pre-x models). For some measurements of both see: http://groups.yahoo.com/group/Garmin_GPSma...Rows&tbl=13 (Those were for the 76 models, but are typical for the 60 models as wel (Note: I didn't see the reference to "external power"; the messurements I am referring to are current at the GPSr battery terminals.)

The segments (looking at the Phonix area) tend to be a little less than 0.5MB, so you could shoe-horn a few of these into 8MB. The area coverage/segment seems to match the old topo pretty well, but each segment in the old topo takes less memory 260KB vs 395KB for one typical segment.

Carefully look at the bottom of the 2nd screen when you turn it on; the US units will say something like "Americas Rec Basemap", and the UK version will say something else. As far as I know that is the only way to tell, other than viewing the basemap on the Map page to see what you have. Functionally, I don't think there are any other differences between the units. The position format and map datum you describe are pretty standard (I guess the UK units might come preset to some other datum, but I haven't heard that). You can easily change them to something else if yoy prefer.

You can't autoroute on the GPSr with Metroguide; to autoroute you need City Navigator(Much discussed issue in the past). What's happening is that the GPSr is autorouting using the basemap.

Thanks for the info; I've been curious about that. It's pretty much like I expected -- you have to "roll" it in some fashion in order to calibrate the 3rd sensor. Although it's more complicated than the Garmin procedure, I wouldn't mind the extra work to get a decent 3-axis compass.

I think the 3-axis compass is the one place we all agree that the Magellans trump the Garmins. I'm curious about the calibration of the Magellan compass; we talk a great deal about the calibration procedure for the Garmins, but I've never heard anything about the Magellans. Do they have a similar two turn procedure? And is there an additional requirement to rotate it about its "roll" axis?

The Garmin Astro is said to have a 3-axis compass, but I haven't seen any reviews of it. It's probably in the dog unit; the receiving unit looks like a 60CSx with an extra antenna.

You can change the display format in Google Earth (Tools/Options/3D View in my version). FWIW: Google Earth and MapSource are both pretty flexible when it comes to copying and pasting coordinates; they can recognize when the data you are pasting in is not the format they are set to and interpret it correctly.