EW Model "D" Flight Recorder

This document contains the technical description of the EW Model "D" Flight Recorder plus some notes on the differences of the EW Model "E" Logger.

Public document: This document has been processed to remove certain information which is important to the security of the EW Flight Recorders. As such it is incomplete but it is intended to contain all of the information required for normal operations such as setting of the trace recording parameters, entering a flight declaration and uploading traces.

The contents of this document are provided for information only and do not form any part of a specification of any equipment. Whilst the contents are believed correct at the time of writing no warranty is given. Behaviour of the equipment described may be changed at any time, with or without notice.

2007-04-18

Contents

• A to D Converter
  • Pressure Transducer
  • Battery Voltage
• Operating Modes
• Trace Details
• Commands
  • Command Errors
  • Command List
• BAT, BDR, CLR, CTP, GPI, GRC, GSI, GTP,
• GUI, GUN, LST, OFF, OTP, OUI, OUN, RID, SPI,
• SSI, STP, SRC, SUI, SUN, TAS, VER, XMU
• Trace Data Storage
  • Trace Header
  • Control Byte
  • Sample Interval
  • Next trace page and address
  • Trace start Dtime
  • Trace end Dtime
  • User number
  • Security Code
  • User info
  • Declaration
  • Declaration Dtime
  • Pilot Info
• Trace Record Format
  • Events
  • Samples
• Battery Checking
• Control Button
• Timeout in IO Mode
• IGC Approved Character Set
• EW Model "E" Differences
• Memory Organization
  • Paging
  • Layout
  • Fixed Area Contents
  • Trace Storage

A to D Converter

This is a two-channel unit producing 12-bit output. Channel 1 is connected to the pressure transducer and channel 2 monitors the battery voltage.

Pressure Transducer

Output from the transducer is converted to a 12-bit value by the A- to-D converter. This is then converted to a value which is stored in the trace. The actual altitude can be calculated from this value. Conversion is a two stage process consisting of: (a) mapping the A/D output span and offset onto the lookup table and (b) using the resulting value to index into the lookup table to obtain an actual altitude. The mapping process is done using three calibration parameters. Call the calibration values X, Y and Z. Then the A/D output (A) is mapped onto the lookup table using the following formula:

n = (A - X) * Y + Z

The actual altitude is then the nth entry in the lookup table. Note that X and Z are unsigned short integers, while Y, though also stored as a two byte integer, is considered to have a binary point after the 2nd bit from the left of the high byte i.e. 00.00 0000 0000 0000. This should give adequate span.

Battery Voltage

This can be read using a BAT command (see below). A similar principle is used to decode the A/D output, except that the offset Z need not be applied, so there are only two calibration constants. The intention is to read this periodically during recording, and, if the battery voltage is dangerously low, to shut down the unit before things go to pieces.

Operating Modes

After initial self-test, the unit listens for two hash (#) characters at 9600 baud within a 5 second period. If these are received, it switches to I/O mode (equivalent to Print Mode in the old barograph) at 9600 baud. If two hashes are not received, it switches to 4800 baud and enters Recording Mode. Upload software running in an attached computer should output hashes until it receives a confirmation that the unit is connected.

Trace Details

Each trace starts with a trace header which contains data about the current trace, pointer to the next trace etc. Thus traces in the unit comprise a linked list. Of particular importance, therefore, is the End of Chain flag bit in the trace header control byte, which indicates the last trace in the list.

Each trace contains, as a minimum, a single pressure altitude record. This is to ensure compatibility with the EWT file format which always contains at least one record. Thus the first record in any trace will not contain NMEA data. Subsequent records may contain NMEA data if a GPS has been detected meanwhile.

Traces are held as a sequence of compressed records. Each record begins with a control byte whose bits are used as flags to indicate which fields have been omitted because they have not changed since the last record. Fields affected by this system are latitude degrees and centiminutes high byte, longitude degrees and centiminutes high byte. A GPS validity flag is also stored here.

Since the first record is pressure altitude only, the bits in its control byte which indicate changed fields will be reset. The first record containing NMEA data will have these bits set, since this record must, by definition, explicitly contain the data for these fields. Subsequent records will have these bits set or reset according to whether their values have changed since the previous record.

Before each record is written, a look-ahead routine checks to see if the current record would collide with the beginning of the oldest trace in the unit. If this is about to happen, the global pointers to the oldest trace are changed to point to the second oldest trace, thus effectively erasing the oldest trace and freeing the memory it was using. The exception to this process is when the oldest trace is also the one being currently written. In this case, the current trace has filled the entire memory all by itself so the recording process just terminates.

Commands

The unit accepts a variety of commands which can be used to change configuration items such as the sample interval, or carry out actions such as sending a list of traces. The generalised command syntax is as follows:

#ABC[dd]cs<CR><LF>

Note that apart from the <CR><LF> which terminate the command, all the characters sent to the unit are printable letters and digits. The various parts of the command are:

Hash prefix. This is used to say to the unit "watch out, there's a command coming next".

ABC. This is a placeholder for the command identifier. The identifier always consists of three uppercase letters. A detailed list of valid command identifiers is given below.

Optional data. If a command requires numerical data, this will consist of a string of upper case hex, the length of which depends on the particular command. In this context, hex always consists of pairs of characters, so leading zeroes must be present. For example data "2, 32767" would be sent as "027FFF". Text strings are simply sent "as is".

cs. Exclusive OR checksum of the preceding bytes, not including the hash prefix as a two digit hexadecimal (upper case letters) number.

Command Completion. Some commands request output from the unit, in which case receipt of valid output can be taken as successful completion of the command. Except for trace uploading, output is normally printable characters without a checksum. When commands that don't produce output (e.g. configuration commands) have been successfully completed, the unit reports "OK"

Command Errors

The unit can detect and report a number of command errors. However unrecognised commands are simply ignored. The following errors may be reported:

Command List

The following commands are presently implemented thought there could be others in the future.

BAT Battery Level

Returns the internal battery voltage from A/D channel 2 as a two character hex string. This should be converted to an actual voltage by dividing the value returned by ten. For example, 5Fh (95d) represents 9.5 volts, FFh (255d) converts to 25.5 volts.

If the actual battery voltage is less than 6 volts, this function returns 00h. Since the unit's voltage regulator requires at least 6 volts to operate at all, this should not cause a problem, and furthermore the A/D converter will become unreliable before the voltage drops to 6 volts. However, attached software could denote this condition by a message such as "internal battery dangerously low".

This command has no parameters.

Syntax:

#BATcc<CR><LF>

cc Checksum of the preceding 3 bytes

BDR Set baud rate

Sets the baud rate for the serial port.

Syntax:

#BDRddcc<CR><LF>

dd Baud rate

cc Checksum of the preceding 3 bytes

The parameter dd passed to the command can have the following values:

Any other value for dd is not valid and has no effect.

CLR Clear all traces from memory

This does not do a complete system reset, it merely re-initialises the file system, leaving User Info, User Number, and Tps unaffected. This command has the following syntax:

#CLRcc<CR><LF>

cc Checksum of the preceding 3 bytes

CTP Clear turning point

This deletes a specified turning point from the declaration held in global memory. Once done, an attempt to get the Tp using GTP results in the message "No Tp"<CR><LF>. See also GTP and STP.

Syntax:

#CTPnncc<CR><LF>

nnNumber of TP to clear (00 - 05)

cc Checksum of the preceding 5 bytes

GPI Get Pilot Info

This reads back the Pilot Info previously input by SPI (Set Pilot Info). This data comprises exactly 58 ASCII characters (but see exceptions below) which may be subdivided by the user into fixed length fields such as pilot name, glider type and competition number.

The fields are defined for the purposes of the PC software as:

Characters sent to the unit from attached software must be taken from the IGC approved character set. The unit doesn't care about internal subdivisions of the data, it just outputs the stored 58 bytes and any formatting is the user's responsibility.

Syntax:

#GPIcc<CR><LF>

cc Checksum of the preceding 3 bytes

See also SPI (Set Pilot Info)

GRC Gets the Real Time Clock

This command outputs the current value of the RTC. The 12 character string returned is the hex representation of the six RTC fields in the unit. Example:

if 6205180C1A09 is received, this means a Dtime of 98-05-24 12:26:09.

The command has no parameters. Syntax:

#GRCcc<CR><LF>

cc checksum of the preceding 3 bytes

See also SRC (Set Real Time Clock)

GSI Get Sample Interval

This command retrieves the current sample interval and outputs it as 4 bytes of hex. Valid range is 1-999 seconds.

Syntax:

#GSIcc<CR><LF>

cc Checksum of the preceding 3 bytes

See also SSI, (Set Sample Interval).

GTP Get Turning Point

This retrieves a turning point specified by number. Valid TP numbers are 00h - 05h. The agreed convention is that TP00 will be the start and TP05 will be the finish, though the unit doesn't make any distinction internally. The unit outputs a TP consisting of 26 hex characters followed by CR and LF. A call to this command simply outputs data from the requested TP buffer, therefore it is the responsibility of the program which sets tps using STP to ensure the buffer contains data which it considers meaningful when it loads the buffer.

It is not necessary to load the buffers in a continuous sequence, e.g. buffers 0, 1 and 3 can be loaded. Assuming buffers 2, 4 and 5 have not been previously loaded, an attempt to get these Tps will result in the message No Tp<Cr><Lf>.

Syntax:

#GTPnncc<CR><LF>

nn Number of TP to retrieve (00 - 05)

cc Checksum of the preceding 5 bytes

See also STP (Set Turning Point), CTP (Clear Turning Point) and OTP (Output Turning Point)

GUI Get User Info

Outputs User Info as input by SUI. The line number required must be specified. See SUI for more on the format of User Info. The requested line is output with CR and LF appended.

Syntax:

#GUInncc<CR><LF>

nn line number to output

cc checksum of the preceding 5 bytes

GUN Get User Number

This retrieves the global user number previously set using SUN. The value returned is a 4-digit hex number.

Syntax:

#GUNcc<CR><LF>

cc checksum of the preceding 3 bytes

LST List Traces

This command returns a directory list of traces currently in the unit. When the unit first receives the command, it returns the number of traces currently stored (00h-FFh). You should then send one ACK character (Chr$(6)) for each trace. Each time the unit receives this character, it outputs a string giving directory information for the next trace. Therefore you must send as many ACKs as there are traces, as indicated by the number first returned by the unit. The directory info returned for each trace consists of the following fields:

Syntax:

#LSTcc<CR><LF>

cc Checksum of the preceding 3 bytes

OFF

Turns the unit off, equivalent to pressing the button once, while in IO mode.

Syntax:

#OFFcc<CR><LF>

cc Checksum of the preceding 3 bytes

OTP Output TP

This command retrieves a specific TP from a specified trace.

Syntax:

#OTPmmnncc<CR><LF>

mm number of trace

nn number of TP (00-05)

cc checksum of the preceding 7 bytes

OUI Output User Info

This is used to obtain the User Info associated with a particular trace. This will be a copy of whatever was in the User Info buffer at the time the trace header was written in memory. Any or all of the five lines may be blank, in which case just CR and LF will be returned. When creating EWT or IGC files, all five lines should be read.

Syntax:

#GUInnmmcc<CR><LF>

nn Number of trace whose User Info is to be retrieved

mm Line number to retrieve

cc Checksum of the preceding 7 bytes

OUN Output User Number

This command gets the user number embedded in a specified trace.

Syntax:

OUNnncc<CR><LF>

cc Checksum of the preceding 5 bytes

RID Return ID

This command outputs the unit's individual ID in the format YYWWDXXXX where:

YYWW: Year and week number of firmware

D: Barograph Model

XXXX: Serial number of the unit

Syntax:

#RIDcc<CR><LF>

cc Checksum of the preceding 3 bytes

SPI Set Pilot Info

This allows the user to input global pilot info to the unit. This data comprises exactly 58 ASCII characters which may be subdivided by the user into fields such as pilot name. glider type and competition number. The unit doesn't care about such subdivisions, it just accepts up to 58 ASCII characters.

The six fields are defined for the purposes of the PC software as:

Characters sent to the unit from attached software must be taken from the IGC approved character set.

To ensure consistency for the purpose of computing the security code, the PC software must set any unused bytes at the end of each field to 20h (space).

The command is a two step process; first the SPI command is issued in the usual way, then a stream of exactly 58 ASCII characters can be sent to the unit. Once 58 characters are received, inputting of data ceases and the command terminates with an OK message. Alternatively, if 10 seconds elapses from the issue of the command, it times out with a message: "Timeout on input". It then returns to the normal waiting-for-a-command state. This functionality is similar to that used for the SUI command.

Syntax:

#SPIcc<CR><LF>[Text String]

cc Checksum of the preceding 3 bytes

SRC Set the Real Time Clock

This command permits the user to send a string of hex to the unit in the same format as the one received when GRC is executed. This sets the RTC to a new value. Example: to set the RTC to 98-05-24 12:26:09, the user sends 6205180C1A09.

Syntax:

#SRCyymmddhhmmsscc<CR><LF>

yy Year mod 100

mm Month

dd Day

hh Hour

mm Minute

ss Second

cc Checksum of the preceding 15 bytes

SSI Set Sample Interval

This command is used to set the sample interval. This must be in the range 1-999 seconds inclusive. If the value sent to the unit is out of range, the current sample interval is left unchanged, the error message "Invalid sample interval" is output, and the command terminates. After the sample interval has been checked for range, it is written to the EEProm and then read back. The value read is compared with the value which was written and in the unlikely event that they do not match, the error message "Sample interval not set" is output. In this case, the contents of the sample interval fields may or may not have changed, so it is recommended that a few more attempts are made to set the sample interval. This should never happen but if it does, this may indicate a fault with the unit.

Syntax:

#SSInnnncc<CR><LF>

nnnn Sample interval to set - 4 bytes of hex. Range 1-999 (0001h-03E7h) inc.

cc Checksum of the preceding 7 bytes

STP Sets a TP

This command instructs the unit to accept a numbered TP. Each TP buffer has space for 13 characters, represented by 26 hex characters in this command. Valid TP numbers are 00h - 05h. The agreed convention is that TP00 will be the start and TP05 will be the finish. The command terminates when 26 hex characters have been received. See GTP for how to read back a TP, also CTP for clearing a TP.

The TP names supplied to the unit by the attached software should (a) be upper-case, and (b) use only characters from the IGC approved character set.

Although the 26 hex characters can represent anything as far as the unit is concerned, it is envisaged that each TP buffer will be subdivided into fields as follows:

* Lat/Long flags obey the same convention at the LL_Flags field in the barograph, i.e.

Bits 4-7 are always set to zero to allow the validation program to correctly deduce the value of this byte when reconstructing the contents of memory.

If no lat/long is to be defined, all bytes in these fields should be set to zero.

Syntax:

#STPnnttttttttttttttttttttttttttcc<CR><LF>

nn Number of TP to set: 00 - 05

tttttt... 26 hex characters.

cc Checksum of the preceding 31 bytes

SUI Input User Info

User Info corresponds to the comments field in the EWT file format. A full user info block consists of up to 5 lines of text (e.g. pilot name, glider number, etc) with up to 55 characters per line. Thus, this command could be called up to five times, each with different line numbers and text, to fill the whole block of data. See OUI for outputting user info.

This command prepares the unit to receive a line of user info which will be stored in the unit in a location which depends on the line number specified. After the command has been executed, the text for the specified line (00h - 04h) should be sent to the unit. The text should be terminated with a CR, as this signals to the unit that the end of the string has been received. If more than 55 characters are received before the CR, the unit stores the first 55 characters but ignores the 56th and subsequent characters. The string need not be null terminated.

Because sending the text string is a separate operation from processing the command itself, there is a 10 second timeout on receiving the text string. This is to ensure that if the connection to the unit is broken while the text string is being received, or no CR is received, or fewer than 55 characters are received without a CR, the unit will not wait indefinitely for further input. If more than 10 seconds elapses between the SUI command being issued, and either a CR or the 55th character being received, the unit stops listening to the serial port and issues an error message: "Timeout on input". In this case, the unit returns to the state in which it awaits another command. If a timeout occurs, any characters already received during the inital 10 second period are stored in the specified User Info line.

It is recommended that a brief pause (10 ms should suffice) be inserted between issuing the SUI command and sending the text string.

Syntax:

#SUInncc<CR><LF>[Text String]

nn Number of line to store (00h - 04h)

cc Checksum of the preceding 5 bytes

SUN Set User Number

This command instructs the unit to accept a global user number. This is sent as a 4-byte hex value, e.g. FFFF. The unit doesn't check for the range of this number, but to maintain compatibilty with the big barograph, the value sent should be in the range 0-9999. See GUN for how to retrieve the user number.

Syntax:

#SUNnnnncc

nnnn User number

cc Checksum of the preceding 7 bytes

TAS Returns the Trace Area Start

Outputs the address of the first byte at which trace information can be stored. This is required when uploading a trace which has wrapped around the start of memory. This means you can calculate the number of bytes in the trace from Trace Start Page and Address and Trace End Page and Address as obtained from the LST command. From this you can calculate the number of Xmodem blocks which will be transferred during the uploading process. You can use this for a progress meter if required. This command has no parameters.

Syntax:

#TAScc<CR><LF>

cc Checksum of the preceding 3 bytes

VER ROM Version Number

Syntax:

#VERcc<CR><LF>

cc Checksum of the preceding 3 bytes

XMU Xmodem Uploads a Trace

Syntax:

#XMUnncc<CR><LF>

nnNumber of trace to upload as returned by LST (0 based).

cc Checksum of the preceding 5 bytes

This command implements a standard Xmodem upload of a trace. This is the only command which results in the unit outputting binary data. If a trace is requested which doesn't exist, the error message "No such trace" is returned and the command terminates.

The sequence of events during uploading is:

• The Receiver (PC) sends NAK or C to tell the unit to send the first packet of data. If C, the unit appends a 2 byte CRC checksum to each packet, otherwise a one byte standard checksum is appended.
• The unit sends a packet header followed by a packet of data. The header consists of SOH followed by the sequence number and the ones complement of the sequence number. The packet comprises 128 bytes followed by the CRC or standard checksum.
• The PC checks the checksum. If OK, it sends ACK to request the next packet, else it sends NAK to request the unit to re-send the packet. Alternatively, it may send two CANs to abort the upload.
• Steps 3 and 4 are repeated until all the blocks are sent, when the unit finally responds with EOT. The receiver sends ACK, when the protocol terminates.

Once all the data are received, it can be decompressed and stored in EWT or IGC format. The on-off button is monitored during the Xmodem process so it may be used to terminate the upload prematurely. At each stage where the unit waits for a response from the receiver, it applies a timeout of 30 seconds. If the protocol is aborted by either end, a message: "Xmodem cancelled" is output.

The status LED flashes during data transfer to indicate that the process is continuing.

Trace Data Storage

The following section described how trace data is stored.

Trace Header

Every trace begins with a header. This consists of:

Control Byte

Individual bits in the control byte are used as flags as follows:

Sample interval

This is set using the SSI command and may be read using the GSI command. It will be in the range 1-999.

Next trace page and address

These combine to form a pointer to the next trace in the chain. If there is no next trace, these fields point one byte past the end of the current trace.

Trace start DTime

Date and time of the first sample.

Trace end DTime

Date and time of the last sample.

User number

This should probably be restricted to 0-9999 to be consistent with the old barograph.

Security Code

This is an 8 byte field containing the security code for the trace.

User info

This is copied to the trace header at the time when the trace header is written. It is centrally stored using the SUI command and may be read using the GUI command. User info from a specific trace may be retrieved using OUI. User info corresponds to the comments field in the EWT file format.

In the trace, only as much user info is stored as is actually required. This is to save space. Thus there is a length byte for each line of User Info, followed by only as many data bytes as the length byte implies. At its minimum, therefore, User Info might comprise nothing more than five length bytes each containing zero. To clarify this point, here is an example:

Suppose the User Info consists of the following lines:

EW Barograph

<Empty>

XYZ

Here is some info

<Empty>

This would be stored as:

0Ch "EW Barograph" 00h 03h "XYZ" 11h "Here is some info" 00h

Declaration

This consists of a flag byte followed by up to 6 fields of 13 characters each. 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 TP 00 is stored, bit 1 says TP 01 is stored, etc. Thus the number of declaration TPs to be read in from 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, which means that it is only necessary to test the flag byte for zero to find out if there is any declaration at all.

See command STP above for the agreed convention on the contents of each TP record.

Declaration DTime

This field is always present in the trace header. Declaration DTime records the date-time when the current declaration was downloaded from the PC.

Declaration DTime is updated to reflect the current RTC time whenever any component of the declaration is changed, i.e. when any of the following commands is issued: STP, CTP, SPI or SRC. This guarantees that the date-time of declaration can be legitimately converted to UTC by applying a UTC offset, since the same offset is applied both to trace samples and to correct Declaration DTime to UTC.

This procedure is designed to ensure that a paper declaration issued before the unit is switched on for flight recording, but after the declaration was downloaded, is not invalidated since the UTC declaration date-time is always available and can be shown to be earlier than the paper declaration.

Pilot Info

This 58 ASCII character field is used to store the pilot's name, glider type, comp. number, GPS info and flight date. The whole 58 ASCII characters are always present. The last character output by the unit is always a CR. If the user entered the maximum 58 characters, the unit will output these plus a CR, i.e. a total of 59 characters. If the user entered fewer than 58 characters, the character after the last one entered is a CR.

Characters sent to the unit from attached software must be taken from the IGC approved character set.

Trace Record Format

The trace is stored as an arbitrary number of discrete records. Each record is either a sample or an event. A sample always contains a pressure altitude and may also contain NMEA data. Samples occur at regular intervals as defined by the sample interval. Events can occur at any time, coinciding with samples, or in the gaps between samples.

Every record, whether event or sample, begins with a control byte. The first bit in this byte to examine is bit 0 (lsb) which is set if the data following the control byte is a sample, reset if it is an event.

Events

If the control byte's bit 0 is reset, the top nibble (bits 4-7) of the control byte indicates which type of event is being recorded. Bits 1-3 are unused in event records and are set to zero. The data in the bytes following the control byte varies depending on which type of event it is.

The table below summarises the various event types and the data they contain:

Note that all events except End of Trace comprise a control byte which identifies the event type, followed by data whose nature depends on the event type. The End of Trace event is the only one which consists of a single byte which includes the additional data.

The contact opening/closing events are constructed as follows. If valid NMEA data is not available, the event record comprises the control byte, DTime, and pressure altitude. If valid NMEA data is available, the NMEALL record is appended. In either case, the pressure altitude is recorded in the usual format:

Recorded value = (Actual value + 350) / 5.

If there is no valid NMEA, the record is terminated by a byte containing &HFF. If valid NMEA data is available, the 7-byte NMEALL record is appended. The first byte of the NMEALL record is the one which would otherwise be &HFF if the NMEA data was not available.

The first byte indicates the hemisphere:

The Datum Change Event records not only a new datum every time the user changes it, but also the initial datum shortly after the unit recognises that it is connected to a GPS.

The UTC fix event records the UTC time as supplied by the GPS. If the GPS sends the date as well as the time, the UTC record contains the UTC time in the same Dtime format as elsewhere. If there is no date available, the UTC DTime contains 000HMS, i.e. the date part comprises three zeros. As this is an invalid date, it can easily be recognised as such.

The End of Trace Event. This has two purposes, (1) to distinguish padding bytes in the last Xmodem packet from genuine trace data, and (2) to record the reason for the trace terminating. As with other events, the high nibble indicates the event type, and in this case, the low nibble is used to record the reason why the trace terminated. Since bit 0 must always be reset in order for the byte to retain its identity as an event, bits 1-3 are used to record this. Possible values for the low nibble are:

Note that although the values in the table above leave bit 3 reset, this can not be assumed as additional values may be used in future. Note also that the least significant bit is always zero (that's why these values are even). The actual end of trace codes are the high order three bits of the low order nibble, so are half of each of the values shown here.

Samples

As indicated above, a control byte with bit 0 set indicates that a sample follows. In this case, the remaining bits of the control byte are used as various flags. Bits 4-7 indicate whether certain fields have changed since the previous sample, and the fields referred to will be present in the sample record only if they have in fact changed. This mechanism saves memory by eliminating data which has remained unchanged from one sample to the next.

It follows that the first record in a trace to contain NMEA will always have its control byte bits 4-7 set, since the fields to which they relate must be explicitly contained in the record. In records containing pressure altitude only, bits 4-7 are reset, as are bits 2 and 3.

Bit 1 reset indicates that there is no NMEA data present in the sample, i.e. the NMEA device wasn't connected when the sample was taken. In this case, the only data present is the pressure altitude so the remainder of the control byte has no significance. However, to ensure consistency for validation purposes, bits 2-7 are reset in this case, as mentioned above.

If any component of an event latitude or longitude is different from a previous sample latitude or longitude, this does not affect the setting of control byte bits 4-7 which only record the relationship between successive sample latitudes and longitudes.

Note that latitude degrees are stored unsigned in the lower 7 bits (bits 0-6), with the msb (bit 7) used as a hemisphere flag. Bit 7 set indicates a southerly latitude.

Pressure and GPS altitudes are both stored in the same format. To compress them to 12 bits each, they are converted as follows:

Stored Value = (Actual Altitude + 350) / 5

The two altitudes are then packed into three bytes. If bit 1 of the control byte is reset (i.e. no NMEA data is available), the lower nibble of byte 2 is zero and can be ignored and byte 3 is omitted.

The meaning of the control byte bits in the sample record is as follows:

Sample Record Structure. The bytes following the control byte are organised as follows.

Battery Checking

Battery voltage is checked periodically and if below a pre-set value, the trace is terminated and the unit is switched off to protect data stored to date.

The following algorithm is used to determine whether the battery voltage has reached the danger threshold:

The voltage is measured every 5 minutes. If the voltage is below the acceptable minimum, another measurement is made one minute later, and at one minute intervals thereafter until either (a) the voltage rises above the acceptable minimum, in which case the original 5 minute measurement is restored, or (b) four consecutive measurements below the acceptable minimum are made, at which point the trace terminates and the unit is switched off.

The Control Button

This is used to switch the unit on or off. When the unit is off, a single, brief press of the button turns it on. What happens next depends on whether it finds a PC polling it via the serial port within a period of 5 seconds. If so, it enters "IO Mode", in which state it can be uploaded or configured. If no PC is present, it starts recording.

If the unit is switched on by pressing and holding the button for five seconds, it enters "IO Mode" directly. This may be useful if there is doubt as to whether the unit is actually connected to the serial port selected on the PC, since it avoids creating short, unintended traces.

There are three stages at which the button can be used to turn the unit off:

• during the 5 second listening period just after switch-on
• while trace recording is taking place
• while the unit is in IO mode

In each case, two clicks of the button are required within a 2-second period for the unit to recognise that it is being switched off. For debounce purposes, the button is considered to have been clicked only if it has been held down for a defined number of times round whichever software loop is executing at the time, otherwise the click is not counted.

Timeout in IO Mode

The unit maintains an internal record of the time when it entered IO Mode, and when it executed the last command. If more than a defined number of seconds elapses since either of these events, the unit will switch itself off. It will never switch off if this period expires while it is executing a command.

Currently the timeout is set to 5 minutes.

IGC Approved Character Set

This comprises ASCII characters 20h to 7Dh inclusive, but excluding 24h, 2Ah, 2Ch, 21h, 5Ch, 5Eh which are reserved. ($*,!\^).

EW Model "E" Differences

The model E logger is used for marine and road applications. It is very similar to the model D but is in a wider case and does not have a pressure transducer - it does not record either pressure or GPS altitude. It does, however, record positions with a resolution of milliminutes (one thousandth of an arc minute, about 1.9 metres in latitude) rather than centiminutes (one hundredth of an arc minute, about 19 metres in latitude).

This section describes the differences between the trace recorded by the model E compared to those of the model D.

Trace Header Control Byte This is the same as for the model D except that bit 4, which is always zero on the model D, can indicate "Enhanced Mode". In enhanced mode the logger records additional NMEA information relevant to sailing. This information is not described here so this document is only relevant to the case where this bit is zero - called simple mode.

Corners. At the end of the trace header, after the pilot information but before the control byte of the first sample are the "corners" of the trace - that is is the bounding box in latitude and longitude of the positions in the trace.

These are stored as four 32-bit (four byte) numbers - the southmost, the westmost, the northmost and the eastmost latitude or longitude. These numbers are directly in milliminutes. The latitudes are measured north from the south pole, the longitudes east from the 180 west line.

In determining these ordinates the logger first initialises them to the least extreme values. For example, the first (the southmost point) is initialised to the number of milliminutes north from the south pole to the north pole (10 800 000). Then the values are updated as more extreme values are encountered during recording of the trace. Therefore, if a trace contains no positions these "least extreme" values are stored.

Sample Timing With the model D, the first sample recorded is taken at the start time of the trace whereas with the model E the first sample is recorded one sample interval later. Therefore, the model E can have events (such as GPS connection) prior to the first sample.

Samples Model E samples follow the same general scheme as those of the model D but, as they are affected by most of the differences between the types, they are sufficiently different to be described directly.

As with the model D, the first byte is the sample control byte which has the low order bit set to indicate a sample, as opposed to an event. The remaining bits in the sample control byte and the following bytes are different between the two models.

Following the sample control byte are zero, or two to six data bytes containing the latitude and longitude. Which bytes are present depends indicated bits in the control byte being set:

Events. Model E event records are the same as those for the model D except that the pressure altitude bytes are omitted from the NMEA connect, NMEA disconnect, contact opening, contact closing and pilot events.

Memory Organization

This section describes the layout of the RAM within the Model D flight recorder. As the RAM contents are not directly accessible this is not normally of any interest. However, if it is necessary to recover information from a damaged unit, e.g., after an accident, then this information could be useful.

The major page address locations are the same in each of the software versions but the addresses of some data areas might vary from version to version. Where these are given here they apply to version 9942.

Paging

The Hitachi 6303 processor used in the EW model D has a 16-bit addressing capability, i.e., it can address 64K bytes. The RAM used for temporary variables and trace storage is 128K bytes. The processor also needs to address 16K of program ROM and various external I/O devices. This is achieved by dividing the RAM into eight 16K pages which are mapped into the lower two 16K pages of the processor's address space.

The ROM is mapped into the top 16K bytes of the processor's address space. This is required because the interrupt vectors which the processors reads from the top few locations of its address space need to be in the ROM so that they will be valid immediately after the processor is first started up. I/O devices are located in the 16K block below the ROM.

An additional complication is that the processor has a certain amount of on-chip RAM and I/O devices which are in the first 256 address locations. These take precedence over external devices. Therefore, the first 256 bytes of the RAM page mapped to the lowest 16K block is not accessible.

Considering the processor's address space to be divided into 16K pages, it is therefore laid out as:

The RAM page which is mapped into the processor address space page 1 is selected directly under software control. A routine (SelectMemoryPage) sets three i/o bits (IOPort 2 bits 7, 6 and 5, most significant to least significant) to choose the RAM page. These signals are gated with logic external to the processor so that RAM logical page 0 is accessed when processor page 0 is addressed but the page selected by the IOPort 2 bits is accessed when processor page 1 is addressed.

Note: The external logic which decides which RAM page is actually addressed may have some invertions or other complications such that the logical RAM pages discussed above do not correspond one-to-one with physical 16K blocks in the RAM chips "natural" address space. I need to check the circuit diagram or PCB layout for this when Graham finds them.

If we can't easily work out the logic of this address decoding then it should be reasonably easy to identify logical page 0 in a RAM dump because it contains a copyright text string at the start of the data (offset 0100h). See below.

In principle, it is possible to access RAM page 0 in two separate ways: via processor page 0 or by setting the page selection bits to all zero and accessing it via processor page 1. The selection-and-page-1 method has the advantage that the first 256 bytes are available (i.e., not masked out by the processor's on-chip I/O devices and RAM). The page-0 method has the advantage that the page is always available, even when other pages are selected.

In practice, logical page 0 is always accessed via processor page 0. Therefore, locations in logical page 0 are accessed with addresses in the range 0100h to 3FFFh. Locations in logical pages 1 through 7 are addressed as 4000h to 7FFFh. Therefore, the first 256 bytes of logical page 0 are not used even though they are, in principle, accessible.

Where a RAM location is stored (e.g., a pointer to the start or end of a trace) it is represented as three bytes: one byte for the page number and two bytes for the address within the page. In summary, for each such stored location the following invariants should hold:

Layout

As noted above, the first 256 (0100h) bytes of RAM logical page 0 are not accessible through page 0 of the processor's memory space whereas the rest of that RAM page are always accessible, irrespective of the mapping chosen for processor page 1. Therefore, all of the fixed data needed for the logger's state information, other than the actual traces, are stored in RAM logical page 0 starting at location 0100h.

The space used to record traces is the remainder of logical page zero and all of the other pages. The first trace recorded starts straight after the fixed data and following traces are added at successively higher locations until the memory is full. At this point storage wraps round to the initial location, deleting the oldest trace. Therefore, once the memory has been filled once it can nolonger be assumed that the oldest trace starts immediatedly after the fixed data.

As data is added to traces in memory they "eat" the oldest traces until the limit case where a single trace fills memory at which point recording stops.

The fixed area contains the page and address of the beginning of the oldest trace in memory. The header at the beginning of each trace then contains the page and address of the start of the next trace, forming a linked list. The next trace pointer in the header of the last trace points to the first byte after that trace. The end of the list is indicated by a bit in the control byte at the start of the header of the last trace.

At the start of the fixed area is a block of memory which is copied from the start of the ROM. It contains a copyright notice, the version of the logger, a one byte checksum of the ROM contents and the assembly date and time of the code in ROM. Each time the logger is switched on these RAM and ROM bytes are compared. If there is a difference then it is assumed that the RAM contents have not been initialised and a cold start operation is performed, which initializes the pointers mentioned above amongst other things.

Fixed Area Contents

The following are the locations and descriptions of selected items in the fixed area at the beginning of the RAM.

Trace Storage

The traces are stored in memory as described above under Trace Data Storage and Trace Record Format with the trace headers linked together as described under Layout.