How Many Miles in my track?

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’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.

I understand that there will always be some error and that a consumer grade GPS doesn't have absolute position accuracy. I also understand that the mileage could be a little high do to readings wandering or a little low do to curves being cut off.

I have a file showing 3:23:47 moving time and 0:12:38 stopped time and a distance of 15.1 miles. I Know this is wrong. It was on a trail I hike a lot and know well and I have a lot of tracks of it so it would be easy for me to see any points that were way off. If I force BaseCamp to recalculate it I get 6.7 miles. The 6.7 miles is close, it could be a tenth or two off but that is understandable and I wouldn't complain.

I understand there could be some error or more likely correction do to the filter. But I don't see how this could account for 8.4 miles in less than 13 minutes of stopped time. As I said I only had 345 ft in the house where the signal shouldn't be as good in over half an hour. I think this is from something other then the filter. The filter could account for the small differences I see on the bike but that's not a problem and well within the accuracy I would consider very good.

I also tried using 5 seconds and .01 mile record methods at Garmin's request. The time file looked good the distance file was bad but both had errors.

There is another issue that I have noticed with respect to the summary statistics reported from the device. This is just a foggy recollection with respect to the current track log. It seems to me that that the total mileage is using either the first data point in the current log or perhaps the value in the meta data portion of the gpx log. Or perhaps it uses the last location prior to turning of the device as the initial location for the trip computer.

In fact, I have seen the total distance on a track of over 700 miles in the statistical header for a track that could not be longer than 20 miles. And I am not talking about a long line going back to some far away location. Simply deleting a point in the middle of the track reduced it to ca. 16 miles.

I haven’t really examined it to try and figure out what is going on, nor do I know if saving the track vs. grabbing it from the current track log would make a difference. The best practice for capturing tracks you are interested in is to have your device up and running for ~ 10-15 minutes, clear the trip computer and track log just before you start and save the track when you finish. I won’t guarantee good results, but it should avoid some of the quirky results/behavior while Garmin works the kinks out of this new feature.

There is another issue that I have noticed with respect to the summary statistics reported from the device. This is just a foggy recollection with respect to the current track log. It seems to me that that the total mileage is using either the first data point in the current log or perhaps the value in the meta data portion of the gpx log. Or perhaps it uses the last location prior to turning of the device as the initial location for the trip computer.

In fact, I have seen the total distance on a track of over 700 miles in the statistical header for a track that could not be longer than 20 miles. And I am not talking about a long line going back to some far away location. Simply deleting a point in the middle of the track reduced it to ca. 16 miles.

I haven’t really examined it to try and figure out what is going on, nor do I know if saving the track vs. grabbing it from the current track log would make a difference. The best practice for capturing tracks you are interested in is to have your device up and running for ~ 10-15 minutes, clear the trip computer and track log just before you start and save the track when you finish. I won’t guarantee good results, but it should avoid some of the quirky results/behavior while Garmin works the kinks out of this new feature.

That sounds like what I'm seeing only bigger. Like you say it's not a long line going back somewhere I understand that when that happens it's operator error. The files I'm talking about look good. As you say it's not the point being deleted that's the problem I can delete any point at random to force BaseCamp to calculate the data and not use the summary data from the GPS and get good numbers.

I reset the track log at the start of the hike and save it at the end. I then load the file in BaseCamp when I get home and select all but one point. This gets me numbers that I'm happy with. I don't even bother looking at the trip computer anymore as I don't trust it anyway.

You could be correct that it's using a point other than the first one in the file to calculate distance that could explain the error. I have not seen the error on my bike, the distance will only change maybe a tenth or two. I don't consider that an error as little things like when a point is written to the file verse when the trip computer takes a reading, stopped filter etc. could enplane that. I've thought that was based on speed but it could be the fact I more likely to ride from home where the GPS has been for a day or more and/or it could be a coincidence.

I will try to get a better idea of when the error is occurring next time I hike. I know at the start of the hike it's 0 and sometime before the end the error is included. After resetting and verifying its st 0 I've never looked until later in the hike to see how far I have gone. If it's a problem with where it's starting from I would expect the error early most likely when the filter you talked about decides I'm moving.

Good luck.

I took a look at the current track log on my device and the saw that it only recorded the statistical data for the first track segment, but none of the others. The data was clearly wrong for the first segment.

So, I am not sure where the data comes for subsequent segments as it must be stored elsewhere if it exists. But, it also suggests that the order of resetting the track log and the trip computer may now be important, where as before it didn’t matter.

I usually clear the trip data and track log with the Reset Both option on my device. It may be important to Clear the Track Log AFTER clearing the Trip Data to prevent the old Trip Data from becoming part of the first track segment in the track log.

And Garmin thinks this is progress. Next thing you'll have to stand on your left leg, spin around three times to your right, then spit twice over each shoulder; all while keeping the second and third fingers of your left hand crossed. ;)

...ken...

I don't know if someone is still watching this old discussion. However, my 64s does this all the time. Last year, I returned the unit to Garmin and received a replacement. Same behavior. Yesterday I did a 12 mile hike. The GPS listed a distance of over 30 miles. When looking at speed data over distance, it registered over 700 mph speed! At several points along the route, an erroneous point adds miles to the saved track. I have to carry multiple GPSs on winter hikes to ensure I can navigate safely. Does anyone know of a solution for this issue?

For some reason, I could not attach the actual gpx file. However, here is picture of the track that shows just what the 64s is doing.

The large departures from the obvious track are the measurement errors introduced by the 64s. I do receive lots of warnings that the satellite is lost. However, I get those messages on top of mountains where the horizon is unobstructed.

Well for some reasons you're getting erroneous track points, not surprising if you keep losing satellite lock. Where do you keep your 64? I have never experienced this sort of issue with my handhelds, and I've had 3 different ones I've the years.