Introduction

Both the DOS and Windows versions of the EWView program and the EW Windows Uploader program used with the EW Flight Recorder support export of traces in the .IGC format defined by the International Gliding Commission - part of the Fédération Aéronautique Internationale.

This format contains B records which are used to contain information about individual fixes of time, geographical position, pressure altitude and GNSS derived altitude. In addition, extra fields can be added to the end of the B record. These are defined in the I record which appears near the start of the file.

The I record can define any of a number of different types of field. The field types are identified by three letter codes. One code is "REX" which specifies a manufacturer defined field type.

EW Avionics has chosen to define the use of the REX code for .IGC files produced from flight recorders it has manufactured. It is these fields which are defined in this document.

This document applies to EW models A, B, C, and D barograph and flight recorder traces exported by DOS and Windows versions of the EWView programs and by EW Windows Uploader. It does not apply to more recent EW recorders, especially not the EW microRecorder.

History

In versions of EWView produced prior to 1998 only a single character REX field was used. In spring 1998 versions of EWView were created which produced REX fields with two characters. In the later version the interpretation of the first field was not changed.

During the winter of 1999/2000 it was decided to update the EWView programs to allow the option of exporting traces with points which are not defined to be to the WGS 84 datum still marked as valid. When this option is selected the REX field reverts to the pre-spring 1998 form (that is, only the REX 1 character is present, not the REX 2).

Pre-spring 1998 traces and traces produced with the winter 1999/2000 versions or later with the option to leave non-WGS 84 samples as valid are referred to as non-invalidating traces.

REX 1 - GNSS Altitude Validity

The first character of the REX field indicates the validity or otherwise of the GNSS derived altitude.

This is required because some models of the EW Flight Recorder do not record the GNSS altitude with every sample or event. In order to conserve memory they only record this altitude often enough to meet the requirement of recording it once per minute.

The EWView program carries the previous recorded GNSS altitude forward to some later samples in order that each B record in the .IGC file should have an appropriate GNSS altitude.

However, the VALI-EWA program must compute its own security code using the same GNSS altitude values used by the flight recorder when it computed the security code stored in the trace. VALI-EWA must therefore be able to determine which GNSS altitude samples were actually recorded by the flight recorder and which were inserted by EWView.

The first byte of the REX code is intepreted as follows:

REX 1	Interpretation
A	GNSS altitude was stored by the flight recorder and should be included in the security code.
V	GNSS altitude was inserted by EWView and so should not be included in the security code.

REX 2 - Extended Fix Validity

Flight Recorder Datum Handling

The EW Flight Recorder is designed to ensure that the datum information stored is as accurate as possible. In particular, it is designed to err on the side of caution in assigning datum values to individual samples.

For this reason it is possible that some samples in a trace will not have a valid datum assigned. Typically, the first sample in the trace with a geographical position is recorded before the datum is established. Other samples can also be affected if there are GPS connections or disconnections or if the GPS datum is changed (perhaps for valid reasons prior to take off).

EWView Datum Handling

In .IGC files produced by EWView, changes of datum are recorded in the trace using event and log book records. (Sometimes it is not appropriate to use an event record for a GPS datum recorded by the flight recorder (e.g., because the datum record is the first in the trace and matches the header datum) but the presence of the datum record must be reflected in the security code - hence the use of log book records for some datum records).

VALI-EWA Datum Handling

However, analysis software might not deal with such datum changes accurately, particularly if the software was designed with flight recorders which have a single fixed datum per trace in mind.

Also, the .IGC file format does not have a well defined means of representing a position fix which does not have a known datum in a trace where other position fixes do have a specified datum.

Versions of VALI-EWA prior to 1998 went to some lengths to ensure that the user verified the relationships between non-WGS 84 datums and the appropriate codes used in the .IGC file.

As the IGC has now changed the Sporting Code to require the use of WGS 84 for all flights this complexity has become redundant. VALI-EWA has therefore been simplified to only note which samples (by UTC date and time) are not defined relative to the WGS-84 datum.

Invalidation of Non-WGS 84 Position Fixes

This is a good partial solution but still results in a few samples (e.g., the first in the trace) being noted as not being defined as relative to WGS 84. This creates unnecessary concern and work for the official observers and others involved in dealing with the trace.

For this reason, EW Avionics has decided to mark all samples in the trace which are not defined to be relative to WGS 84 as invalid. This will avoid problems with any analysis software which does not fully deal with datum changes and also correctly handles fixes for which the datum is not defined.

This decision is supported by the revision of the Sporting Code annex on flight recorders which now states (in Sporting Code Section 3, Annex B, Appendix 1, para 8) "that the WGS 84 Geodetic Datum (...) shall be used for all lat/long co-ordinates which are recorded and transferred from the FR after flight."

The original design and approval of the EW FR was made before this rule was introduced and the rule is applied retrospectively by requiring the use of WGS 84 for the position fixes sent to the EW FR by the external GPS. However, the rule change supports EW's change to mark non-WGS 84 fixes as invalid for Sporting Code purposes.

Preservation of Validity Information

Though non-WGS 84 fixes are now marked as invalid the original status must still be preserved. There are two reasons for this. Firstly, VALI-EWA must be able to make a decision on whether to include the position in the computation of the security code which matches the equivalent decision made by the flight recorder for its security code.

Secondly, for non-Sporting Code controlled flights use of datums other than WGS 84 might be acceptable. It must therefore be possible to determine which position fixes have been marked invalid in this way and which are actually invalid.

In extreme cases it would be possible to edit the .IGC file to mark the appropriate positions as valid again, though this would invalidate the file for Sporting Code purposes. For example, a competition pilot who inadvertently used the wrong datum might be allowed the flight but with an admin penalty.

An additional complication is that some flights might have no datum information at all. A typical example would be a flight recorded using a Garmin 100 GPS receiver which does not output datum information. Such a trace would not be valid for purposes covered by the Sporting Code but might well be acceptable in a competition. It would be unreasonable to mark all of the positions in such a trace as being invalid - they are left as valid but a special value is placed in the REX code to indicate this condition.

The second character of the EW Avionics REX code (REX 2) is used to preserve the position validity. It is interpreted in combination with the standard B record fix validity flag.

VALI-EWA must, of course, also deal with traces which were created by older versions of EWView which do not output the second REX character. This is shown as '-' in the table below.

The following combinations of standard B record fix valid field contents and contents of the second character of the REX code may be produced by EWView and are acceptable to VALI-EWA. Any other combinations will cause VALI-EWA to indicate that the trace is not valid.

Fix valid	REX 2	Interpretation by analysis software	VALI-EWA datum check	Included in security code	Usage
A	-	Valid	May be any datum. Reported if not WGS 84 but trace still valid.	Yes	Non-invalidating trace, valid fix.
V	-	Invalid	Not checked.	No	Non-invalidating trace, invalid fix.
A	A	Valid	Trace INVALID if not WGS 84.	Yes	Valid WGS 84 fix.
V	V	Invalid	Not checked.	No	Invalid fix.
A	N	Valid	Trace INVALID if any datum information at all present. Fix reported as not WGS 84.	Yes	Valid fix in trace with no datum information.
V	D	Invalid	Trace INVALID if is WGS 84.	Yes	Was valid but not defined relative to WGS 84 in trace containing datum information.

The term non-invalidating trace is used to signify a trace in which non-WGS 84 samples are not marked as invalid. That is, traces in which otherwise valid samples with undefined datum or datum other than WGS 84 are left marked as valid on export.

This can be either because the trace was exported by a version of EWView produced before the spring of 1998 (when the behaviour of marking as invalid non-WGS 84 samples was introduced) or because the trace was exported by a version of EWView produced during the winter 1999/2000 or later with the option to not invalidate non-WGS 84 points selected.

Currently, non-invalidating traces do not contain a REX 2 code. In future a REX 2 code to indicate this state may be introduced but this will need a new version of VALI-EWA to support it. Such an introduction would be required to allow further REX sub-fields to be added.

VALI-EWA does not use the REX 2 code in determining whether or not the position fix was relative to WGS 84. The datum record in the trace header and the datum change events and log book records are used for this purpose. The reason for this is that the header and datum change events/log book records are secure against manual editing because they are included in the security code.

VALI-EWA checks for consistency of datum information against the REX 2 codes as described in the "VALI-EWA datum check" column above.

Security Analysis

Note that there is no valid combination of Fix Valid flag and REX 2 code which will result in a position fix being interpreted as valid by analysis software without being checked for correct datum by VALI-EWA. All such fixes are also included in the security code.

We must consider the possibility that somebody could edit the Fix Valid and/or REX 2 codes in such a way as to make the trace still acceptable to VALI-EWA whilst obtaining more "useful" results for cheating purposes. By "acceptable" here we mean that the security code still matches and VALI-EWA does not report any position fixes which are not relative to WGS 84.

In carrying out such an analysis we can assume that only edits which preserve the inclusion or exclusion of the position fix in the security code need be considered - otherwise the security code would not match. In other words we need only consider changes between combinations which have the same value ("yes" or "no") in the "Included in security code" column. For "yes" these are A-, AA, AN and VD and for "no" they are V- and VV.

For the "no" cases the analysis is simple: any change between V- and VV simply converts an old invalid fix into a new invalid fix or vice versa with no effect on the interpretation by VALI-EWA or the analysis software.

For the "yes" cases more care must be taken. Let us consider them on a case by case basis:

Original	Editted	Effect
A-	AA	WGS 84: No effect. Not WGS 84: VALI-EWA reports trace invalid.
	AN	Traces with no datum information: No effect. Traces with datum information: VALI-EWA reports trace invalid.
	VD	WGS 84: VALI-EWA reports trace invalid. Not WGS 84: See below.
AA	A-	WGS 84 so no effect.
	AN	Datum information present so VALI-EWA reports trace invalid.
	VD	WGS 84 so VALI-EWA reports trace invalid.
AN	A-	No datum information present so VALI-EWA reports not WGS 84.
	AA	No datum information present so VALI-EWA reports trace invalid.
	VD	No datum information present so VALI-EWA reports trace invalid.
VD	A-	VALI-EWA reports fix not WGS 84.
	AA	Not WGS 84 so VALI-EWA reports trace invalid.
	AN	Datum information present so VALI-EWA reports trace invalid.

The only effect such editing can have on the trace without causing VALI-EWA to report problems is to mark an "old" non-WGS 84 valid fix as invalid. Since such a fix should not be used for trace analysis this cannot have an adverse effect for Sporting Code purposes and so does not affect the security.