• cotsgps

This is a place for me to gather information on the October 2009 Sporting Code rules which will permit some flight evidence to be gathered by COTS GPS units. I will arrange these thoughts as time allows. There might be significant changes to this page for a period of time. References to relevant internet sites will be added, as will sample log files from some actual candidates. The extraction prodecures will be documented. Graphics will be added.

Considerations.

Which methods of retrieval should be supported?

Most GPS which store track logs use a propriety internal formal. Examples are Garmin etrex Legend; Holux M-241.

The OO must extract the log and convert it to .IGC format for submission with the SAC Claim form. The internal logs are not usually "signed" or protected in any way (as far as I understand).

The Secure G Record in IGC File

There are some "download" utilities which extract the logs directly from particular GPS models, and which can produce a .IGC file with a valid G security record. These programs usually interact with the GPS via a serial or USB-serial interface. The unprotected, propriety file makes no intermediate stop on the computer, so the opportunity to modify the record produced by the GPS is reduced. These programs are not open-source. Examples are g7towin and gpsdump.

When a Secure G Record can't be produced

Newer GPS models store the track logs in a file. The filesystem of the GPS is accessible when a USB connection is established. An example is the Garmin Nuvi 260w which produces a standard .GPX log (an XML-based track log). The track file may be directly copied from the filesystem of the GPS to the computer. The track file must then be converted to .IGC format by using a conversion program. A good example is gpsbabel. A valid security record is not included by the .IGC file produced for at least two reasons. (1) The source track file is untrusted, being simply a standard file on the filesystem of the computer (2) gpsbabel is an open-source utility, so it would be possible to recompile the utility to defeat or "customize" the G security record produced by the program.

Assuming the OO can be trusted with the insecure file copied from the device in the above example, it might be acceptable to allow him to "sign" that file and the .IGC equivalent produced by the conversion utility. There are highly secure, mature open-source signing protocols which could guarantee the integrity of the track and IGC files in the state which was deemed satisfactory to the OO. In this case, he should have placed the recording GPS in the aircraft, ensured that no existing track log was on the device and that it was impossible to illegally plant such a log on the device. After the flight, he should be the one to retrieve the track log and to validate it against external evidence of the flight e.g. takeoff and landing times which could not have been known in advance of the soaring performance.

Taking the Nuvi 260w as an example, one way that the track log could be guaranteed to have been produced in-flight would be for the OO to "prime" the nuvi with a pre-constructed .GPX log. The Nuvi adds records to the existing file, so it would be impossible for the pilot to know what OO records would precede his own flight track. This is more secure than simply erasing the on-board track log because it establishes a seed position known only to the OO. This could be considered the equivalent of the grease-pencil line drawn randomly on the canopy which would appear on the photographic evidence.

It is worth trying to build an acceptable procedure for the Nuvi because many modern Garmin devices are likely to function in an identical fashion.

Initial thoughts on testing GPS Candidates

Method A.

Get an initial list of candidate devices. Gather them all together and erase any preexisting track logs. Set them all to recording mode. Arrange them with a monitoring pilot in the rear of a two-seat glider. Add an approved logger such as our EW-MR. P1 sits up front. A flight is made. Some thought should be given to flying a particular track and to making some "turnpoint" maneuvers. The track logs from each device extracted and analyzed for equivalence to each other and to the approved logger.

Method B.

Similar to Method A, except that a road-based course is "flown". Some techniques to expose "averaged" or "predicted" positions should be included. These might include shielding the devices receiving a satellite signal immediately prior to making a 90deg turn, then un-shielding them some good distance away. Those devices which store predicted fixes in their log should continue in the direction before the turn was made.

Method C.

This method says that candidate devices are subjected to both Method A and Method B.

Garmin etrex Legend

Sample of a track log extracted from the Garmin etrex Legend.

etrexLegend-gpsdump-IGC-analysis.pdf

How was track extracted from the GPS? Using the Linux version of a program called gspdump.

http://www.multinett.no/~stein.sorensen/

Was an intermediate file produced? No. The program extracts the records from the GPS and creates an .IGC file with a secure G record.

Command line usage:

What does that mean? run gpsdump, fetching a track log from a Garmin on serial port 0, producing an .IGC file called test1.igc.

garmin-etrex-legend-sample1.igc

How can the file be validated? Using a DOS program called vali-xgd.exe . This program prints the word PASSED or FAILED and issues return codes zero or 255 respectively.

vali-xgd.exe