Distance travelled InReach Explorer vs Forerunner 945

Yeah, this is a pretty bogus reply, that the device will report incorrect information unless i change some settings.  I changed some settings and did not see any improvement.

Anyway, thanks for confirming that the device will report incorrect information.  That's the answer i got from phone support, too.

I understand how the distance can be reported shorter.  I could walk out 5 minutes and back to start between track points, and see 0 traveled.   So, Yes, Garmin-Andrew's response IS correct for that case.  Shortening the time between points would give better accuracy for the case where the trail is not a straight line.

But how can i be seeing LONGER distances than actual?  And higher speeds than i could ever walk?  I don't see how topology or settings can account for that.

Yesterday i went for a walk and the distance traveled was pretty good (as it is occasionally), but moving time was only 3 minutes out of the total two hours.  We didn't walk 4 miles in 3 minutes.   Yet the average speed was reported at 4.5 mph, which doesn't work with either the 2 hours actual or the 3 minutes reported moving time, nor can we walk that fast in snow. 

My old eTrex reported the correct info.

Last year Garmin Support told me the issue is caused because the InReach gets its position information from the Sat Phone system, which is not as accurate as GPS.   I expressed some doubt :)  They didn't care.

I got the device for Christmas , but didn't get around to really checking it out until March.  Although REI agreed it needed replacing, i was past their 90 days guarantee.

And Garmin Support doesn't care.

The straight out and back case was not what I was referring to. That should not report zero. It should accurately report a total of twice the "out" distance (since the "back" distance is equal to the "out" distance).

The best way to think about straight lines vs. the path actually travelled is to visualize a path that is a large half-circle. Call the actual distance along the half-circle X. Now visualize 4 points equally spaced along the half-circle - one at the beginning, one at the end, and two more equally spaced in between. (Assumes you are walking at a constant speed.) Connect the 4 points with 3 lines. The lengths of those 3 lines will be less than X. That smaller distance is what the GPS would report (in ideal conditions) when you walk the path but only log points at relatively long intervals.

Now suppose that you log points twice as often. Now you have more (but shorter) line segments. The sum of those lengths is what the GPS will report with shorter logging intervals. Still less than X. As you continue to shorten the logging interval, you get more and more shorter segments. Each decrease in the logging interval results in a better approximation of the actual path travelled. So that the reported distance approaches X more closely.

I cannot account for the short moving time on a two hour walk. Maybe poor fix? Or maybe there really is a problem with your device. What was the maximum speed that the device reported?

The reason I ask about maximum speed has to do with GPS performance in challenging conditions (for example, at the bottom of a canyon, near high bluffs, or whatever). These conditions can lead to a phenomenon called multi-path reception. Without getting into the gory details, the resulting track frequently shows a spider-web pattern. The "threads" in the web represent errors by the GPS due to the conditions. Each thread represents an essentially instantaneous change in calculated position. It is not unusual to see threads several 10s or even 100s of yards long. The net results on the recorded statistics for the trip are (a) very high maximum speed and (b) excessive distance travelled. Usually also results in higher than expected average speed.

Average speed on a GPS is not calculated the way we all think it should be. It is calculated by computing the average of the speeds recorded for each of the track-point-to-next-track-point intervals in the trip. Each segment has its own distance and elapsed time - which is used to calculate the speed for that segment. Then the results are averaged for all segments.

In particular, this NEVER exactly equals total distance traveled divided by either time moving or total time. Ideally, it will be close to total distance traveled divided by moving time. But things like multi-path conditions can throw this off considerably.

Multi-path is the usual reason for reported distances MUCH longer than the actual distance traveled. Smaller errors tend to result from cumulative errors in position. Typical single system (GPS only, vs. GPS with GALILEO or GLONASS or whatever) is on the order of a few meters. Since the total reported distance is the sum of the lengths of the individual point-to-point segments, cumulative results of many small errors in position can result in SMALL errors in the total distance traveled. Sometimes in the direction of reported distance larger than actual distance. This is definitely a secondary effect. The errors usually "average out" over the trip so that the resulting total error is very small. Nobody thinks anything of it when reported distance is a bit too short. But everybody notices when it is a bit too long.

No matter what Garmin support told you, the iR satellites have nothing to do with computing position. That's all on the GPS satellites. Which are the same ones that all GPS units use.

While there are lots of rational reasons for discrepancy in reported vs. actual distance, I think that your issue with time moving might indicate a problem with the unit. Try one more test. DISABLE "sending" track points via inReach. But continue logging track points. Make sure you have a fix before you start moving. Take a walk of at least half a mile, moving at all times. A half mile would typically take anywhere from 15 to 30 minutes, depending on how fast you walk. Before you stop recording track points, look at the moving time statistic. It should be roughly equal to the total time you walked.

If it is NOT, open a support ticket. Describe the experiment and the result. 

Thanks for that.  I think we described similar cases.  Your case has an arc with 4 points, and the sum of the 3 chords being less than the arc distance.  My case has an arc with two coincident points, and the sum of the single chord is zero.  In each case a "point" is where the GPS took a position reading.  I'm sorry i was not clear that in my case i had the hypothetical GPS taking readings at 10 minute intervals, and so it did not notice that i walked out 5 minutes and back to start inside that interval.  (I have my actual log interval set to one minute)

The main point here is that the GPS does not notice what we do or how we travel between readings.  It can only record a total distance as the sum of the chord distances, which can only be LEQ less than or equal the arc distance.  I think the average speed could be the average of the chord speeds, or the sum of the chord distances over the moving time (it works out the same, doesn't it?)   Plus an epsilon error.  It should not be recording a distance 20% greater than the distance i walked, or a speed faster than i can possibly walk.

I appreciate your discussion of multi-path reception.  I don't believe that can be the issue here in SE Michigan - we're pretty flat.

I've seen my average trip speed reported as the same as max speed - as high as 8 mph.  

I have my "Send Interval" at 10 minutes, but this should not be relevant to my issue, right?  My "Log Interval" is 1 minute.  I think this is what determines my position points.  "Extended tracking" is OFF, and "Auto Track" is OFF.

I wonder if there is an accelerometer in there.  It could start and stop the "moving time" clock.  If there is, and it's broken, that could account for my 3 minutes moving time in 2 hours elapsed and actual walking time.

When i expressed doubt that the Iridium satellites had anything to do with positioning, and that they were only being used for comms, the Garmin Support person doubled down and insisted. 

I did essentially your suggested test on one mile of straight road before i called Garmin Support.  I did not know i could open a support ticket.  I've lost the actual data from that test.  I'll do it again and call Support again.  (I'll bet they're pretty busy this week with everybody asking how to use their new Christmas present)

Thanks again for the discussion.

Best regards

-Rick

The only reason I mentioned turning "sent points" off (no tracking via Iridium) has to do with moving/not moving time. iR devices dynamically change the send interval from whatever you set (say 10 minutes) to 4 hours when the device senses that you are not moving. Once it has set it to 4 hours, it wakes up at the previously set intervals (10 minutes in our example) to see if you have moved. If so, it changes the send interval back to what you set and goes on with life.

I really don't think sending or not sending has anything to do with measuring the issue at hand. But all that wake up stuff just adds another variable. I like to eliminate variables when possible. Plus the fact that limiting the device to only ONE interval means you know for sure what it's using. Makes it easier for the support people to duplicate the problem as well.

In my head, the distance traveled, maximum speed, average speed, etc. should be based on the SHORTER of the logging interval and the sending interval. Because the shorter one is going to be more accurate. I have no idea what happens in reality, but my anecdotal recollection is that that is true. If I send at 10 minutes and log at 30 seconds, the distance seems to be based on the 30 second intervals. To get better accuracy, you would need to log at even shorter intervals. Once you get to 30 seconds or less, many of the iR devices just leave the GPS radio on all the time. So there is very little extra battery drain between 30 seconds and maybe 5 seconds.

There IS an accelerometer in most iR devices. I honestly do not remember about the SE+/Explorer+. Even if the device has one, I have no idea if it helps determine "motion". I do know that the devices use "motion sensed from satellites" for other things. For example, devices which have an electronic compass determine heading from satellite motion if you are moving (according to GPS position) fast enough (1.5 to 2 mph, IIRC). If you are not moving fast enough, the devices use the electronic compass for heading. Inconclusive at best relative to your question.

Garmin support assertions or no, it is physically impossible for iR satellites to participate in location determination. The Iridium satellites do not broadcast necessary timing signals. Even if they did, there is typically only one Iridium satellite visible at any given time. It takes signals from 4 (or, at worst, 3) satellites to perform the trilateration calculations.

I so not think that (sum of chord distances)/(moving time) is always the same as (average of speeds on each chord). But now you've got me wanting to generate a counter example

On a slightly separate note, do you remember Iridium flares?  The large flat antennas of iridium satellites would reflect the sun to a path on earth, occasionally brighter than jupiter or venus.  The flare would last only a second or two as the path of the reflection moved over the ground.  I read that they've mitigated the effect by positioning the antennas.

There was a website ( heavens-above.com ) that you could enter your position and it would show the brightest flares for the next few days, by magnitude, altitude, azimuth, and time. I would telll my kids i was practicing at creating stars, take them outside, point at the location in the sky, and say i would try one right there.  It would flare up and fade away.  I would explain the fade because i'm still practicing. 

I think that the only case where the two numbers are not equal is when you do not actually move in a straight line between the points. In our example, let's say you zig zag back and forth across the chord while going from one end of it to the other. In this case, you will actually cover a longer distance than the length of the chord. If you are moving at a fixed speed, this segment will take longer than straight-line travel. The extra time will be reflected in the overall time moving. The extra distance will not.  Pretty sure this throws the (sum of chord distances)/(moving time) out of sync with the (average of speeds).