This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

InReach Explorer Trip Info:Trip Distance vs Share Page Dist. Traveled

I have had my InReach Explorer for just about a year now and use it frequently. I continue to have a large discrepancy between the Trip Distance in the Trip Info on the device and that shown as Dist. Traveled on share.delorme.com. For example, my last track on the device shows 10.6 miles yet the share page shows 7.76 miles. The two data sources rarely are even close to one another with the device mileage always being higher.

Which is correct? Why do they not agree?
  • Neither is actually correct. The trip information on the device is closer. The distance information is derived from straight-line distance between the available track points. Assuming that you have track logging turned on and that the logging interval is shorter than the send interval, the device trip information will be based on the logged points. So the shorter the logging interval, the closer the distance will be to reality. MapShare, on the other hand, only has the sent points available. These are much farther apart in both time and distance, meaning that the straight lines between them do not approximate your actual path very well. So the distances shown there are shorter.
  • A great deal of the difference might be explained by the amount of information known to the web account vs the inReach device. The device measures all the "wiggles" along the path, whereas the web site can only total up the distance between sent track points. The sum of several straight lines will be less than the length of the continuous wiggly line.
  • So I have logging set at 1 min and 10 mins. I would expect the web site to be very inaccurate until I sync so the web site has the 1 minute intervals. Even then it is way off. Very frustrating.
  • Trip distance vs share page distance vs other means of measuring

    Tom and Bob are quite right - the distances displayed on various devices will always disagree, sometimes by large amounts. And the reason that Bob gave is correct. For example, I went for a long bike ride yesterday in an area of winding roads. Since I wanted to know the distance of the route I traveled, I had my Polar 800 (GPS watch with heart rate monitor), Delorme PN60 (GPSr that has fixed 10 second intervals), a Cateye bike odometer/speedometer (adds up rotations of the bike wheel), and my inReach+. Since the route I picked had a section with multiple switchbacks (a hilly region of the Santa Cruz Mountains on the San Francisco Peninsula), all 4 gave different results.

    I tend to think the Cateye gives the most accurate results since it measures the distance on the road that the tire rolls. I have the inReach set to log interval 5 sec and the Send at 5 min. On a straight-line road, I would expect that the PN60 and inReach log would be fairly close together since both are marking at the same 10 second interval. However, on a road with many switchbacks or an in-town route with many turns, a pair of consecutive log points at 5 sec for the inReach and 10 sec for the PN60 to pick points as if the PN60 is skipping alternate marks. On a steep switchback, the distance for the short interval can be 5 or 6 times the distance for the long interval (straight line road should be the same, but doubling back so the uphill point is only a short distance away from the twice as long timewise 10 second interval).

    Draw a series of switchback loops and place the points in the middle of each horizontal traverse to get an idea of how the switchbacking makes the actual traveled distance longer than the 10 second recorded distance.

    Did the same route this morning to get a comparison - The PN60 gave 15.88 miles, the Cateye gave 15.96 miles (as expected, slightly longer since the Cateye is doing the wheel distance on the road and the PN60 is doing a series of straight lines). Earthmate gave 15.71 miles - as expected slightly shorter than the PN60 10 second intervals. The Polar800 has a somewhat longer marking interval, so gets a shorter distance (14.94 miles) on the 2 sections of the route that have numerous switchbacks.

    I sent Bob my MapShare from today - set the filter as 6/21/2017 6AM to 6PM.
  • WRT accuracy, two bounding cases: Perfect circle and perfect straight line.

    Circle
    1. Diameter = 20 ft
    2. Walk circumference while recording @ 12, 3, 6, 9 and 12 o'clock.
    3. The unit will calculate the straight line distance between 12 and 3 as 14.14 feet.
    4. The total of the 4 segments is 56.56 ft. (Note: zero error in the GPS readings is assumed).
    5. The true circumference of the circle is 62.83 ft.
    6. As the frequency of readings is increased, or the distance between them is decreased, the sum of the shorter straight line increments will approach the true circumference of the circle.

    Straight Line
    1. Walk a straight line of 1,000 ft while recording every 100 ft.
    2. The recorded sum will be greater than 1,000 ft due to errors in the GPS readings.
    3. Unexpectedly, the sum of the errors will increase (rather than decrease) as the increment of the distance between readings goes down (or, as the number of readings goes up).

    Note: As I expect most to assume that the smaller bites lead to better accuracy as I did initially. However, as I worked out the analysis, I did find the reverse to be true.
  • CS certainly has a valid point regarding positional error in general. The straight line example is an extreme case. It's wrong to say that it exaggerates the accumulated error. What it does do, though, is to completely eliminate the effects of the errors introduced by taking distances along chords rather than along the curved path. With a curved path, there is a (completely unpredictable) "sweet spot" which balances the improvements obtained by taking shorter chords against the larger cumulative distance error introduced by more frequent samples. In real world off-road scenarios (non-straight-line paths), you are still likely to get more nearly accurate results from shorter intervals - at least to a point. Depending on your speed of travel and the nature of the path (see the switchback example), 1 minute intervals are likely not short enough to get markedly better results.

    With the inReach devices, there is a definite trade-off between the fidelity of the track (and the associated distance) and battery life. The inReach shuts down radios whenever possible to conserve battery life. A logging interval of 30 seconds or less causes the unit to keep the GPS radio on at all times. This eats into battery life. I believe you get a warning to that effect when you set a logging interval of 30 seconds or less. Still, I've found that I need a logging interval of 2 to 5 seconds to get good track fidelity (a track which matches aerial imagery fairly well). Even then, the distances aren't very accurate. Perhaps because I'm logging more frequently than that hard to find sweet spot?
  • Regarding perfect straight lines in my post above, I should have been more explicit and stated: The cumulative errors are unexpected and counterintuitive.

    1. I made some quantitative, statistical simulations for two sets of straight line trips, both having identical total distances of 200 ft and identical average GPS errors,
    1a. Set A: One logging interval of 200 feet (record location a start (0 ft) and finish (200 ft)),
    1b. Set B: Two logging intervals of 100 feet (record location a start (0 ft), an intermediate (100 feet), and finish (200 ft)),
    2. The possibly unexpected and counterintuitive results are:
    2a. The distance errors for both the 100 and 200 ft intervals are positive, and
    2b. The cumulative error for Set A (one interval of 200 ft) is less than that for Set B (two intervals of 100 ft).
    quantitative,
    3. Allow me to restate that these errors, generated during straight line tracking are due to GPS device and methodology inaccuracies.

    Furthermore, I agree with Tom above that the errors discussed with non-perfect straight line tracks are due to geometric assumptions as the tracking device will sum up the straight line logging distance intervals as approximations of the exact non-straight, curved track actually traveled.
  • Pure speculation on my part, but I suspect that the errors in the straight-line-track distance will always be positive. This is because the vast majority of the erroneous locations will be "off the line". So they will always add distance, never subtract it. That's also the reason for larger accumulated errors with additional samples. You're accumulating more "off the line" excursions. In fixed circumstances (for example, no significant variation in the GPS constellation over the length of the test), there is no reason to expect the position error to be quantitatively different because there are more samples.

    I do agree that the accumulation of error with more samples is counter-intuitive. It's hard to visualize the effect on track length of what are essentially random excursions off the intended line. Best I can do is to hypothesize that the distribution of the erroneous locations is such that points on opposite sides of the intended line are equally likely. So in the limiting situation, you're zig-zagging back and forth across the intended line. Clearly, the more often you zig-zag, the larger the accumulated error. Even if you don't cross the intended line, it's highly unlikely that consecutive samples will lie on a line parallel to the intended line. So each one contributes additional error. But I'm far from satisfied with either of those. Hate it when I can't visualize an effect which clearly exists :mad:
  • My Last Gasp

    CHARACTERIZATION OF STRAIGHT LINE TRACKING ERRRORS

    Background
    1. At the same location in my backyard, I recorded 50 waypoints over a several week period about a year ago.
    2. I cited these onto an Excel spreadsheet and averaged the lat and lon data.
    3. I plotted the data points and their centroid on a chart.
    4. As expected, about 1/2 were above an EW axis through the centroid and the rest were below.
    5. Similarly, about 1/2 were to the left of a NS axis through the centroid and the rest were to the right.
    6. I calculated the radial distance of each point from the centroid and then the average of the radial distances.
    7. Assuming the centroid to be true location of my GPSr, these data represented the 50 errors and their average.
    8. I arbitrarily assigned negative values to those points W of the NS axis.
    9. I then tabulated them incrementally as how many were in each 2 ft increment of distance radially from the centroid.
    10. Again and as expected, the shape as that plotted tabulation was characteristic of a normal distribution with the median, or max frequency, at the centroid.
    11. Consequently, I calculated the standard deviation as the typical ± value.

    Error Analyses
    1. I've attempted to keep my scenario quite simple in order to keep it digestible but also reasonably consistent with psuedo-random statistical reality.
    2. As a result, I am limiting to 4 discrete errors: (1) 5 ft due N of centroid, (2) 5 ft due E, (3) 5 ft due S, and (4) 5 ft due W.
    3. I have to separate analyses, one for the two NS errors only and the other for the two EW errors only.
    4. Both analyses will consider the straight line track to be due N with logging intervals of 100 ft.

    NS Errors
    1. Alternating the errors between -5 ft and +5 ft, with the logging locations being 0 ft, 100 ft, 200 ft, 300 ft, 400 f,, 500 ft, ......
    2. The logged locations are -5 ft, 105 ft, 195 ft, 305 ft, 395 ft, 505 ft, ....
    3. The GPSr calculated intervals are 110 ft, 90 ft, 110 ft, 90 ft, 110 ft, ....
    4. The summed locations are 110 ft, 200 ft, 310 ft, 400 ft, 510 ft, ...
    5. The cumulative errors are 10 ft, 0 ft, 10 ft, 0 ft, 10 ft, ....
    6. Repeating by alternating the errors between +5 and -5 with all else the same,
    7. The cumulative errors are -10 ft, 0 ft, -10 ft, 0 ft, -10 ft, ......

    EW Errors
    1. Alternating the errors between -5 ft at logging location 0 ft, and +5 ft at logging location 100 ft,
    2. The GPS calculated distance is the hypotenuse of a right triangle with legs of 10 ft and 100 ft.
    3. That length is 100.125 ft for an error of 0.125 ft, or 0.12%.
    4. Same analysis with a logging interval of 50 ft for an error of 0.25 ft, or 0,50%.
    5. Same analysis with a logging interval of 200 ft for an error of 0.25 ft, or 0,03%.
    6. Regardless of distance logging interval, the error for each consecutive adds such that the cumulative error continually grows.
    7. Note that as the interval doubles, the error per interval reduces by 1/2 while the % error reduces by 1/4.
    8. This is the counterintuitive aspect where by shortening the logging interval decreases total accuracy for tracks of perfectly straight travel.

    Conclusions
    1. While individual errors in he direction of travel are larger than those to travel, they are limited as they don't accumulate.
    2. Consequently, while initially smaller, the sum of the normal errors will eventually exceed those in the travel direction.
    3. As a result, the overall sum of errors will be expected to be positive.
  • Your rocket scientist is showing, Slim ;) Thank you!