| |
Issues with 2D tracklog points and GPSes
From the Beginning
Software Issues
Hardware Issues
From the Beginning
In the early days of GPSes, I was scoring a hang gliding competition at Mt Buffalo, and Gordon Rigg was flying in the competition.
Gordon had 2 GPSes, a Garmin and a MLR. The MLR had a setting where you could force it into 2D mode and during the
flight Gordon activated this setting (he thought it gave better accuracy when the number of satelites was low).
When the first download showed Gordon missing a turnpoint, we downloaded the other GPS. Comparing the 2 tracklogs,
it was clear that, from the time the MLR was put into 2D mode, the tracklogs seperated and the amount of separation
was related to pilots height.
Fast forward to the 2018 European Hang Gliding Championships - Thomas Weissenberger is approaching goal and the tracker
shows him
missing the last turnpoint. His flight instrument (an Oudie) shows him getting the turnpoint. A comparison of the 2 tracklogs show
them separating with the amount of separation being related to the difference in height...
This prompted some lively discussions, with a variety of reasons proposed for the variations in the tracklogs. I suggested
the flight instrument was recording 2D tracklog points and started doing some testing of various instruments (I had an
old Garmin 12 and a Skydrop, and I borrowed a friend's Oudie). The Garmin was used to get a NMEA log which was
useful as its output followed the NMEA standards correctly. The Oudie and Skydrop both had software AND hardware
issues. Analysis of Flytec 6030 tracklogs (I have a lot of these from scoring hang gliding competitions) showed some issues,
probably hardware related. Examination of XCSoar code (open source) showed software issues.
Software Issues
The software issues I identified are related to the IGC specifications which have been implemented by various
hang gliding / paragliding / sailplane instrument manufacturers and in code used by apps or software installed on
other devices.
Here is the code from XCSoar:
/* "Use A for a 3D fix and V for a 2D fix (no GPS altitude) or for
no GPS data" */
gps_valid = basic.location_available && basic.gps_altitude_available
It is simply assigning a 3D fix if there is a location and height in the GPS data - the problem with this is that a
2D fix will have location and height data!
How did they get it wrong? The first response to a suggestion that the code is wrong will be a reference to
the IGC Specifications which state things like:
GNSS altitude drop-out. Where GNSS altitude is not recorded such as in the case
of a 2D fix (altitude drop-out), it must be recorded in the IGC file as Zero so that the lack of valid GNSS altitude
can be clearly seen during post-flight analysis.
It seems that the IGC specs incorrectly assume that a 2D fix will have an altitude of 0. While this seems reasonable, it is not
actually the case - a 2D fix is obtained when there are insufficient satelites for a 3D fix, and the GPS compensates
for the lack of satelites by assuming a certain height (often the last known height) and uses the assumed height in
its calculations. So a 2D fix will include a height and is only accurate if the height used is correct. This explains the
diverging tracklogs detected from Thomas's tracklogs.
Both Oudie and SkyDrop manufacturers modified their software to correctly interpret the GPS data, although they both still
had hardware issues. Oudie also added code to produce a NMEA log (SkyDrop had this already) which was useful
for identifying hardware issues.
Hardware Issues
Would you believe that many GPS chips currently used have a fault when identifying 2D tracklog points? I'd done a bit of
testing by now and was getting quite good at identifying 2D tracklog points, so I was surprised to see them even after
the Oudie and SkyDrop code had been updated. The NMEA log would show them as 3D fixes, but there were obvious
positional errors and height errors.
If you can find a datasheet (here's one for the PA6H) for your GPS chip look for something like this:
| | Table-6: Mode 2 |
| | Value | Description |
| | 1 | Fix not available |
| | 2 | 2D (<4 SVs used) |
| | 3 | 3D (≥4 SVs used) |
What this is saying is that if there are 4 or more satelites used to get the fix, then it is a 3D fix. Unfortunately, this is not
always true - it is possible to have a 2D fix even when 4 or more satelites are used. And what is really unfortunate is
that these GPS chips seem to identify 3D fixes in a manner consistent with the datasheet. So a 2D fix that uses 4 or
5 or 6 satelites will be incorrectly identified as a 3D fix.
| Here are links to some of my
files and other websites that
are relevant to the
above observations: |
|---|
|
Garmin NMEA |
My old
Garmin 12 produced this NMEA log - shows 2D tracklog points with 4 or more satelites used.
As an extreme example this NMEA sentence
shows 5 SVs used in a 2D fix:
$GPGSA,A,2,05,07,,09,,,27,,30,,,,2.9,2.9,*10 |
SkyDrop NMEA
SkyDrop IGC |
NMEA file
and associated IGC file.
Files were created while driving on a road and clearly show positional and
height errors consistent with 2D fixes, but have been recorded as 3D fixes
Note that the GSA sentence appears to incorrectly list SIV (Satelites in view) instead of SIU (Satelite in
use).
eg: $GPGSA,A,3,28,01,30,17,15,,,,,,,,1.72,1.46,0.91*07
All of the GSA sentences seem to indicate that all of the SIV are also SIU, when normally this would
happen on only rare occassions. |
Oudie NMEA
Oudie IGC |
NMEA
and associated IGC files.
Files were created while driving on a road and clearly show positional and
height errors consistent with 2D fixes, but have been recorded as 3D fixes
Note that the GSA sentence appears to incorrectly list SIV (Satelites in view) instead of SIU (Satelite in
use).
eg: $GPGSA,A,3,30,07,09,08,23,193,,,,,,,3.27,1.61,2.84*33 |
| Copy of PA6H datasheet (in case
the link
is broken) |
|
NMEA GSA and other sentences information |
|
2D vs 3D fix explained |
| |