Jump to content

Garmin Vista HCx total ascent computed incorrectly


groth

Recommended Posts

I just sent the following to Garmin customer support:

 

I took my Chistmas Vista HCx for its first bicycle ride yesterday. I could tell on the ride that it wasn't computing total ascent properly. When I got home, I uploaded the track and computed 1866 ft of climb. The receiver said 632 ft. I am aware that there are problems with how one accounts for the noise, but this usually enters at the 5-10% level, not a factor of 3. Also, the total ascent calculated from the track log agrees with what I was expecting from previous rides with a Summit, Vista, and Vista C. I would be happy to provide the track log or a plot of the elevation and total ascent.

 

Here is the plot I referred to above:

 

Profile_20071229.gif

 

Other data:

 

Software Ver 2.50, GPS SW 2.30. ID 3377960307. WAAS enabled, variable elevation.

 

Also, the odometer calculated by the receiver was 31.5 miles compared to 31.3 I calculated from the track log. I don't know if I have the "trip odometer" problem or not. I think I would have to take the receiver for a walk to get the slow speeds required to produce the problem.

 

Have others seen this problem?

 

- Ed

Link to comment

Yes, I've noticed exactly the same problem. I went on a hike last week, that started and finished at about 200m and went up as high as 925m with a few other small ascents in between. I'd have guessed at about 900m of climb altogether, but my Vista HCx said 550m or thereabouts! The altitude plot on the unit looks OK, and the altitude plot displayed in OziExplorer from the downloaded track looked OK as well.

 

I'd be interested in what reply you get from Garmin.

 

My software is at 2.50 and GPS at 2.40.

Link to comment

 

Profile_20071229.gif

 

 

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.

Edited by Hertzog
Link to comment

Yes, I've noticed exactly the same problem. I went on a hike last week, that started and finished at about 200m and went up as high as 925m with a few other small ascents in between. I'd have guessed at about 900m of climb altogether, but my Vista HCx said 550m or thereabouts! The altitude plot on the unit looks OK, and the altitude plot displayed in OziExplorer from the downloaded track looked OK as well.

 

I'd be interested in what reply you get from Garmin.

 

My software is at 2.50 and GPS at 2.40.

 

2.40 huh? So do you have the low speed problem with that version, or does that fix it? I also notice that it is not on Garmins site yet....

Link to comment

 

2.40 huh? So do you have the low speed problem with that version, or does that fix it? I also notice that it is not on Garmins site yet....

 

The recent units have shipped with SW Version 2.40, the earlier units that shipped with 2.20 or 2.30 cannot be upgraded to 2.40 (apparently).

 

The update from 2.30 to 2.40 did not make any difference to the low speed tracking.

Link to comment
2.40 huh? So do you have the low speed problem with that version, or does that fix it? I also notice that it is not on Garmins site yet....

It's better than what a lot of people have reported with the 2.30 version, but still not quite right when compared to the reported distance computed from the track logs. It was supplied with that version of the GPS firmware I believe, although I'm not quite sure as I ran Webupdater as soon as I got it set up.

Link to comment

I see nothing wrong with the graph.

If I hiked up a 1000m tall mountain to take a picture of the scenery and hiked back down only to go back up to retrieve the camera I forgot, the "total assent" would be 2000m

He said there was nothing wrong with the graph -- it's correct. The GPSr, however, on it's own display showed an incorrect 632 feet when it should have displayed 1866, same as the graph.

 

When I got home, I uploaded the track and computed 1866 ft of climb. The receiver said 632 ft.
Link to comment

Yes, I've noticed exactly the same problem. I went on a hike last week, that started and finished at about 200m and went up as high as 925m with a few other small ascents in between. I'd have guessed at about 900m of climb altogether, but my Vista HCx said 550m or thereabouts! The altitude plot on the unit looks OK, and the altitude plot displayed in OziExplorer from the downloaded track looked OK as well.

 

I'd be interested in what reply you get from Garmin.

 

My software is at 2.50 and GPS at 2.40.

 

Well, so far, I've been told to reset the unit (with incorrect instructions on how to reset it!). I sent back a rather testy reply.

 

However, I did reset. I also updated the software as suggested (I had just updated it before the ride and sure enough when I used web updater it told me I was up to date).

 

I'll do another ride this weekend and I bet I'll find the same problem.

 

- Ed

Link to comment

Well, so far, I've been told to reset the unit (with incorrect instructions on how to reset it!). I sent back a rather testy reply.

 

However, I did reset. I also updated the software as suggested (I had just updated it before the ride and sure enough when I used web updater it told me I was up to date).

 

I'll do another ride this weekend and I bet I'll find the same problem.

I'd put money on it :P I'm out tomorrow on a hike too, so I'll check it out as well and come back with some figures. What software did you use to analyze the track data by the way?

Link to comment

Well, so far, I've been told to reset the unit (with incorrect instructions on how to reset it!). I sent back a rather testy reply.

 

However, I did reset. I also updated the software as suggested (I had just updated it before the ride and sure enough when I used web updater it told me I was up to date).

 

I'll do another ride this weekend and I bet I'll find the same problem.

 

- Ed

 

I did my ride and found the same problem. Below is what I just sent to Garmin:

 

The problem is definitely repeatable. Also I may have found another problem which is described in the 3rd to last paragraph below (has to do with the display and half used batteries).

 

I took the HCx out for another ride on Saturday and also took my Vista C.

 

I had to make a special mount to put them side by side on my handlebar stem shown in the picture below (taken when I returned).

 

Garmins_x_2.jpg

 

I bigger view so you can read the total ascent (upper left field of both screens):

 

Garmins_x_2_big.jpg

 

which shows the HCx on the left calculated a total ascent of 567 feet vs the C on the right which calculated a total ascent of 1986 feet. All during the ride, the HCx lagged behind the C by roughly the same factor. I could see the total ascent being incremented on the C while nothing happened on the HCx. You can see from the screens that the elevation profiles are essentially identical.

 

Of course it goes without saying that I set them to the same altitude when I started the ride and I zeroed both track logs and the altitude data when I started.

 

Below are the profiles for the C and HCx plotted from the uploaded tracks. Again, the profiles are almost identical. The plots also include my calculation of the total ascent,

2117 feet for the C and 2183 feet for the HCx in good agreement with each other and also that calculated by the Vista C, but way bigger than that calculated by the Vista HCX.

 

Profile_20080105C.gif

 

Profile_20080105.gif

 

The next plot is a plot of altitude vs time for both receivers from the track logs. They agree very well!

 

A_vs_T_20080105.gif

 

The long flat spot starting at 14 hours is when I turned them off and took them inside while I had lunch. At 17 hours I made a bathroom and beer stop and here I left the bike outside with the receivers running (a very out of the way place, so I wasn't worried about anyone stealing them or the bike). The C's batteries were dead when I came back out - looks like they died just after I went inside, so the C's curve is flat, while the HCx's curve drifts around.

 

The C turned itself off fairly early in the ride, but I caught it right away and probably went a couple of hundred fairly flat yards before it acquired satellites again. (My C has always been very flaky: it turns itself off frequently from road vibration or even just operating buttons).

 

Later I was finding the HCx's display hard to read and it fact it looked like every other horizontal scan line was white. I stopped and turned on the light and I saw that I was down to two battery bars. Replacing the batteries made the display appear normal. This seems to be something new: in all three of my previous Garmin receivers, the display looks fine until the receiver complains about low batteries and turns itself off! Could there be something wrong with the display?

 

While I was doing this, I operated the page button on the C and it turned itself off! So I turned it back on.

 

THe upshot of all this is the HCx was off twice: once to change batteries, and once while I took it inside for lunch. The C was off four times: Once when it turned itself off on the road, once when it turned itself off while I was stationary and operated the page button, once while I took it inside for lunch and once when its batteries ran out while the bike was parked. Only one of these times was the bike moving when it covered a few hundred yards and little elevation gain (say less than 20 feet).

 

I am looking forward to a patch that cures the total ascent calculation.

 

Thanks,

Ed

Link to comment

I'd put money on it :laughing: I'm out tomorrow on a hike too, so I'll check it out as well and come back with some figures. What software did you use to analyze the track data by the way?

 

I'll be interested to hear what you find. I just posted my results - same problem.

 

My software: I'm a Mac user, so I use MacGPSPro to upload the track log. Then I have a homebrew Excel template that I use to calculate distance, time, speed, climb, etc. from the uploaded track log.

 

- Ed

Link to comment

I'd put money on it :) I'm out tomorrow on a hike too, so I'll check it out as well and come back with some figures. What software did you use to analyze the track data by the way?

 

I'll be interested to hear what you find. I just posted my results - same problem.

 

My software: I'm a Mac user, so I use MacGPSPro to upload the track log. Then I have a homebrew Excel template that I use to calculate distance, time, speed, climb, etc. from the uploaded track log.

 

- Ed

Sorry, wasn't feeling too well at the weekend, so I didn't go out after all. Hopefully I'll be out next weekend.

 

I've found some software for the PC that will analyze GPX track logs and spit out all kinds of useful info including total ascent. It's in German though, so maybe not for everybody :)

Link to comment

Well, so far, I've been told to reset the unit (with incorrect instructions on how to reset it!). I sent back a rather testy reply.

 

However, I did reset. I also updated the software as suggested (I had just updated it before the ride and sure enough when I used web updater it told me I was up to date).

 

I'll do another ride this weekend and I bet I'll find the same problem.

 

- Ed

 

I did my ride and found the same problem. Below is what I just sent to Garmin:

 

.......

 

THis past week I upgraded my software from 2.50/2.30 to 2.50/2.60 and today (Saturday, January 12) did the same ride as I did last Saturday. As far as I can tell there's no change in the total ascent computation.

 

Here's what I just sent to Garmin:

 

Today I did the same ride as last Saturday (with the exception of the bathroom & beer break after about 30+ miles.) I assume you have all the data from last week's ride from xxx.

 

This is with the Vista HCx at versions 2.50/2.60. (Previous data was at 2.50/2.30.)

 

The total ascent shown by the Vista HCx was 846 feet at the end of the ride. Several hundred feet of this was added by a bogus altitude reading after I turned the unit back on after lunch. Discounting this several hundred feet, the total ascent for the "real" altitude profile in the ride would be about 600 feet, about the same as last week. The Vista C's total ascent from last week was about 2000 feet. The total ascent calculated from the track logs (Vista C last week, Vista HCx last week, Vista HCx this week) ranges from about 2100 feet to 2400 feet.

 

It's pretty discouraging to be doing a steady (always up, no going back down) climb of 300+ feet (starts just after mile 20 in the plot below) and see the altitude going up but see NOTHING added to the total ascent!

 

There are two plots below. The first has the bogus altitude reading edited out of the track log. The second has it left in.

 

I would say that nothing (or at most, very little) has changed with the total ascent problem in going from GPS SW version 2.3 to 2.6.

 

Start Speculation:

 

I guess that the unit software does the distance calculation for the trip odometer and the total ascent calculation. I further guess that the unit software relies on a velocity computed by the GPS software. If the horizontal component of the velocity is non-zero, the trip odometer is incremented. If the vertical component is non-zero and positive, the total ascent is incremented. Additional guess is that the GPS software contains thresholds for deciding when the raw velocity is too small and should be truncated to zero. It appears from what I've observed with my own unit on the total ascent problem and what I've read about the trip odometer problem on the Groundspeak forums that the thresholds that have been set in the GPS software are most likely appropriate for automobile travel! And not for hiking (it is billed as a handheld unit!) or cycling.

 

End Speculation.

 

I am sometimes able to watch the vertical velocity display on the unit. The lowest I've seen it read (other than 0.0) is about 17 feet per minute. I also have some idea of how much hill climbing I've done on previous rides and how long it took and very roughly, 17 feet per minute is probably close to my upper limit for a sustained climb.

 

If 17 feet per minute is indeed the velocity threshold for incrementing total ascent, then the lower limit for incrementing total ascent is about the same as my upper limit for climbing. Seems like a mismatch to me!

 

What's used in the Vista C?

 

Thanks,

Ed

 

Profile_20080112.gif

 

 

Profile below has one bogus point just before mile 20 (from turning the unit back on after lunch).

 

Profile_20080112x.gif

 

 

Link to comment

I guess that the unit software does the distance calculation for the trip odometer and the total ascent calculation. I further guess that the unit software relies on a velocity computed by the GPS software. If the horizontal component of the velocity is non-zero, the trip odometer is incremented. If the vertical component is non-zero and positive, the total ascent is incremented. Additional guess is that the GPS software contains thresholds for deciding when the raw velocity is too small and should be truncated to zero. It appears from what I've observed with my own unit on the total ascent problem and what I've read about the trip odometer problem on the Groundspeak forums that the thresholds that have been set in the GPS software are most likely appropriate for automobile travel! And not for hiking (it is billed as a handheld unit!) or cycling.

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.

Link to comment

OK, so I went out hiking yesterday with my Vista HCx (at 2.50/2.60).

 

Started at an altitude of 228m and climbed steadily to 555m. The total ascent at this stage showed as 131m!! At the end of the walk (altitude 208m) Total ascent showed as 376m and total descent as 409m.

 

I put the track through an analysis program and it came back with 1192m ascent / 1212.7 descent which is way over the top I think, and probably caused by insufficient smoothing / filtering. The terrain was very uneven (covered with what are known in these parts as "peat hags", if you know what these are), but looking at the altitude profile and adding up the really significant height gains by hand, I'd say the truth was probably closer to 800m total ascent.

 

There's clearly something wrong here, and I'm leaning towards the explanation given that it, as well as the Trip Odometer are somehow velocity driven rather than driven by changes in horizontal or vertical position, or maybe there's some kind of minimum speed filter in place as there possibly was in the case of the latest 2.60 GPS s/w update.

 

In any case, for it's primary intended purpose, i.e. outdoor pursuits that normally imply slow speeds, it makes this display essentially totally worthless.

 

Does anyone know if the older units with barometric altimeters, such as the Summit suffered from similar problems?

 

@groth: Have you had any kind of reply yet from Garmin on this matter?

Link to comment

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.

 

On scaling versus threshold: I first thought scaling; with the factor of approximately 3, a meters to feet conversion problem seemed likely, but in fact, watching the display, you see it add nothing to total ascent while you are going up a long climb! Also, you see 0 ft/min as the vertical velocity. I have to watch the road sometimes! So I can't watch the display all the time and be certain of the correlation of vertical speed and ascent increment.

 

On threshold size: I only have altitude, not vertical speed, so I can only apply a threshold based on the size of the altitude change. My normal algorithm is: if the previous altitude increment is not negative and this altitude increment is at least 2 feet, add this altitude increment to the total climb (ascent). I had to change the threshold to 7 feet to get a total comparable to what the display was telling me.

 

On ascent vs descent: on the rides where the result should be about 2000 feet, the display reports an ascent of about 600 feet and a descent of about 1200 feet. Of course, down hills are much faster than up hills. On reaching the top of a hill, I generally stop pedaling and coast down and it takes a bit for the speed to build up. At the bottom, some of the speed is carried part way up the next hill until gravity wins and I have to start pedaling to keep a more or less constant speed. In other words, not all of the down hill will be above threshold nor will all of the uphill be below threshold (if in fact it's a threshold problem). These rides have been loop rides with the starting and ending points and altitudes the same. So total ascent should equal total descent modulo the drift of the altimeter which seems to be less than 100 feet for all the rides with the HCx. (With previous GPS receivers, they have never been equal, but much closer and both close to the total computed from the track log.)

 

- Ed

Link to comment

think you are right about the velocity being used...

 

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.

Link to comment

OK, so I went out hiking yesterday with my Vista HCx (at 2.50/2.60).

 

Started at an altitude of 228m and climbed steadily to 555m. The total ascent at this stage showed as 131m!! At the end of the walk (altitude 208m) Total ascent showed as 376m and total descent as 409m.

 

I put the track through an analysis program and it came back with 1192m ascent / 1212.7 descent which is way over the top I think, and probably caused by insufficient smoothing / filtering. The terrain was very uneven (covered with what are known in these parts as "peat hags", if you know what these are), but looking at the altitude profile and adding up the really significant height gains by hand, I'd say the truth was probably closer to 800m total ascent.

 

There's clearly something wrong here, and I'm leaning towards the explanation given that it, as well as the Trip Odometer are somehow velocity driven rather than driven by changes in horizontal or vertical position, or maybe there's some kind of minimum speed filter in place as there possibly was in the case of the latest 2.60 GPS s/w update.

 

In any case, for it's primary intended purpose, i.e. outdoor pursuits that normally imply slow speeds, it makes this display essentially totally worthless.

 

Does anyone know if the older units with barometric altimeters, such as the Summit suffered from similar problems?

 

@groth: Have you had any kind of reply yet from Garmin on this matter?

 

Peat hags: I had no idea what a peat hag was, but I googled it and even found a photo of icicles hanging from the sides of a peat hag. Looks like they could be tough to hike through!!!

 

I have a summit, a vista, a vista C, and now a vista HCx. All have a barometric altimeter. In fact, I think you don't get the altitude page unless you have the barometric altimeter (at least in the etrex series). I believe that all use the barometric altitude as primary with the option to correct (over time) the barometric altitude with the GPS altitude.

 

The summit, vista, and vista C all have given results similar to each other and in agreement with calculations from the track log. The HCx is the first that I've owned with displayed results in violent disagreement from the track log calculations (which are in agreement with the previous track log calculations). Also, my experiment with running the C and the HCx side by side is, I think, conclusive evidence that there is something wrong with the HCx's total ascent calculations.

 

Replies from Garmin: Yes, none have been very helpful. I'm not convinced they think there's a problem. The last was, which software versions are you using? This was just after GPS 2.6 appeared on the web site. At that time all my data had been collected with 2.50/2.30. The most recent data is with 2.50/2.60, and I sent the report on this last night (Saturday). It's a weekend and not surprisingly I haven't heard anything back yet.

 

- Ed

Link to comment

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.

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!)

Link to comment

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.

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 :laughing:

Link to comment

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 :laughing:

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.

 

EDIT: Indeed I set it outside on a table for a while and then lifted it above my head and put it on the floor for a bit and the only altitudes measured in the log (as imported into OziExplorer) were 54.9, 55.4 and 56.4 metres which would tend to indicate a 0.5m granularity. It's not based around an integer value though, which is why it doesn't immediately spring out at you in a more chaotic 'normal' track log (I'd first looked for just either .0, or .5 after the decimal point).

 

However, and this is odd, the GPX file saved to the memory card is showing very different values, with no altitude being the same over that period to within 3 decimal places.

 

I wonder whether there's some limitation in the Garmin PVT protocol preventing more precision in the altitude being transferred over the USB or serial connection, somehow?

 

Unfortunately I can't upload files here, and they're a bit too long to quote in their entirety, but here's a small 10 second section from each covering the same time period for comparison. In the Ozi file, the 4th item is the altitude, in feet for some weird reason, and in the GPX file it's in metres, but you get the drift ...

 

OziExplorer Track Point File Version 2.1

WGS 84

Altitude is in Feet

Reserved 3

0,2,255,ACTIVE LOG ,0,0,2,8421376

205

53.194830, -6.128580,0, 181.8,39460.7326389, 13-Jan-08, 17:35:00

53.194830, -6.128580,0, 180.2,39460.7326505, 13-Jan-08, 17:35:01

53.194830, -6.128580,0, 180.2,39460.7326620, 13-Jan-08, 17:35:02

53.194830, -6.128580,0, 181.8,39460.7326736, 13-Jan-08, 17:35:03

53.194830, -6.128580,0, 180.2,39460.7326852, 13-Jan-08, 17:35:04

53.194830, -6.128580,0, 180.2,39460.7326968, 13-Jan-08, 17:35:05

53.194830, -6.128580,0, 180.2,39460.7327083, 13-Jan-08, 17:35:06

53.194830, -6.128580,0, 180.2,39460.7327199, 13-Jan-08, 17:35:07

53.194830, -6.128580,0, 180.2,39460.7327315, 13-Jan-08, 17:35:08

53.194830, -6.128580,0, 181.8,39460.7327431, 13-Jan-08, 17:35:09

53.194830, -6.128580,0, 181.8,39460.7327546, 13-Jan-08, 17:35:10

 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<gpx xmlns="http://www.topografix.com/GPX/1/1"'>http://www.topografix.com/GPX/1/1" creator="" 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">

<trk>

<name>ACTIVE LOG173448</name>

<trkseg>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.187</ele>

<time>2008-01-13T17:35:00Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>54.939</ele>

<time>2008-01-13T17:35:01Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>54.968</ele>

<time>2008-01-13T17:35:02Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.262</ele>

<time>2008-01-13T17:35:03Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.159</ele>

<time>2008-01-13T17:35:04Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.107</ele>

<time>2008-01-13T17:35:05Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.117</ele>

<time>2008-01-13T17:35:06Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.007</ele>

<time>2008-01-13T17:35:07Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.055</ele>

<time>2008-01-13T17:35:08Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.435</ele>

<time>2008-01-13T17:35:09Z</time>

</trkpt>

<trkpt lat="53.194831" lon="-6.128581">

<ele>55.248</ele>

<time>2008-01-13T17:35:10Z</time>

</trkseg>

</trk>

</gpx>

Edited by AlunS
Link to comment

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 :laughing:

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!

Link to comment

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!

I updated my above post with some more data. unfortunately it only serves to confuse the matter, I'm afraid!

 

I've looked at the document defining the Garmin PVT protocol on their website, and apparently the altitude information is transferred in metres as a 32-bit floating point number during track download, so no real excuses there.

 

I can't explain why they would save the internal GPX track to 3 decimal points and then transfer the track log as a floating point number and then truncate / round it to 0.5 metres .... strange.

 

Also, if I use OziExplorer or GPS Utility to record my current position in real time, rather than downloading a track log it seems to have a much finer granularity (both programs only display to one decimal place, but there are points with, say, only 0.1m difference in altitude, so the 0.5m granularity definitely isn't there).

 

My head hurts!

Edited by AlunS
Link to comment

HCX with the newest 2.6 firware.

 

I just went on a quick 5km hike (3 mile?) with 3 steady hill sections. acording to both the graph on the HCX, and the track profile in mapsource. the first section was about 370 feet (lowest valley to highest peak), the 2nd was 90 feet, and the 3rd 150 feet. for a rough guess of 610 ft. my total assent said 646... so mine seemed fine on that walk.

 

I didn't pay any atten to the vertical speed. I'll have to do that next time I guess. but surly you can bike faster then I can walk!.

 

what program are you using to make a graph of the total assent?

Edited by Smac999
Link to comment

I updated my above post with some more data. unfortunately it only serves to confuse the matter, I'm afraid!

 

I've looked at the document defining the Garmin PVT protocol on their website, and apparently the altitude information is transferred in metres as a 32-bit floating point number during track download, so no real excuses there.

 

I can't explain why they would save the internal GPX track to 3 decimal points and then transfer the track log as a floating point number and then truncate / round it to 0.5 metres .... strange.

 

Also, if I use OziExplorer or GPS Utility to record my current position in real time, rather than downloading a track log it seems to have a much finer granularity (both programs only display to one decimal place, but there are points with, say, only 0.1m difference in altitude, so the 0.5m granularity definitely isn't there).

 

My head hurts!

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.

Edited by Hertzog
Link to comment

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.

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 :unsure:

RE: "Elevation Granularity"

 

I have the old B&W Vista. I had never really noticed the "elevation granularity", because I use my GPSr in metric units, which tends to cloud the issue a little (because it only displays elevation to whole metres, although downloaded track-logs show higher precision), but on closer examination:

 

ALL elevations which are saved in track-logs etc definitely show "granularity". What is interesting is that the recorded granularity is always either EXACTLY 1.5 feet OR 1.6 feet - never anything else; with a bias towards 1.6 feet (i.e. more 1.6 feet increments than 1.5 feet increments).

 

This is not really consistent with the hypothesis that the hardware is calculating in increments of 0.5 m (= 1.6404 feet, NOT 1.5752 feet!), because this would suggest increments of either 1.6 feet or 1.7 feet when converted to decimal feet (with one decimal place). I can't really explain the algorithm which is actually being used.

 

For example, elevations in the track-log files can be any of the following, but apparently NEVER anything else:

 

...

35.1'

36.7' (1.6')

38.3' (1.6')

39.9' (1.6')

41.5' (1.6')

43.0' (1.5')

44.6' (1.6')

46.2' (1.6')

47.8' (1.6')

49.3' (1.5')

...

 

These elevations do not really make a logical sequence when converted to metres - there is no clear evidence that the "native" elevation which is being calculated in the hardware is a rational fraction of a metre, which is then being converted and / or rounded.:

 

...

10.698

11.186

11.674

12.162

12.649

13.106

13.594

14.082

14.569

15.027

...

 

It's all a bit academic - I certainly don't trust my Vista's elevation to 0.5 m precision (it only displays to whole metres anyway), but there is clearly some strange stuff going on deep in the bowels of the processor!

Link to comment

HCX with the newest 2.6 firware.

 

I just went on a quick 5km hike (3 mile?) with 3 steady hill sections. acording to both the graph on the HCX, and the track profile in mapsource. the first section was about 370 feet (lowest valley to highest peak), the 2nd was 90 feet, and the 3rd 150 feet. for a rough guess of 610 ft. my total assent said 646... so mine seemed fine on that walk.

 

I didn't pay any atten to the vertical speed. I'll have to do that next time I guess. but surly you can bike faster then I can walk!.

 

what program are you using to make a graph of the total assent?

 

Hmmm... interesting.

 

Not clear that I can bike uphill faster than you can walk. When you're fighting gravity, walking or cycling doesn't make that much difference (except for the extra weight of the bike!). In fact, when the hill is steep enough that I can't balance, so I walk, I walk about as fast I was cycling.

 

I use a homebrew excel spreadsheet to make the plots.

 

- Ed

Link to comment

groth .. any news from Garmin on this one yet?

 

Well, the latest was, I can send back the unit for a replacement or perhaps its a glitch in the firmware. I said I was almost positive it's a glitch in the firmware and I hope he can get some engineers to work on it. The answer was OK, sorry for the inconvenience.

 

So, I really don't know if they are acknowledging the problem or just ignoring it.

 

However, I thought of another test I will do. It turns out I can drive essentially the same route as I cycled (about 1 or 200 yards were on a path that I can't take my car on, but I can go on a parallel road). So for this, I should be able to get much faster vertical speeds.

 

I thought it would also be good to take my Vista C along for the ride.

 

- Ed

Link to comment
Well, the latest was, I can send back the unit for a replacement or perhaps its a glitch in the firmware. I said I was almost positive it's a glitch in the firmware and I hope he can get some engineers to work on it. The answer was OK, sorry for the inconvenience.

 

So, I really don't know if they are acknowledging the problem or just ignoring it.

What a strange reply! Well, it's highly unlikely it's a hardware problem, seeing as the altimeter itself would appear to be perfectly OK. It sounds like a similar problem to the problem with the odometer to me, i.e. only registering ascent when over a certain speed (not sure whether this is horizontal speed or vertical speed). In which case it's a firmware problem.

 

Either way, it'd be a trivial thing for them to test for themselves.

 

However, I thought of another test I will do. It turns out I can drive essentially the same route as I cycled (about 1 or 200 yards were on a path that I can't take my car on, but I can go on a parallel road). So for this, I should be able to get much faster vertical speeds.

 

I thought it would also be good to take my Vista C along for the ride.

Sounds like a good test. If the height gain is more accurate when in the car as opposed to when you're cycling that would tend to point to vertical speed being an issue.

Edited by AlunS
Link to comment

Sounds like a good test. If the height gain is more accurate when in the car as opposed to when you're cycling that would tend to point to vertical speed being an issue.

 

OK, I did the test and just sent the following email to Garmin. We'll see what happens - Ed

 

Please let me know if anyone is working on this problem.

 

I ran another test.

 

Recall, I hypothesized that there's a threshold problem in computing the total ascent in a Vista HCx (that is, when the vertical velocity is less than some threshold, it's set to zero and the altitude gain is not added to the total ascent).

 

So, I went for a drive covering essentially the same 40 mile route as my two previously reported bicycle rides. (The only difference, is about 200 yards in the town of Lambertville, NJ, that I cycled on a path, but drove on a parallel road. However, this is all flat and should make no difference to the total ascent. It's part of the flat minimum altitude part just before mile 20 in the plots below.)

 

I also took my Vista C.

 

Both units were altitude calibrated and reset at the beginning of the drive.

 

Since my car can go uphill much faster than I can bicycle, the hypothesis would say that there should be a bigger total ascent when driving than when cycling.

 

The summary is (units are feet):

 

HCx C

Total Ascent

From Unit 1391 2246

From Track Log 2238 2224

 

Total Descent

From Unit 1361 2380

 

For the case of driving, the HCx is computing about twice the total ascent that it did for cycling (recall, about 600 feet). This is still way less than what the C computes or what is computed from the track log. Note that the C and the track log computations agree.

 

There is definitely a problem in the HCx.

 

Some photos and data:

 

The pair of receivers at the end of the drive (after they've been removed from the car and taken in the house):

 

Drive_20080122.jpg

 

The altitude and total climb (ascent) profiles from the track log of the HCx:

 

Drive_20080122.gif

 

The altitude and total climb profiles from the C's track log:

Drive_20080122C.gif

 

The track logs and profiles are essentially the same and agree with what the C computes for the total ascent. What's different is what the HCx computes for the total ascent.

 

Thanks,

Ed

Link to comment

Either way, it'd be a trivial thing for them to test for themselves.

The Garmin engineers are in Olathe, Kansas. The topography in Kansas means that it is not trivial to test altitude gain problems there. It would be quite difficult.

That's a bit like saying "all the roads around here are straight and have 35 mph / 60 km/hr speed limits, so we aren't able to test the unit on irregular tracks and/or at varying speeds"!

 

Surely any company which manufactures GPSrs which are designed with topographical map capability has a test regime which allows such capabilities to be tested?! :huh:

 

Maybe they should consider relocating to Colorado where they have some real terrain (or perhaps Nepal)? :D

Link to comment

Either way, it'd be a trivial thing for them to test for themselves.

The Garmin engineers are in Olathe, Kansas. The topography in Kansas means that it is not trivial to test altitude gain problems there. It would be quite difficult.

That's a bit like saying "all the roads around here are straight and have 35 mph / 60 km/hr speed limits, so we aren't able to test the unit on irregular tracks and/or at varying speeds"!

 

Surely any company which manufactures GPSrs which are designed with topographical map capability has a test regime which allows such capabilities to be tested?! :huh:

I'm sure they do. But it would not be as trivial as taking a bike ride up several steep hills would it?

 

Maybe they should consider relocating to Colorado where they have some real terrain (or perhaps Nepal)? :D

Again, that is most definately not a trivial solution.

 

"Trivial" is the key word here. It is not trivial for them to test altitude gain problems under real situations where the problem would show up such as walking or biking at slow speeds up/down large elevations. That doesn't mean they can't test them, but that instead of looking for them to find a solution in a couple of weeks, you would need to allow them several months at least.

Link to comment

OK - in answer to that question, I received the reply that the engineers are aware of the issue and plan to release a software update in the future (but no date known).

Your wishes have been answered ...

 

Changes from version 2.50 to version 2.60:

 

* Correct German translation of 'delete all waypoints'.

* Fix data card unlock failure when 2 cards of the same map set are used in one device.

* Improve sun times for polar regions.

* Fix issue where ETA in non motor vehicle modes can be unreasonably short.

* Increase precision of distance measurement to the cursor on the map page.

* Allow backlight adjustment on the track back point selection page.

* Fix shutdown when editing Estonian Grid coordinates.

* Correct daylight saving time for New Zealand.

* Improve selection of the names of cross roads with NT maps.

* Correct potential shutdown when viewing a vertical profile.

* Correct European word translation of 'Find' and 'Mark'.

* Support multiple languages in American version.

* Fix screen fading issue in cold temperature.

* Correct total ascent calculation.

* Correct direction symbol of vertical speed.

* Fix reboot issue of GPS firmware update.

* Correct battery issue of lithium battery.

Link to comment

OK - in answer to that question, I received the reply that the engineers are aware of the issue and plan to release a software update in the future (but no date known).

Your wishes have been answered ...

 

Changes from version 2.50 to version 2.60:

 

* Correct German translation of 'delete all waypoints'.

* Fix data card unlock failure when 2 cards of the same map set are used in one device.

* Improve sun times for polar regions.

* Fix issue where ETA in non motor vehicle modes can be unreasonably short.

* Increase precision of distance measurement to the cursor on the map page.

* Allow backlight adjustment on the track back point selection page.

* Fix shutdown when editing Estonian Grid coordinates.

* Correct daylight saving time for New Zealand.

* Improve selection of the names of cross roads with NT maps.

* Correct potential shutdown when viewing a vertical profile.

* Correct European word translation of 'Find' and 'Mark'.

* Support multiple languages in American version.

* Fix screen fading issue in cold temperature.

* Correct total ascent calculation.

* Correct direction symbol of vertical speed.

* Fix reboot issue of GPS firmware update.

* Correct battery issue of lithium battery.

 

Thanks for letting me know!

 

We shall see, I've updated the software (so it's 2.60/2.60). Now the weather has to cooperate so I can do a test!

 

- Ed

Link to comment

Thanks everyone for all the information. Now that Garnin says they have corrected the Total Ascent calculation I am hoping that someone with a Vista HCx could test to see if that is truly the case.

 

Thanks

 

You can bet we will!

 

I hope to get in a bike ride this weekend to give it a good test.

 

On Wednesday, I took it in the car on the way to work. about 8 miles of driving and a quarter mile walk from the parking lot. It gave 360 feet of total ascent; analysis of the track log gave 330 feet. (It's a relatively flat route!). So the first test is promising, but a more challenging test is required!

 

- Ed

Link to comment

Thanks everyone for all the information. Now that Garnin says they have corrected the Total Ascent calculation I am hoping that someone with a Vista HCx could test to see if that is truly the case.

 

Thanks

 

You can bet we will!

 

I hope to get in a bike ride this weekend to give it a good test.

 

On Wednesday, I took it in the car on the way to work. about 8 miles of driving and a quarter mile walk from the parking lot. It gave 360 feet of total ascent; analysis of the track log gave 330 feet. (It's a relatively flat route!). So the first test is promising, but a more challenging test is required!

 

- Ed

 

Today, I waited until the snow stopped and went for a bike ride.

 

The Vista HCx at 2.60/2.60 reported 2137 feet of climb while my analysis of the track log gave 2243 feet. This is about as close as it gets. With previous receivers (Summit, Vista, Vista C) the receiver and my analysis would agree to 5-10%.

 

So I think the problem is fixed.

 

It's much more pleasing to crank up a hill and have the total ascent go up rather than just sit there!!!

 

- Ed

 

Ride_20080209_profile.gif

Link to comment

The Vista HCx at 2.60/2.60 reported 2137 feet of climb while my analysis of the track log gave 2243 feet. This is about as close as it gets. With previous receivers (Summit, Vista, Vista C) the receiver and my analysis would agree to 5-10%.

My Vista HCx reported 748m of climb on my hike yesterday which seems to correspond roughly to what I was expecting (just looking at the map, the major climbs added up came to about 700m).

 

I've tried many different pieces of software from the Internet to analyse the track logs, but they all seem to wildly overestimate, presumably because there's little smoothing going on, so any noise in the elevation data plus the fact that were I am, the terrain is extremely uneven (it's those peat hags again).

 

The closest match I got was from a piece of mapping software I use produced by the Irish national mapping agency, which I suspect uses accurate local DEM data to calculate total ascent from tracks rather than the GPS data and that came up with 739m, which is pretty good.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...