How Many Miles in my track?

I've just done an experiment on a track created on my Etrex on 27 December. I normally delete all my tracks so checking others isn't possible.

Original track was 4.2 miles. I then loaded it into BC and deleted a point, mileage changed to 4.7 miles. Looking further at the tracks, I knew that at one point my Etrex had shut down, and as we were walking quite quickly it took a while to reacquire a signal. That distance (measuring it in Basecamp) was the 'missing' .5 miles.

So based on that this is my theory. The measurement on the Etrex (and I assume other GPS) is only the distance measured while it has a satellite lock. If it loses it for a bit then that distance isn't counted, but it is when Basecamp is forced to recalculate.

If you loose a lock on the sats from the GPS by shutting it down or other reason the GPS and BaseCamp will both use the straight lint distance between losing the lock and getting it back. While this mileage will be wrong it's understandable and not the fault of the GPS. The mileage on the GPS and BaseCamp should be the same as they would both include the straight line. To prove this you can power it up at home and clear the track and then turn it off. Then drive somewhere turn it on and do a walk. Then check the mileage and it will include the Mileage from home in a straight line. I think the .5 miles is the bug and not because of the shutdown.

Well I agree it has nothing to do with the shutdown. What I'm saying is that they both show the straight line, but it seems my Etrex wasn't counting it yet Basecamp was once it was forced to. I know full well that you can get straight lines between home and start point and indeed finish point to home if you don't clear current track at the beginning and then save current track at the end of the walk. However this section was in the middle of the track, and it's too much of a coincidence IMO that the distance when I didn't have a lock equals the 'missing distance'. It also explains why I've never seen it before as I can't ever recall an instance when I've had my Etrex shut down 'mid walk'.

It is a coincidence that the mileage is the same when you didn't have a lock as the missing mileage. The only point I was trying to make turning it off at home was to get a long straight line so it would be easy to see that it is included. All it knows is it recorded a point and later recorded another and will add the straight line distance between them.

If you look at the mileage on the GPS at the end of the walk at the same time you save the track it will be the same. After forcing BaseCamp to recalculate you will get a different correct number. When the error was so bad that there was no doubt it was wrong I could see the mileage was wrong before the end of the hike so it's getting off before it's saved and not being corrupted during the save process.

This is from Garmin Tech Support "I have seen exactly what you are talking about with your tracks and distance. Currently the only work around for what is shown in Basecamp is to delete a point."

When you open a gpx file with a track log from the eTrex in a text editor, does it contain a section with the tag <gpxtrkx:TrackStatsExtension>? I assumed that only the Or6x0 and the GPSMAP64 did this, but apparently I was wrong...

When you open a gpx file with a track log from the eTrex in a text editor, does it contain a section with the tag <gpxtrkx:TrackStatsExtension>? I assumed that only the Or6x0 and the GPSMAP64 did this, but apparently I was wrong...

Yes it has that section. However looking at my old files it didn't in the past. That is most likely why the older files were not a problem.

Ah, then it must have been added recently. Can't find anything about it in the change logs though...

This extension was added to the 62 (and presumably 78) series as well. The statistical data in the GPX file appears to come from the real-time trip computer. It also appears that a &#8220;filter&#8221; has been added to improve the accuracy of trip distance for slow movement, although it may no longer be there.

An illustration of how it might work is as follows: maintain a stack of the current and previous position; calculate the distance and compare to a value to determine if movement is likely (our units will almost always indicate movement); if moving, then add the distance to the trip distance and 1 to the moving time (position updates every second); if not moving, then add 1 to the stopped time.

Now a decision must be made on what to do with the stack under error conditions (lost lock) and when no movement detected. For no movement, the decision to be made is whether to replace the previous position with the current position or just throw out the current position. I suspect the former. I&#8217;ll let you make your own guess on what to do when lock is lost. Keep in mind that this is just an illustration of how things might work and not how they actually do work.

A similar filter was in BaseCamp at one point, but I do not know if it is still present. If your interested, collect a stationary track (i.e. set your device down somewhere and just let it sit for a while). Make sure your unit isn&#8217;t logging data every second &#8211; set it to auto or something like 4 sec intervals. Look at the track in BaseCamp with and without deleting a point (also in MapSource if you have it - no such filter exists) and compare the distance (also look for changes in the stopped/moving times in BaseCamp).

I agree that the statistical data in the GPX file appears to come from the real-time trip computer.

I tried your test and had my etrex 20 setting here not moving for 38 minutes. It showed 0 ft. After loading it in BaseCamp and forcing a recalculation it shows 345 ft. So it looks like you are correct that there is a filter. If the filter was the problem I would expect any error to be in the same direction always low. This was in my house so not the best of conditions to get an accurate fix so I would expect less of a difference out in the open. At this rate of 345 ft filtered out in 38 minutes it would take days of no movement to get some of the errors I'm seeing.

I have carried 2 GPSs on the same hike so any lack of movement lock loss etc. should be close to the same. I would expect numbers to be close to the same. One shows 6.9 miles and after deleting a point 7.7 miles, the other one shows 8.2 miles and after deleting a point 7.5 miles. I can understand the .2 mile difference this could be as small as .11 miles do to rounding and I think that's good accuracy. Both files look good no reason to think there is a problem. I looked at them for no movement based on your post and found that the one that changes by .7 miles only has 2 points showing no movement and the one that changes by 1.2 miles has no points showing no movement.

Just to be clear, it is the stopped time vs. moving time that is important, not the values for leg distance in the property column (at one time BaseCamp was or still is trying to use a similar filter and thus not using all the leg distances to calculate total distance). If you are constantly moving, then the stopped will zero or close to zero and will have little affect on the total distance. Under these circumstances, it is the total number of points that become important.

Let&#8217;s say the trip computer showed no stopped time. In that case the total number of points used to determine the total distance will be the elapsed time in seconds. Now if the interval for the track log is set to anything other time 1 second, there will be far fewer points used to calculate the total distance (half or fewer).

Remember, that the gps system does not give absolute positions. If you were to walk a perfectly straight line the track will show you drifting to the left and right. The net result is a greater accumulation of error with more data points. In general, with no stopped time, you would expect to see a shorter distance with fewer data points. As long as no curves are cut off, then fewer points will likely be a more accurate estimate of the distance covered.