eTrex 30 - significant differences of "Stopped time" on Trip Computer and Base Camp

Former Member
Former Member
At the end of a long walk my eTrex 30 Trip Computer shows Moving Time 05:21 and Stopped Time 05:09 but the same track loaded into BaseCamp shows Moving Time 09:59 and Stopped Time 0:36. BaseCamp is correct but Trip Computer is grossly inaccurate.
  • Former Member
    0 Former Member over 10 years ago
    Real-time, devices likely answer the question of stationary or moving by comparing adjacent position solutions. Since these adjacent solutions will almost always indicate movement (i.e. not be identical), a threshold value of distance or speed (these are the same over a 1 sec interval) might be used to determine motion.


    I would hope that the threshold is based on speed not distance and that the speed is averaged over several points to ensure an accurate estimate. Belt mounting might be a good option. I have also had WASS/EGNOS disabled so that is something else to try. I still think that better quality device firmware is required though: firmware that tells you that you are stopped when you really are stopped and moving when you really are moving. Obviously a walker's definition of stopped and moving is very much simpler than a software engineer's.

    I assume that track log record method (auto/distance/time) has no effect at all on the trip computer. Mine is set to Auto.
  • Your choice for logging data will have no effect on the trip computer.

    Older consumer gps receivers updated positions at 1/sec, so, if this is still true for Garmin handhelds, then distance and speed are the same value for a 1 sec interval (the programming will likely use units native to GPS calculations; meters for distance, seconds for time and m/s for speed). At faster intervals, calculation of speed may not be worth the cost. In BaseCamp/MapSoucre, speed along with the time interval between two logged points would be needed.

    For the purpose of detecting motion, precision of measurement is more important than accuracy of measurement. That is to say we become more interested in point to point comparisons as opposed to point to true value comparisons. As the interval between solutions becomes small, the more similar the biased errors will be in magnitude and direction between adjacent points and the more point to point error will reflect the precision of measurement. At an update rate of 1 Hz or greater, averaging may not gain that much.

    Under good conditions with WAAS/EGNOS, I think I saw stationary point to point variation of less than 1 foot over a 1 second interval 95% of the time based on a test I did some time ago with a different device. This would be about 0.7 mph (1.1 km/hr) – reasonable to cover most walkers and every activity that is faster. I have never run a test under poor conditions or without WAAS (my curiosity has its limits), so I can’t tell you how the limits change as conditions worsen.

    Since you are seeing false stationary guesses at 3.5 mph it could be mean that you are loosing a good deal of accuracy by placing the device in your pocket along with Garmin using a table of values and needing to adjust these values for poor reception. Of course, it could also mean that Garmin uses some other means of detecting motion, which may be the more likely answer. My method is just the first I would try to implement without giving it too much thought.
  • I would hope that the threshold is based on speed not distance and that the speed is averaged over several points to ensure an accurate estimate. Belt mounting might be a good option. I have also had WASS/EGNOS disabled so that is something else to try. I still think that better quality device firmware is required though: firmware that tells you that you are stopped when you really are stopped and moving when you really are moving. Obviously a walker's definition of stopped and moving is very much simpler than a software engineer's.

    I assume that track log record method (auto/distance/time) has no effect at all on the trip computer. Mine is set to Auto.


    I would also enable GLONASS if it's not already. It can help a lot if you are getting a poor signal.
  • Former Member
    0 Former Member over 10 years ago
    I would also enable GLONASS if it's not already. It can help a lot if you are getting a poor signal.

    I am using GPS + GLONASS, but not tested yet with WASS/EGNOS (which will be EGNOS for me in UK). I still think this has more to do with poor software than poor signal given (a) the very high sensitivity of the Etrex 30 compared to older devices (b) the good quality of the associated track log (c) the huge error is Stopped Time (d) the good mostly open sky walking conditions and (e) the total miles on the trip odometer was accurate (34.2 compared to 35.0 on BaseCamp).
  • Former Member
    0 Former Member over 10 years ago
    Your choice for logging data will have no effect on the trip computer.

    Older consumer gps receivers updated positions at 1/sec, so, if this is still true for Garmin handhelds, then distance and speed are the same value for a 1 sec interval (the programming will likely use units native to GPS calculations; meters for distance, seconds for time and m/s for speed). At faster intervals, calculation of speed may not be worth the cost. In BaseCamp/MapSoucre, speed along with the time interval between two logged points would be needed.

    For the purpose of detecting motion, precision of measurement is more important than accuracy of measurement. That is to say we become more interested in point to point comparisons as opposed to point to true value comparisons. As the interval between solutions becomes small, the more similar the biased errors will be in magnitude and direction between adjacent points and the more point to point error will reflect the precision of measurement. At an update rate of 1 Hz or greater, averaging may not gain that much.

    Under good conditions with WAAS/EGNOS, I think I saw stationary point to point variation of less than 1 foot over a 1 second interval 95% of the time based on a test I did some time ago with a different device. This would be about 0.7 mph (1.1 km/hr) – reasonable to cover most walkers and every activity that is faster. I have never run a test under poor conditions or without WAAS (my curiosity has its limits), so I can’t tell you how the limits change as conditions worsen.

    Since you are seeing false stationary guesses at 3.5 mph it could be mean that you are loosing a good deal of accuracy by placing the device in your pocket along with Garmin using a table of values and needing to adjust these values for poor reception. Of course, it could also mean that Garmin uses some other means of detecting motion, which may be the more likely answer. My method is just the first I would try to implement without giving it too much thought.


    You say that averaging might not help because at 1Hz the point to point errors will be too small (I get your reasoning). Yet something is affecting my Stopped time and if these errors are bigger than we think then averaging would help to improve the speed estimate. Neither of us knows how Garmin really does it though. And since the device "worked" throughout the walk I doubt if the errors were that great.

    If I set track log record method to Time with an interval of 1 second do you think I would get the same set of data points that the trip computer uses? That might help me evaluate the point to point errors. BTW - thanks for your input!
  • Yes, a running average will allow for a lower threshold value. It is really a question of how much it helps vs. the computational costs.

    Yes, logging tracks at a 1 sec interval would give you the same set of data points that the trip computer uses assuming that Garmin still uses position updates of 1 sec. Even if Garmin updates positions at a faster rate, it has a better chance of shedding light on what is happening. Keep in mind that the trip computer and BaseCamp/MapSource may differ in how they determine motion, which could lead to different values for total stopped time and distance.

    Experiments you might consider are the same walk with the device in your hand and in your pocket in similar terrain/direction as your long walk. Also recording a track while stationary with the device in your pocket and on the north side of your body (someone south of the equator should have it on the south side of their body) under poor conditions (say under a forest canopy with a nearby hill/bluff to the south (to the north south of the equator). The last would give better idea of the magnitude of false motion while the device is actually stationary under poor condition. This track need not be too long. Say 15 minutes of absolute boredom. Make sure your device has been on for ~15 minutes before recording your tracks.

    Posting your results (1 sec interval track logs as a gpx file) might help the collective to get a better handle on what is happening.
  • Former Member
    0 Former Member over 10 years ago
    Experiments you might consider are the same walk with the device in your hand and in your pocket in similar terrain/direction as your long walk. Also recording a track while stationary with the device in your pocket and on the north side of your body (someone south of the equator should have it on the south side of their body) under poor conditions (say under a forest canopy with a nearby hill/bluff to the south (to the north south of the equator). The last would give better idea of the magnitude of false motion while the device is actually stationary under poor condition.

    Posting your results (1 sec interval track logs as a gpx file) might help the collective to get a better handle on what is happening.


    My "shirt pocket" experiment proved to my satisfaction that in the hand is better (perfect) than in the pocket. That was a 7-mile walk so plenty of evidence there. I am also confident that there is never any false motion, only false non-motion. In other words moving time gets assigned to stopped time but never the other way round. Moving time never increments when the device is inside my house, where I'm surprised it even works at all. My gripe is that in-the-pocket should be as good as in-the-hand. PS: Garmin Support have suggested returning it for a replacement!

    Not sure that gpx files would help because the stats that BaseCamp calculates from them are fine. But you and others will know more about gpx fiiles than me, so I will post one when I get a suitable candidate.
  • I walk with either my Etrex 20 or Montana in my pocket where they work perfectly well. I suggest there is something else happening to cause your problems.
  • Devices have really improved in their ability to lock onto gps signals over the years. I would not have been surprised at all if my first one would have lost lock or dropped down to a 2D position if placed in a pocket while walking thru the woods. Simply orienting the antenna wrong (vertical/horizontal) caused an obvious drop in reception.

    I would probably take advantage of the offer for a device exchange unless you can think of some other reason for the poor performance in your pocket. The only remote possibility I can think of would be electronic interference. These devices are pretty robust, but I suppose that it is remotely possible that a pace maker, heart rate monitor or a cell phone in the same pocket could affect performance. But to be honest, I kind of doubt it.

    There is no real need to post a file, particularly if you end up replacing your device.
  • I also walk with my GPSs in my pocket including my eTrex 20 with no problem. In the past it made a difference if it was your pocket but modern GPS units including the eTrex 20 and 30 pick up the signal a lot better. You can see this from the fact that it works in the house. The only way I would think putting it in your pocket would matter is if you were someplace you had poor reception to start with or you have something else causing interference.