Tests on Garmin Geko show that the odometer software has a bug and will get the distance wrong every single time!
This fault or error means that the true distance covered is typically about 6% above the odometer reading.
It is likely that all the other Garmin models have the same software fault too.
Garmin could easily introduce an extra odometer routine in their firmware,
which would be helpful to Garmin owners,
but they do not seem to be at all interested in doing so!
At first sight one might hope that a GPS is going to measure the length of your walk to an accuracy of a few metres. A little more thought will suggest that there are going to be problems where the track crosses woodland and false points are recorded.
That sort of problem aside, a good track in open country will still have a problem of the tiny errors that occur each time a position is determined. So a GPS attached to a walker who is moving on a straight or smoothly-curving path will perceive the walker as following a zig-zag track. This will add to the calculated distance.
The error is reduced a lot by processing and storing the data. Unnecessary points are omitted and the remaining points will mostly be so far apart that the offset angles of the zig-zag approaches zero and hence the cosine of the angle approaches unity (in most cases to an excellent approximation).
So why is my Geko so consistently producing errors averaging 6% on first-class tracks that are free from major scatter? In the table below you will see the results that I am getting for near-perfect tracks. (If there is any appreciable scatter due to woodlands or hillsides then I have not put the data into this table.)
The software version is 2.70 in all three of the Geko GPS units used.
|Geko A||06-Apr-08||13.3||13.9||13.8||4.5%||Geko C-mr||06-Apr-08||11.7||14.1||13.9||20.5%|
|Geko A||06 May 08||15.4||16.7||16.6||8.4%|
|Geko B||06 May 08||15.2||16.6||16.4||9.2%|
|Geko A||08 May 08||11.5||11.7||11.6||1.7%|
|Geko B||08 May 08||11.2||11.9||11.9||6.3%|
Length of the track noted from Geko,
then data downloaded to Gartrip and either Memory Map or Tracklogs
and the length of the track noted from these.
I plan to ask Garmin what is going on here. Whatever it is, I would prefer things to be done differently! (The odometer in the Geko gave an underestimate of the distance in all of the above tests - and in the many other tests I have not reported here)
Please click on date to see the full text of any message
|To Garmin 11 Jan 2008||First contact|
|From Garmin 21 Jan 2008||Is it switched on etc.|
|To Garmin 24 Jan 2008||Will do as you asked, but look at extent of evidence!|
|From Garmin 29 Jan 2008||Request for more information|
|To Garmin 06 Feb 2008||Replies and me trying to get the discussion serious|
|From Garmin 07 Feb 2008||Polite reply|
|To Garmin 02 Apr 2008||More evidence and a very striking example|
|From Garmin 07 Apr 2008||"I will forward your suggestion to the appropriate channel"|
|To Garmin 29 Jul 2008||Asking what action is being taken to rectify the fault|
|From Garmin 29 Jul 2008||Acknowledgement, but no details of action.|
If you look at the three entries for 24-Jan-08 you will see there are three sets of results for the same walk. These were the results for three Garmin Gekos travelling together in the lid of a rucksack round the same route. The first and third produced perfect tracks whilst the second appears to have lost the signal briefly and then got one false point before locking on again. I have included this result in my table since a plot of the track shows a triangle where a rectangle should be but without significant alteration to the length of track and the affected section is only one very tiny portion of the total track length.
On the same walk a friend carried a Garmin Vista. This recorded 10.1 km for the track length. So, the three Gekos all produced results significantly different from the result given by feeding their trackpoints into a mapping program. Each Geko came up with a different track length. The Vista gave a track length in better agreement with the value derived from using the Geko data in the mapping programs.
I did a Master Reset on Geko C and then took it for a walk on 27 Jan in the company of Geko A. Laughably the Master Reset Geko recorded less than half the true distance! I have seen comparable mini-values before and always assumed that a sequence of button presses had occurred by accidental contact, although it does seem to happen amazingly often!
When the traces from the two Gekos were downloaded to a mapping programme they proved to be quite normal-looking and I would not describe them as differing in any significant way. It will be a few days before I can take the GPS units for another walk.
All these units are recording the data accurately. It must be the software for working out the distance travelled which is at fault. My explanation is in the email I wrote on 06 Feb 2008.
Shortly after writing the paragraph above, I went out on a walk with some friends and we had to retreat from a damaged path and take an alternative route. We also did a much smaller deviation to view a field of Llamas. Both these excursions produced an "out and return" effect on the track. When I got home I stored the points on Gartrip and then made a second copy and deleted all of the points on these two excursions. I also deleted a few tiny "blemishes" on the track which were genuinely due to high-error recorded points. The result fitted my theory like a glove fits a hand. The modified track had a length exactly equal to the value worked-out by the Geko. The track length had gone down from 14.1km to 11.5km - a loss of 1.6 km of which 1.5km had been genuine walking and about 0.1km had been due to high-error points.
The track in question is the one on 23 March 2008 and you can see a diagram of the unedited and edited tracks superimposed by clicking here.
I would like to see Garmin change the software to include an alternative odometer which uses a simple "join up the points" odometer, which would give us a much more accurate odometer reading when operating in good reception localities. That suggestion was submitted in the email I wrote on 02 Apr 2008.