Contents
Introduction
The DOS and Windows versions of the EWView program and the EW Windows Uploader program, used with the EW A, B, C and D Flight Recorders, provide the ability to export traces in the .IGC format defined by the International Gliding Commission - part of the Fédération Aéronautique Internationale.
This document describes the subset of the .IGC files which are actually produced by these programs.
Certain information is not defined because it forms part of the security mechanism. In particular, this means the interpretation of the contents of the G record and one component of the contents of the LEWAT record.
In addition, this document contains notes on the processing of .IGC files by VALI-EWA and discussions of the reasons for certain decisions in the selection of the format. These notes are shown in italic to signal that they do not form part of the basic description of the file format.
Applicability
There have been a number of versions of the .IGC format which have been in some ways incompatible with each other. Also the EWView programs have been developed over a period of time with additional features and with changes to follow the changing IGC definition.
This document therefore gives a general format which covers the more recent versions of the EWView programs, particularly those with version numbers 97XX and 9850. It does not apply to some earlier 98XX versions which were produced for development purposes and given limited distribution. It also applies to later versions of the programs until further notice.
97XX versions of EWView/DOS conform to the format specified here but do not support the serial number ranges or declaration features implied by Model D Barographs. They cannot upload traces from Model D Barographs and, if used to export traces uploaded by later versions, will give an error implying that the serial number is "non-standard" and will omit the declaration information from the exported trace.
Obviously, this document does not apply to flight recorders not supported by the EWView and EW Windows Uploader programs. In particular, it does not apply to .IGC files created by the EW microRecorder even though that also uses VALI-EWA for validation (there are essentially two different validation processes within that program sharing only the lowest level of input checking).
The notes on VALI-EWA in this document apply to version 9850 and later until further notice. They do not necessarily apply to earlier versions of VALI-EWA unless specifically noted.
File Naming
EWView/DOS allows the user to configure the file names used for exported .IGC files. In particular, there is some degree of flexibility to label files in a suitable way for competition use. However, the default is to follow the IGC standard naming convention.
In the standard naming convention the format of the name is YMDCXXXF.IGC. Y, M and D encode the date of the flight. For these purposes, the UTC date of the start of the trace is used. C is the manufacturer specific letter and is 'E' for EW Avionics. F is the flight number for the day and is chosen to be the lowest value which makes the file name unique in the directory to which the export is made.
XXX is an encoded form of the barograph serial number. Like other values in the file name it is a base 36 number. It is derived from the unique part of the barograph serial number, that is the middle letter and the last four digits. The encoding is as follows:
| Model | Barograph S/N | Decimal encoding | Base 36 encoding |
|---|---|---|---|
| English 10Km | vvvvA0001 to vvvvA0999 | 1 to 999 | 001 to 0RR |
| vvvvA1000 to vvvvA1999 | 1000 to 1999 | 0RS to 1JJ | |
| English 12Km | vvvvB0001 to vvvvB0999 | 2001 to 2999 | 1JL to 2BB |
| vvvvB1000 to vvvvB1999 | 3000 to 3999 | 2BC to 333 | |
| vvvvB2000 to vvvvB2999 | 4000 to 4999 | 334 to 3UV | |
| French 12Km | vvvvF0001 to vvvvF0999 | 5001 to 5999 | 3UX to 4MN |
| English 15Km | vvvvC0001 to vvvvC0999 | 6001 to 6999 | 4MP to 5EF |
| vvvvC1001 to vvvvC1999 | 7000 to 7999 | 5EG to 667 | |
| vvvvC2000 to vvvvC2999 | 8000 to 8999 | 668 to 6XZ | |
| English, Miniature, 12Km | vvvvD0001 to vvvvD0999 | 9001 to 9999 | 6Y1 to 7PR |
| vvvvD1000 to vvvvD1999 | 10000 to 10999 | 7PS to 8HJ |
The last four digits of the serial numbers for the 'A', 'B' and 'C' models are actually unique but there are 'D' and 'F' models with the same numbers as 'A', 'B' or 'C' models. Manufacture of 'A' models ceased before serial number 2000 was reached. In practice there are only a few 'C' models in existence but they are scattered over the number sequence common with the 'A' and 'B's so three "blocks" are allocated in the above table.
Clearly, future models or extensions to the ranges of serial numbers in use may result in versions of the EWView programs which expand this table. Serial numbers which are not covered by entries in the above table are exported with the serial number part of the file name set to "000". EWView/DOS shows a warning message box when this is done.
Record Order
This section describes the order in which records appear in the .IGC file. Each record type is identified by its first few characters. For example, record type "AEWA" refers to an "A" record with the manufacturer code set to "EWA" and "HFDTE" refers to a header record whose data source is the flight recorder which contains the date of the flight.
Syntax Notation
In the record order description the following notation is used:-
| Notation | Meaning |
|---|---|
| <x> ::= y. | Element x is defined as expression y. |
| <x> | Element x as defined in another part of the description |
| x y | Expression x followed by expression y. |
| x | y | Expression x or expression y, but not both. |
| [ x ] | Expression x. Used to group elements together for other syntax purposes. |
| x ? | Zero or one instance of x. That is, x is optional. |
| x * | Zero or more instances of x. |
| x + | One or more instances of x. |
Overall File Structure
The overall format of the file is defined by:-
| <EW-IGC-file> ::= | <head> <task>? <point>+ <tail>. |
That is, the file consists of a head, optionally a task, one or more trace points and a tail.
VALI-EWA ignores all lines which consist of only zero or more blank characters. It also ignores any excess carriage return characters which appear immediately prior to the carriage return/line feed combination terminating a record and allows a single line feed with no preceeding carriage returns to terminate a record. It also allows the last record of the file to be terminated by the end of file, without any carriage return or line feed.
These relaxations of the strict interpretation of the IGC file format specification give extra resilience in the face of the sort of corruption which is likely to happen if the file is transmitted as text in e-mail without impinging on the validity of the data.
File Head
The file head is at the start of the file and can be in one of two forms:-
| <head> ::= | <declD-head> | <no-decl-head>. |
| <delcD-head> ::= | AEWA HFDTE HFFXA HsPLT HsGTY HsGID HFDTM? HFRFW HFRHW HFFTY HFGPS? I. |
| <no-decl-head> ::= | AEWA HFDTE HFDTM? I. |
The <declD-head> form is used if either the trace contains a declaration (of the task or pilot/glider details) or if it is created by a Model D Barograph. Currently only Model D Barographs can create traces containing declarations but if a future version of the A, B or C Barograph firmware also supported declarations then any traces it created which did contain a declaration would have this syntax.
The <no-decl-head> form is used for traces produced by Model A, B or C Barographs which do not contain task or pilot/glider declaration information. Ideally all traces exported by newer versions of the EWView programs would contain HFRFW and HFRHW records to conform better to the more recent IGC specifications. However, they would not then be compatible with older versions of VALI-EWA which check for the addition of "spurious" FR source header records.
HsPLT, HsGTY and HsGID denote pilot name, glider type and glider identification records respectively with record source fields "F" (for FR source) or "P" (for Pilot source).
VALI-EWA ignores any HO (header, OO source) or HP (header, pilot source) records present between the AEWA and I records with the exception of records with types HOPLT, HPPLT, HOGTY, HPGTY, HOGID and HPGID which, if they appear, must be in the positions specified by the syntax above. This allows for the insertion of such records by other software and upward compatibility for their insertion by future versions of the EWView programs. However, VALI-EWA will report an error for any HF (header, FR source) records whose record subtype is not recognised, for any H records other than HO, HP or HF and for any H records after the I record.
The syntax of head accepted by VALI-EWA is:
| <VALI-EWA-head> ::= |
AEWA
HFDTE [HFFXA HsPLT HsGTY HsGID] | [[HOPLT | HPPLT ]? [HOGTY | HPGTY ]? [HOGID | HPGID ]? ] HFDTM? [HFRFW HFRHW HFFTY HFGPS?]? I. |
Note that logbook records are not allowed in this context.
Task
The task part of the file is present if either the trace contains a declaration (of the task or pilot/glider details) or if it is created by a Model D Barograph.
Its syntax is:-
| <task> ::= | LEWAK C1 C2TO C2Start C2TP* C2Fin C2Land. |
Here the names of the various forms of the C record are defined by adding the number of the record sub-type ("one" or "two") and the abbreviated name of the type of point being defined.
VALI-EWA ignores any non-manufacturer specific logbook records ("L" records with the manufacturer ID set to three spaces) before, between or after the task records.
Trace Point
There is one trace point sequence of records for each sample or event present in the original trace. The trace point sequence incorporates records for any changes of geodetic datum (of which there may be zero, one or more than one) between the preceeding trace point and this one.
The syntax is:-
| <point> ::= | <datum-change>* E/~CGD? B. |
| <datum-change> ::= | [E/CGD | LEWAB] LEWAM. |
Here E/CGD denotes an event record for a change of geodetic datum and E/~CGD denotes an event record for anything except a change of geodetic datum.
VALI-EWA ignores any non-manufacturer specific logbook records ("L" records with the manufacturer ID set to three spaces) before, between or after the trace point records.
File Tail
The file tail comes after the trace points. It contains some logbook records specific to EW Avionics and the security record at the end of the file.
| <tail> ::= | [<new-logbookrecords> | <old-logbookrecords> ] G. |
There are two different forms of the log book record sequence which appears in the tail of the .IGC file depending on the version of EWView in use. The difference is required to accommodate the requirement that the log book records which are manufacturer specific should be included in the security code. In order to meet this requirement the logbook records which do not affect the security code have the manufacturer field set to blank in more recent versions of EWView.
For traces from a Model A, B or C Barograph which do not contain a declaration the manufacturer field of all logbook records is set to "EWA" to maintain compatibility with old versions of VALI-EWA.
| <new-logbookrecords> ::= | L U L E L I L D L F L P L S L C* LEWAT L N? |
Note that the "T" logbook record does contribute to the security code and therefore is marked as "EWA" irrespective of the version.
| <old-logbookrecords> ::= | LEWAU LEWAE LEWAI LEWAD LEWAF LEWAP LEWAS LEWAC* LEWAT LEWAN? |
VALI-EWA ignores any non-manufacturer specific logbook records ("L" records with the manufacturer ID set to three spaces) before or between the file tail records. Such logbook records are not allowed after the G record.
Records
AEWA
The A Record contains the identification of the FR.
The Manufacturer field is set to "EWA".
The Unique ID is a five character field (under the grandfather rights rule) and consists of the model letter and the last four digits of the FR serial number.
The ID extension is set to a space followed by the version number (first four digits) of the FR serial number. This version number does not contribute to the unique identification of the FR. Optionally, it may be followed by a four digit minimum revision number for VALI-EWA required to validate the file.
The VALI-EWA minimum revision number is provided in order to allow VALI-EWA to give a better error message if it is presented with a file which it is not capable of dealing with. For example, if a new HFABC .IGC record type was introduced a message such as:
C:\EW>vali-ewa 88qe0002.igc
This version of VALI-EWA (9850A) is incompatible with the specified file.
The file requires VALI-EWA version 9927 or later.
Error at line 1.
EW Flight Recorder security checks indicate file '88qe0002.igc' is INVALID.
would be preferable to one such as:
C:\EW>vali-ewa 88qe0061.igc
Unexpected record type.
Error at line 4.
EW Flight Recorder security checks indicate file '88qe0001.igc' is INVALID.
Only versions of VALI-EWA after 9835 support this revision level field so earlier versions will still give the less elegant style of message on processing incompatible files. Version numbers for weeks to the end of the year 2089 are catered for using the last two digits of the year number - that is, version numbers with years 00 to 89 are assumed to be after those for years 90 to 99.
EWView should avoid the specification of the VALI-EWA revision level unless it is actually necessary. For example, it should be omitted from traces from Model A, B or C Barographs which are written to be compatible with older versions of VALI-EWA.
For example, a trace for a barograph serial number 9800D0002 would start:
AEWAD0002 9800
Or, if a hypothetical VALI-EWA version 9927 or later is required:
AEWAD0002 98009927
HFDTE
The HFDTE Record contains the UTC date of the flight. This is the date portion of the barograph clock's date and time of the first sample of the trace, corrected to UTC as described under the LEWAT record below.
For example, for a trace recorded on 26th August 1998:
HFDTE260898
HFFXA
This record is present in traces created by a Model D Barograph and also in any traces which contain declaration details.
The fix accuracy is set to 100 metres by the EWView program. This value is chosen because of the GPS SPS specification of 95% CEP radius of 100 metres. If Selective Availability is ever turned off permenantly then future versions of the EWView programs may set a lower value for traces recorded after that date.
For example:
HFFXA100
This record is not present in traces created from Model A, B or C Barographs which do not contain a declaration. This is in order to maintain compatibility with previous versions of VALI-EWA.
VALI-EWA verifies that the accuracy is 100 metres preventing users from editing the file to claim unjustifiable accuracy. VALI-EWA will therefore need updating if a change is made to EWView to reflect the removal of SA.
HsPLT
This record is present in traces created by a Model D Barograph and also in any traces which contain declaration details, even if the pilot name in the trace is blank.
"s" denotes the record source. It is "F" when the trace uploaded from the barograph contained a pilot name, "P" when it was blank.
The long name is set to "Pilot". The pilot name consists of from zero to 12 characters. For example:
HFPLTPilot:Ed Davies
This record is not present in traces created from Model A, B or C Barographs which do not contain a declaration. This is in order to maintain compatibility with previous versions of VALI-EWA.
In traces from Model D Barographs and traces containing declarations, VALI-EWA treats HOPLT and HPPLT records as HFPLT records with the pilot name set to blank for security code computation purposes.
Software other than EWView can add, modify or replace HOPLT and HPPLT records as long as they are positioned in the file in accordance with the syntax described under File Head above.
HsGTY
This record is present in traces created by a Model D Barograph and also in any traces which contain declaration details, even if the glider type in the trace is blank.
"s" denotes the record source. It is "F" when the trace uploaded from the barograph contained a glider type, "P" when it was blank.
The long name is set to "GliderType". The glider type consists of from zero to 8 characters. For example:
HFGTYGliderType:ASW19
This record is not present in traces created from Model A, B or C Barographs which do not contain a declaration. This is in order to maintain compatibility with previous versions of VALI-EWA.
In traces from Model D Barographs and traces containing declarations VALI-EWA treats HOGTY and HPGTY records as HFGTY records with the glider type set to blank for security code computation purposes.
Software other than EWView can add, modify or replace HOGTY and HPGTY records as long as they are positioned in the file in accordance with the syntax described under File Head above.
HsGID
This record is present in traces created by a Model D Barograph and also in any traces which contain declaration details, even if the glider identification in the trace is blank.
"s" denotes the record source. It is "F" when the trace uploaded from the barograph contained a glider identification, "P" when it was blank.
The long name is set to "GliderID". The glider identification consists of from zero to 8 characters. For example:
HFGIDGliderID:971
This record is not present in traces created from Model A, B or C Barographs which do not contain a declaration. This is in order to maintain compatibility with previous versions of VALI-EWA.
In traces from Model D Barographs and traces containing declarations, VALI-EWA treats HOGID and HPGID records as HFGID records with the glider identification set to blank for security code computation purposes.
Software other than EWView can add, modify or replace HOGID and HPGID records as long as they are positioned in the file in accordance with the syntax described under File Head above.
HFDTM
This record is present in traces recorded with a GPS receiver which outputs the geodetic datum in use in a suitable format. If there is more than one datum used in the trace then the first recorded is placed in the HFDTM record.
Versions of EWView/DOS prior to IGC approval set the HFDTM to the datum applicable at the time of takeoff. However, this gave problems from the point of view of verification of the security code so the scheme was dropped.
The long name is set to "GPSDATUM". The text string is set to the GPS datum as reported by the GPS. This is trimmed to a maximum of nine characters by taking the first seven characters and the last two non-blank characters from any remaining.
For example:
HFDTM100GPSDATUM:WGS 84
HFRFW and HFRHW
These records contain the FR's revision numbers for the firmware and hardware respectively. They are present in traces created by a Model D Barograph and also in any traces which contain declaration details.
The long names of these records are set to "FirmwareVersion" and "HardwareVersion". In both cases the text string is set to the version number and model letter component of the serial number (that is, the first four digits and the middle letter). For example:
HFRFWFirmwareVersion:9800D
HFRHWHardwareVersion:9800D
These records are not present in traces created from Model A, B or C Barographs which do not contain a declaration. This is in order to maintain compatibility with previous versions of VALI-EWA.
HFFTY
This record identifies the manufacturer and model of flight recorder. It is present in traces created by a Model D Barograph and also in any traces which contain declaration details.
The long name of the record is set to "FRType" and the manufacturer name is set to "EW Avionics". The model is the middle letter from the FR's serial number. For example, for a Model D Barograph:
HFFTYFRType:EW Avionics,D
These records are not present in traces created from Model A, B or C Barographs which do not contain a declaration. This is in order to maintain compatibility with previous versions of VALI-EWA.
HFGPS
This record is present in files created from traces which contain a declaration with either (or both) of the GPS receiver model field or GPS receiver serial number field non-blank.
It contains the long name "ReceiverTypeSerial" and the comma separated contents of the GPS model and serial number fields from the declaration. They are each from zero to 12 characters in length. For example:
HFGPSReceiverTypeSerial:Garmin 100,92400510
I
The I Record defines the extra fields contained in the B Record. In traces created by EWView this contains only one extra field, a manufacturer specific field (REX) which, depending on the version of EWView which exported the trace, contains either one or two characters.
The contents of this REX field are described in EW Avionics IGC File Format - REX Code Interpretation dated 1999-12-07.
For example:
I013637REX
LEWAK
This log book record is present in traces created by a Model D Barograph and also in any traces which contain declaration details.
The purpose of the LEWAK record is to preserve certain information necessary to apply the task information to the security code. Specifically, it records which of the six Turn Point fields in the the FR's memory were used for each turn point declared. By convention the zeroth turn point is used for the start, TPs 1 through 4 are used for turn points on task and TP 5 is used for the finish. This convention is reflected in the export of these turn points to C records.
The contents of the LEWAK record are two hex ('0'..'9', 'a'..'f') digits which encode a single flag byte value. The bits in the byte are numbered from the right - that is, the least significant is zero and the most significant is seven.
The flag byte is used to indicate which fields in the declaration are in use. If the flag byte’s bit 0 is set, this means TP0 (start) is stored, bit 1 says TP1 is stored, etc. Thus the number of declaration TPs in the trace is the same as the number of set bits in the flag byte, and their locations in the list (0-5) depends on the positions of the set bits. The unused bits (bits 6-7) of the flag byte are always reset.
The bits in the flag byte are set if either the lat/long or the name is specified for the corresponding turn point.
For example, for a trace in which the start, two turn points in the first two available fields and a finish point are specified the record would be:
LEWAK27
C1
This subtype one C record appears after the LEWAK record and before the subtype two C records for the turn points. It contains general information on the task declaration. It is present in traces created by a Model D Barograph and also in any traces which contain declaration details.
The Date UTC and Time UTC fields are set to the time at which the declaration was made as determined by the FR's real time clock corrected to UTC as described under the LEWAT record.
The time of declaration is the time of the last command sent to the FR which set or cleared a turn point or set the pilot information (which includes the glider type and identification, the GPS model and serial number and the declared date of the flight) or the time of the last command which set the FR's real time clock (RTC), whichever was the later. In effect, changing the RTC reaffirms any declaration stored in the FR. This allows the time of the declaration to be accurately related to UTC in any trace which contains UTC fix information obtained from a GPS receiver.
The task date is set to the declared flight date the user included in the declaration downloaded to the FR. If no declaration had been downloaded (or somebody sneakly downloaded a declaration without a declared flight date) then it is set to 010190 meaning 2090-Jan-01: a valid date but not one likely to cause confusion with a real declaration for some time.
Note that the user will probably set a local date for the declaration so in some cases this value can be valid but different from the UTC date of the start of the flight by plus or minus one day.
As there is only one task declaration in each trace the Task ID is always set to "0001".
The Number of Task TPs is set to the number of turn points excluding the start and finish. It is therefore equal to the number of bits set in bit positions 1 through 4 of the flag byte in the LEWAK record and so it is in the range zero to four inclusive. VALI-EWA checks that this value is consistent with the LEWAK flags byte and also that there are the required number of turn points present in following C records.
The text string field is not used.
For example, for a triangular task:
C060498190104240898000102
C2TO
This subtype two C record appears after the subtype one C record in traces which contain a task declaration and all traces created by a Model D Barograph.
It specifies the take-off location for the task. The EW Model D barograph does not allow this information to be stored so a fixed string is used:
C0000000N00000000ETAKEOFF (not defined)
C2Start
This subtype two C record appears after the subtype two C record for the take off position in traces which contain a task declaration and all traces created by a Model D Barograph.
It contains the position of the start point. If this is undefined in the trace then it is set to "0000000N00000000E". Because the EW Barograph stores positions in one hundredths of a minute the last digits of the latitudes and longitudes are always zero. VALI-EWA verifies this.
The text string is set to the name of the point as specified in the trace. This may be upto six characters in length. If the trace does not contain a name then the text string is omitted. A name can be present even if the lat/long is undefined.
For example:
C5137620N00051550WBOB
C2TP
These subtype two C record appear after the subtype two C record for the start point in traces which contain a task declaration and all traces created by a Model D Barograph. There can be from zero to four such records present.
They contain the positions of turn points in the declared task. For turn points for which only a name was specified the position is set to "0000000N00000000E". Because the EW Barograph stores positions in one hundredths of a minute the last digits of the latitudes and longitudes are always zero. VALI-EWA verifies this.
The text string is set to the name of the point as specified in the trace. This may be upto six characters in length. If the trace does not contain a name then the text string is omitted. A name can be present even if the lat/long is undefined.
For example, the turn points for a triangular flight might be:
C5137290N00115650WDID
C5154930N00108190WBIC
C2Fin
This subtype two C record appears after the subtype two C records for the turn points (or after the subtype two C record for the start point if there are no turn points) in traces which contain a task declaration and all traces created by a Model D Barograph.
It contains the position of the finish point in the declared task. For a finish point for which only a name was specified the position is set to "0000000N00000000E". Because the EW Barograph stores positions in one hundredths of a minute the last digits of the latitudes and longitudes are always zero. VALI-EWA verifies this.
The text string is set to the name of the point as specified in the trace. This may be upto six characters in length. If the trace does not contain a name then the text string is omitted. A name can be present even if the lat/long is undefined.
For example:
C5136830N00048760WBOO
C2Land
This subtype two C record appears after the subtype two C record for the finish point in traces which contain a task declaration and all traces created by a Model D Barograph.
It specifies the landing location for the task. The EW Model D barograph does not allow this information to be stored so a fixed string is used:
C0000000N00000000ELANDING (not defined)
E/CGD / LEWAB
These two record types are used to represent records in the original trace recording the geodetic datum in use. Both appear in the sequence of event records preceeding a B record as described in the syntax of a point and a datum change.
An E/CGD record is an E Record with the TLC (three-letter-code) set to "CGD" (change of geodetic datum).
A LEWAB record is a log book record whose contents has the same syntax as an E/CGD record except that the string "LEWAB" occurrs in place of the initial "E". Therefore, all the fields in the LEWAB record appear four columns to the right of those in the equivalent E record.
The choice of the use of an E/CGD or LEWAB record depends on whether there is actually a change of geodetic datum. If the datum specified in a particular datum record in the original trace is the same as that of the preceeding datum change or HFDTM record then a LEWAB record is used, otherwise an E/CGD.
The LEWAB record is needed even if the datum does not change in order for VALI-EWA to correctly compute the security code.
Normally, if there is an HFDTM record in a file then there will be at least one E/CGD or LEWAB record also present, preceeding the first trace point for which the datum is defined. However, if the trace was recorded by an EW Flight Recorder with an integral GPS receiver then only the HFDTM record is present as there is no possibility of changing the datum during trace recording. (Such devices have not been approved for gliding use and are not currently available commercially).
The UTC time is that of the following point (sample or event).
The EWView software determines the datum code by matching the spellings of datum names recorded in the trace against a list of known spellings used by various approved GPS receivers. If no match is found then the datum code is set to 999.
If the EW Barograph ceases to receive from the GPS receiver NMEA sentences indicating the datum in use a datum name consisting of nine asterisks is recorded. This also causes the datum code to be set to 999.
Examples:
LEWAB190124CGD100
E190124CGD100
LEWAM
A LEWAM record is a log book record which appears in the file exactly once after each E/CGD and exactly once after each LEWAB record.
The LEWAM record communicates the exact spelling of the datum name recorded in the trace. This is necessary to ensure that VALI-EWA can correctly compute the security code.
The contents of the LEWAM record are the name of the geodetic datum as recorded in the trace - that is, the name as reported by the GPS receiver trimmed to a maximum of nine characters by taking the first seven characters present and the last two non-blank characters from the remainder.
The name can also be nine asterisks if the EW Barograph failed to receive a NMEA datum sentence from the GPS receiver.
For example:
LEWAMWGS 84
E/~CGD
E/~CGD denotes an event record other than one for a change of geodetic datum (CGD). They occur immediately prior to the associated B record.
There is never more than one event record (other than CGD records) for each B record. Two events which occur within the same second have separate B records because the pressure altitude might be different on them.
The TLCs (three letter codes) which can be present are:-
| PEV | Pilot Event. | Corresponds to a tag event initiated via the Model A, B or C EW Barograph's keyboard or a pilot event contact closure input on the Model D Barograph. |
| PHO | Photo. | Caused by a photograph being recorded by pre-IGC approved versions of the EW Barograph. |
| CCN | Camera Connect. | Caused by detection of camera connection by pre-IGC approved versions of the EW Barograph. |
| CDC | Camera Disconnect. | Caused by detection of camera disconnection by pre-IGC approved versions of the EW Barograph. |
| EDN | Engine Down. | Caused by closing of the contact closure input to the EW Barograph. |
| EUP | Engine Up. | Caused by opening of the contact closure input to the EW Barograph. |
| GCN | GNSS Connect. | Caused by detection of connection of a GPS receiver to the EW Barograph. |
| GDC | GNSS Disconnect. | Caused by detection of disconnection of the GPS receiver from the EW Barograph. |
Note that the camera events (PHO, CCN and CDC) only originate from versions of the EW Barograph prior to those with IGC approval and so will not validate using the VALI-EWA program. However, this is no reason why these files cannot be used in an environment where independent verification is available. Typically, this means a competition.
Note also that the fast sample contact closure input on the EW Barograph does not cause event records to be included in the .IGC file, only extra B records at the appropriate times.
There is no text string present on these records.
For example, a contact close event:
E190124EDN
B
There is one B Record for each sample and one for each event in the trace.
As with almost all other times in the .IGC file, the time on the B record is computed by applying a UTC correction to the barograph's clock time of the sample or event.
The latitudes and longitudes are recorded to the nearest hundredth of a minute, so the low order digit in each case is zero. This is verified by VALI-EWA.
The fix valid flag indicates the validity of the latitude and longitude.
The pressure altitude is always valid. For the Model A, B or C Barographs it is always a multiple of 10 metres and for the Model D Barographs it is always a multiple of 5 metres. VALI-EWA verifies this.
The Model A, B or C Barographs only record the GPS altitude often enough to ensure that it is recorded at least once per minute. For example, if the sample interval is set to 12 seconds then every fifth sample will have a GPS altitude recorded (i.e., one GPS altitude every 60 seconds) whereas if somebody was twisted enough to choose a sample interval of 7 seconds then every eighth sample would have a GPS altitude (i.e., one GPS altitude every 56 seconds).
The Model D Barograph records the GPS altitude on every sample if it is available.
EWView sets the GNSS altitude in the B record to the GPS altitude recorded for the sample, if any. If no GPS altitude is recorded in the sample but a sample strictly less than sixty seconds previously had a valid GPS altitude then the GPS altitude from the previous sample is used. Otherwise, the GNSS altitude in the B record is set to zero.
Following the GNSS altitude is a one or two character REX field as defined in the I Record and described in more detail in the separate document EW Avionics IGC File Format - REX Code Interpretation dated 1999-12-07.
L___U / LEWAU
The "U" logbook record contains the user number from the flight recorder trace. Generally this is set to the glider number when this is numeric.
It is a number in the range 0 to 9999 inclusive and therefore consists of from one to four decimal digits.
For example:
L U971
L___E / LEWAE
The "E" logbook record contains the error code specifying the cause of termination of trace recording. The interpretation varies between the model A, B or C and the model D barograph but in both cases zero means termination without error.
It is a decimal number. In all currently defined cases it is a small number but it will always be in the range 0 to 32767 inclusive.
For example:
L E0
L___I / LEWAI
The "I" logbook record contains the sample interval used for the original trace. It is a decimal number of seconds in the range 1 to 999 inclusive.
For example, for five second sampling:
L I5
L___D / LEWAD
The "D" logbook record contains information on checking for changes to the barograph clock's date or time between the time the at which the trace was recorded and the time at which it was uploaded. It can contain one of three strings:
| String | Interpretation |
|---|---|
| Yes | The barograph's clock was not changed between trace recording and upload. |
| No | The barograph's clock was changed between trace recording and upload. |
| Not checked | The trace was uploaded by a very old version of EWView which did not check for the message indicating change of the clock. |
The meanings of the "Yes" and "No" strings are indeed bizarre. They result from a simple coding mistake in an earlier version of EWView/DOS. It is felt better to keep the meanings standard across all file versions than to reverse the meanings to make them more intuitive.
For example, the normal case when the barograph's clock was not changed:
L DYes
L___F / LEWAF
The "F" logbook record contains the date and time at which the trace was uploaded according to the barograph's (i.e, FR's ) clock.
It is in the format DDMMYYHHMMSS, i.e., day, month, year, hour, minute, second.
For example:
L F260898182100
L___P / LEWAP
The "P" logbook record contains the date and time at which the trace was uploaded according to the computer's (i.e, PC's ) clock.
It is in the format DDMMYYHHMMSS, i.e., day, month, year, hour, minute, second.
For example:
L P260898182040
L___S / LEWAS
The "S" logbook record contains the identification of the program (software) which exported the trace. It contains the name (e.g., "EWView/DOS") and the version number.
For example:
L SEWView/DOS-9832AX
L___C / LEWAC
The "C" logbook record contains a line from the comment text added to the trace. For the Model A, B or C barograph this information can only be added in EWView but for the Model D barograph it can be that set in the FR, possibly modified through EWView.
There can be from zero to five comment lines present. Only comment lines which are non-blank in the original trace are exported.
The first character of each comment (after the "C") is a decimal digit which indicates which line the information came from. It can be from zero to four inclusive. Note that though the lines will always be present in ascending order there may be gaps in the numbering, for example, lines 0 and 3 might be present if the user left the second and third lines of the original comment text blank.
After the line number comes the comment text. It can consist of from one to 55 characters.
The .EWT file allows many characters from the IBM character set (a subset of code page 850 - Multilingual (Latin 1)) but .IGC files are restricted to a defined subset of the ASCII character set. For this reason disallowed characters are mapped to appropriate .IGC characters. For example, some disallowed characters are mapped to '#' (hash or number symbol), comma is mapped to semicolon and accented letters are mapped to their unaccented equivalents. This mapping is detailed in ewa-igc-charmap.htm.
For example, a two line comment in which '\' characters in the file path in the second line have been transformed to hashes.
L C0 Trace with partial point specification in declaration.
L C1 ..#vali-ewa#88QE0001.IGC
LEWAT
When the EWView programs export a trace from .EWT format to .IGC format they calculate the average difference between barograph clock time and UTC as reported by the GPS receiver and use this difference to convert times in the trace which are relative to the barograph clock to UTC for storage in the .IGC file. VALI-EWA must reverse this process in order to correctly compute the expected security code for the trace.
The LEWAT record contains the information required by VALI-EWA on the offset between the barograph's clock and UTC. It consists of an eleven digit, possibly signed, zero filled decimal number and a two hex digit ('0'..'9', 'a'..'f') number.
The decimal number is the number of seconds which needed to be added to the barograph clock's times in order to obtain UTC. The meaning of the hex number is proprietary to EW Avionics as it is part of the security mechanism.
For example, from a trace where the barograph's clock was just over one hour (3781 seconds) ahead of UTC, typical of a flight in Britain during summer time, so that that number of seconds needed to be subtracted from the barograph's clock times in order to obtain UTC times. The extra hex number is "df":
LEWAT-0000003781df
L___N / LEWAN
The "N" logbook record is present in some traces exported by later versions of EWView. It contains "incident" flags which indicate certain conditions which have occurred during trace recording. Its purpose is to assist with analysis of problems and to help with the testing of new GPS models.
The contents of the record are a two digit hex number containing the actual incident flag byte and a single character which indicates whether the version of EWView which performed the upload checked for the presence of the incident flag byte. It can be 'Y' for yes or 'N' for no. If EWView did not check for the incident flag byte on upload then the value will be zero.
Only 9815 and later until further notice versions of the Model A, B or C Barograph produce incident codes. Only similarly numbered versions of EWView process the incident code. Traces exported by earlier versions of EWView will not contain the L___N record. Traces exported by recent versions of EWView which were uploaded by earlier versions will have a zero incident code with 'N' for the "checked for flag". Similarly, traces exported by recent versions of EWView for any trace from a model D Barograph will have a zero incident code and 'N'.
Note: Interpretation of these flags takes some understanding of the internal operation of the flight recorder. Presence of a non-zero value does not indicate a problem with the trace. In fact, non-zero values are common, particularly on long traces and some care in the operation of the flight recorder is required in order to make these flags meaningful.
Numbering the bits from the low order bit (as zero) the interpretation is:
| Bit | Value | Interpretation |
|---|---|---|
| 0 | 0x01 | Non-zero bit in high order nibble of byte read from real time clock. |
| 1 | 0x02 | NMEA character overrun while keyboard inactive. |
| 2 | 0x04 | NMEA character overrun while keyboard active. |
Obviously, future versions of the barograph may add extra flags or change the interpretation of the existing flags.
For example, from a trace recorded by a Model A, B or C Barograph, uploaded and exported by recent versions of EWView:
L N00Y
G
The G Record contains the security code which was originally computed by the FR. In the case of traces from IGC approved EW Flight Recorders this is an eight byte value represented as 16 hex ('0'..'9', 'a'..'f') digits.
In traces produced from FRs prior to IGC approval the G record is present but empty.
For example:
G8d71ff70f67e7500