Wesley Hill <<wesleyianhill>>
writes:

About 20 years ago. I was scoring a competition at Mt Buffalo, and
one of the pilots was flying with a MLR GPS and a Garmin backup. On one day the
pilot saw that his MLR was not receiving many satellites. He'd heard that you
could get better position information using '2D mode' and manually switched to
this (this used to be a common feature of marine GPSs). When he downloaded his
tracklog he used the Garmin - it showed him missing a turnpoint. So we checked
his MLR and it showed he got the turnpoint. Comparing the two tracklogs, you
could see them diverge at the time he switched to '2D mode', and the difference
in position seemed to be proportional to the height difference.

When I saw Tom's tracklogs from the Europeans it instantly reminded of those
tracklogs from 20 years ago.

I contacted Naviter and advised them that I thought the errors in Tom's Oudie
tracklog were incorrectly recorded 2D fixes. I got the impression that they
disagreed with my assessment.

Next I tested a friend's Oudie. We took it for a road test while partially
covering it with foil to degrade the GPS fix status. This test showed a
deviation from the road that looked a lot like the deviation that occurred in
Tom's tracklog. This file also has B records with fix validity = V, ie 2D or 'no
fix' B records. Looking closer at these specific B records, it could be
determined that they were all 'no fix' records as the Lat/Long were constant. So
this tracklog contained, according the the IGC file, only 3D and 'no fix'
points. This is a highly unlikely occurrence, as you would expect a transition
from 3D to 'no fix' would have some 2D fixes in between.

At this point, I felt justified in contacting CIVL and sent them the
information.

Ultimately, in order to verify how accurate an IGC file is, you need both the
IGC file and a log showing the output from the GPS chip. A quick read of the
Oudie manual showed 2 possible methods. The first involved running an existing
NMEA log as a simulation (the manual does not state whether this will produce an
IGC file). The second involves opening up a 'terminal' which can show the NMEA
output and which can then be saved. I don't have easy access to an Oudie, so I
decided to be prepared to conduct both tests next time the opportunity came
along. That meant creating a NMEA log that could be used in the simulation. I
have an old Garmin, so I took it for a road test and captured the NMEA log. I
have not yet carried out these tests.

I do have a SkyDrop, so I decided to also test this instrument. The SkyDrop has
a screen that shows GPS fix status. A static test showed that screen displayed
'no fix', 2D and 3D fixes. We then took it for a road test while attempting to
get 10 seconds of continuous 2D fixes as displayed on the screen. The road test
produced an IGC file with large position errors (and obvious GPS altitude errors
associated with those errors during the early parts of the tracklog). There was
also a >10 second period, identified from the GPS screen, as having 2D fixes.
The IGC file identified 3D fixes and 'no fix' data, there were no 2D fixes
recorded. The 10 second section of tracklog identified as 2D fixes was also
recorded as 3D fixes.

I notified SkyDrop and they referred to a (faulty) definition of 2D fixes from
the IGC Specifications. They also advised me how to record a NMEA log using the
debug mode. I took the SkyDrop for a walk and captured a NMEA log with several
2D fixes, including one 7 second sequence. Most of these 2D fixes were recorded
as 3D fixes in the IGC file, the exceptions were all the first 2d fix in a
sequence of 2D fixes (timing error?). SkyDrop has been notified but are yet to
respond.

Since I score competitions occasionally, I have a large quantity of tracklogs,
most of which are from 6030s. I looked at about 120 of them and found eight that
had B records with fix validity = V. It seems that most pilots use a tracklog
interval of 2 or 3 seconds with these instruments so it was not always possible
to identify these as 2D or 'no fix' records. So I started to look for GPS height
errors either side of those B records. I was able to identify, in 3 of those
files, B records recorded as 3D fixes where the GPS height did not change for a
significant period of time (this is the method of height prediction used by my
Garmin for 2D fixes). It seems highly probable that these are 2D fixes recorded
as 3D fixes. Being able to compare those tracklogs to a backup might provide
additional information, but ultimately you need a log with 2D fixes to compare
to an IGC file. I am not aware of any method where I can obtain a log from a
6030 to compare to its IGC file (It appears to be possible to send some NMEA
sentences via bluetooth, but the sentence which identifies the fix status is not
included). Volirium have been notified and I am waiting for a response.

Since 6030s (and SkyDrop) only send and sentences via bluetooth, I
was wondering how XCSoar was identifying 2D fixes. The code is open source so I
checked and found this: /* "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;

The comment appears to be quote from the (IGC) TECHNICAL SPECIFICATION FOR GNSS
FLIGHT RECORDERS. The code does not check the sentence, which is the only
way to identify a 2D fix. Garbage in, garbage out. I have so far been unable to
contact the XCSoar developers.

In summary, I believe that Oudie, SkyDrop and 6030 instruments all record 2D
fixes as 3D fixes, as does XCSoar. Fixing the firmware should be a relatively
simple process.

IMPORTANT REFERENCE INFORMATION

So what is a 2D fix - seems obvious, a fix in Lat/Long. The (IGC) TECHNICAL
SPECIFICATION FOR GNSS FLIGHT RECORDERS (http://www.ukiws.demon.co.uk/GFAC/documents/tech_spec_gnss.pdf)
states the following: "2D Position - a navigational position giving horizontal
data (ie lat/long) but not vertical (altitude). In GNS Systems, at least three
position lines (ie correct data from three satellites) are needed for a 2D fix."

Unfortunately, this is not correct. The main problem with this definition is
it states that a 2D position does not give an altitude.



A 2D fix is a fix giving Lat/Long as you would expect, but the GPS uses a height
that is predicted (assumed/guessed) in order to calculate that 2D position, and
that height is also included in the NMEA output it produces. A 2D fix is only
accurate if the height used is correct. When looking at the NMEA output from a
GPS, a 2D fix is identified by the NMEA GSA sentence with the number 2 in the
second data position (,A,2,...). See
https://www.gpsinformation.org/dale/nmea.htm#GSA. I suspect instrument
manufactures are just checking the NMEA GGA sentence for the fix height and
recording it as a 3D fix if the height is there.

TESTING IT YOURSELF

I have verified the above reference information using my old Garmin (and a lot
of Googling). You can verify it yourself with an old Garmin. Turn it on and
monitor the fix status, when it changes to 2D fix you will see the height
displayed (it uses the last known height), and when it changes to 3D fix the
height will change to your current location's height.

As a more advanced test, set your Garmin to record 1 sec intervals and work out
some way to capture the NMEA output (I used HyperTerminal PE, make sure you know
what settings are needed and activate capture). Now go somewhere with a >200m
height difference (from when it was last used) and turn on the Garmin while
capturing the NMEA output. You will now have access to a nmea log which you can
compare to the tracklog from your Garmin. Note the jump in position when the
Garmin switches from 2D to 3D fixes, and that height is recorded for 2D fixes.

If you want to test your Oudie I am happy to provide the NMEA log for use in
simulation mode. If you want to record the NMEA output using the terminal
feature, I would suggest a road test at a different location (preferably hilly)
and height to where it last had a GPS fix. This will slow down the the
transition from 'no fix' to 2D fix to 3D fix. Make sure you're in motion when
you turn it on so that it starts recoding an IGC file as soon as possible, if it
switches to 3D fixes quickly you may need to degrade the GPS status using foil
in order to get 2D fixes. Monitor the NMEA GSA sentence on the terminal screen
to see if you have 2D fixes.

Testing the SkyDrop is easy - make sure you know how to record the NMEA log
using the debug feature, then go to a new location/height and do a road test.
Hopefully you will get some 2D fixes before it switches to 3D, but you can use
foil to block the GPS signals if necessary.

For the 6030s, I only have single tracklogs. An additional test that could be
performed would be a road test (again, change location and height before turning
on and pick a hilly location). Optional - allow a second instrument to get a 3D
fix first to compare with. Start driving and turn on the 6030. Monitor the GPS
height on the screen, I would expect it show the last known height when it gets
a 2D fix, then jump to a height close to the current height when it gets a 3D
fix. You can now compare the tracklog (IGC file) to the actual road and see if
there are errors in the recorded position.

Does anyone know how to get an NMEA log from the 6030 without attaching wires to
its GPS chip? It should be noted that 6030s do not all have the same GPS chip,
so their method of predicting height may vary. The FURUNO chip uses the last GPS
height from a 3D fix, other chips may give different results (the chip type is
recorded in the IGC file).

Wesley sent me a set of IGC files that confirms what he has stated
here. Further he wrote:

The altitude errors are happening adjacent to 'no fix' records
which is when you would expect 2D fixes.

I think all the developers are under the impression that a 2D fix does not have
an altitude. This is not correct - the log from my Garmin (CAPTURE260718.TXT)
shows sentences indicating a 2D fix and a GPS altitude in the correspong
sentence.

Its critical to note that (for the Oudie) all the B records with Fix validity =
V are 'no fix' records (Lat/Long matches previous records Lat/Long), there are
no 2D fixes recorded at all. You would expect some 2d fixes during the
transition between 3D and 'no fix'.

For the SkyDrop, DEBUG.LOG shows sentences marked as 2D fixes, but most
of them are recorded as 3D fixes in 09-0134.IGC (only the first in a sequence is
recorded as 2D/'no fix', probably some sort of timing error).

For the 6030 file (olav020118.igc), a GPS speed analysis shows that all
(probably) of the B records with fix validity = V are 'no fix' records. Not so
precise as it is a 2 second recording interval, so a 3D fix might have occurred
and not been recorded resulting in a speed approx 50% of the average speed.

Wesley has just received Blenky's IGC file from his Flytec 6030
and is evaluating it.