groth

I believe my wife gave me an eTrex Summit for my birthday, May 13, 2001. The earliest track log I have saved in my files of track logs is from May 31, 2001. - Ed

Hmmm.... I have a summit, a vista, a vista C and now a vista HCx. All have a barometric altimeter with the little hole in the back that leads to the pressure gauge. Never noticed a problem with the wind. However, I did get water on the little hole once. Not surprisingly, I got bogus altitude readings until it dried out. (No, I didn't drop it in the toilet, it was on my handlebars on a fast downhill in the rain!) If you like, you can email your track log and I'll try and see what my software gives for the total ascent. groth at princeton dot edu - Ed

I taught a freshman seminar: "Where's Waldo: the Science and Application of GPS" in the spring semesters of 2004, 2006, and 2007. The course web page for the latest is here: FRS142 Since this course fulfilled a lab requirement, we collected data with the GPS units and analyzed it with excel. Each student was required to have a GPS receiver and a way to read it into their laptop. Freshman physics textbooks are getting to be well over $100 with limited resale value as the textbook publishers bring out new editions as fast as they can to kill the used book market. This course did not have a textbook; students found readings on the web and I lectured occasionally. Since they didn't have to buy a textbook, I figured it was not unreasonable to have them buy a GPS receiver. I steered them to the Garmin eTrex line and told them that the basic receiver would be fine (and they would need a cable to connect to their laptop). It was up to the individual student if he or she wanted a fancier model as long as it was in the eTrex line. Turns out the students weren't put off by this requirement at all. Some bought Vistas, some found the basic eTrex on ebay, etc. They searched the web for the best prices. Some sold theirs when the course was over. In 2004, all the students had windows laptops with serial ports. All the eTrex's had serial outputs. There was free software to do all the uploading and downloading. I had a Mac, but I had purchased a serial to USB adapter and MacGPSPro software, so I was good to go. By 2007, many of the eTrex models had only USB ports and some windows machines were losing their serial ports in favor of USB ports. Also many students had Macs. Since students were getting new receivers with USB ports as well as used receivers with serial ports, this made a lot of combinations to get working. I think in the end there were one or two that couldn't get their receivers to talk to their computers. So I eventually just had them share computers and help each other out. One thing I miss about the USB receivers is the lack of NMEA output. This provided a lot of data and the data stream looks very similar to satellite telemetry in the way the data are commutated. I don't know if having the students buy the GPS units is applicable to your situation; if so, it might be an easy way to solve the problem! - Ed

About 9 mph.

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

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

As the previous reply said, you can't. However, I'm guessing you want to see the GPS elevation because the barometric elevation will be wildly inaccurate inside the pressurized cabin. From the satellite page, press the menu key (lowest button on left), then pick the GPS elevation menu item. Or From the altitude page, press the menu key and choose calibrate altimeter. When it asks if you know the correct elevation, say no. When it asks if you know the correct pressure, say no. If it has a lock that allows it to know the GPS elevation, it will then ask if you want to use the GPS elevation and display it at the bottom of the page. (The first method is easier!) - Ed

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

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). - Ed

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): The altitude and total climb (ascent) profiles from the track log of the HCx: The altitude and total climb profiles from the C's track log:  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

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

No they don't. There is room allocated in internal memory for 10000 active track points and 20x500 saved track points. Using one does not affect the space for the other. You are right. I stand corrected. - Ed

Some of the other answers here have suggested getting a memory card. It is certainly true that if you don't have enough space, you need a memory card. However, without a memory card, the saved tracks and the active track are sharing the space, so you don't gain much by saving a track. You gain a little because the saved tracks don't have the time stamps. When the tracks are uploaded with time stamps, you can use an editor to break them into separate files by looking at the time stamps. If the time stamps won't be enough to tell you where to break the log, just turn the unit off and then back on. This will leave a blank line in the track log. There is probably a header that you want to replicate in each file you make. (I'm a Mac user and use MacGPSPro for uploading the tracks, YMMV.) - Ed

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

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

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

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 below has one bogus point just before mile 20 (from turning the unit back on after lunch). 

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

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). I bigger view so you can read the total ascent (upper left field of both screens): 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. The next plot is a plot of altitude vs time for both receivers from the track logs. They agree very well! 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

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 just sent the following to Garmin customer support: Here is the plot I referred to above: 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