EW Windows Uploader - Port Logging

Introduction

This note applies to EW Windows Uploader version 0322A and later until further notice.

When resolving communications problems with a logger it is sometimes useful to be able to see what communication is going on through the serial port. EW Windows Uploader has, from its inception, contained a facility to allow such communication to be logged. Due to changes made to related software this facility was made available to end users at almost no extra effort on our part in version 0322A.

As well as assisting with problem solving, this facility could well be of use to people attempting to communicate with the loggers using their own software - providing an easy way to see how EW Windows Uploader communicates.

Logging is controlled by a Windows .INI file which indicates the name of a file to be used for each serial port for which logging is required. The specified log files are created as the program is run containing all of the bytes sent to or received from the port in a relatively easy to read format, using only printable US-ASCII characters.

.INI File Format

The control file should be placed in the Windows directory (typically C:\Windows or C:\WinNT) and named EW Windows Uploader.INI.

This file follows the normal format for Windows .INI files, that is, a number of sections started by lines containing the section name in square brackets. Each section contains a number of entries, one per line, consisting of a key name, an equals sign, and a string which is the value of the entry.

The only section used is [LogFiles]. The keys used in this section are:

Key String
COM<n> The name of the log file to be written for the indicated port. <n> is the port number in the range 0 to 12 inclusive.
Paranoid A Paranoid entry with any string value other than an empty string results in the file being flushed and closed after each line written. This could be useful if some data is causing the program to hang or crash.

If more than one port is to be logged then different files should be used for each. It is probably better to avoid file names starting with COM as Windows has a penchant for treating these oddly.

Here's an example EW Windows Uploader.ini file which will log the first two "normal" serial ports to files in the root directory of the C: drive.

[LogFiles]
COM1=C:\Port1.log
COM2=C:\Port2.log

If as much data as possible is wanted, in the face of program crashes or hangs, then this might be used:

[LogFiles]
COM1=C:\Port1.log
COM2=C:\Port2.log
Paranoid=1

The .INI file entries relevant to each port (COM<n> and Paranoid) are read each time the port is opened. Therefore logging for a port can be turned on or off in mid-session by updating the .INI file, closing the port and reopening it. The log file is opened for write deleting any existing file the first time in each program run, then opened for append on subsequent occasions.

Log File Format

First an example, communication with an EW Model B:

COM1 --- Port handler created
COM1 --- Port opened
COM1 <-- <>
COM1 <-- <>
COM1 <-- <>
COM1 <-- <>
COM1 <-- <>
COM1 --> <18>
COM1 <-- <>
COM1 --> <18>
COM1 <-- <>
COM1 --> #
COM1 <-- <>
COM1 --> #
COM1 <-- <>
COM1 --> <CR>
COM1 <-- <>
COM1 <-- <>
COM1 --> <18>
COM1 <-- <>
COM1 --> <18>
COM1 <-- <>
COM1 --> #
COM1 <-- <>
COM1 --> #
COM1 <-- <>
COM1 --> <CR>
COM1 <-- <>
COM1 <-- <>
COM1 --> <18>
COM1 <-- <CR><LF>
COM1 <-- EW Barograph - Main Menu<CR><LF>
COM1 <-- 1.  Print trace.<CR><LF>
COM1 <-- 2.  List traces.<CR><LF>
COM1 <-- 3.  Delete last trace.<CR><LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <18><CR><LF>
COM1 <-- <CR><LF>
COM1 <-- EW Barograph - Main Menu<CR><LF>
COM1 <-- 1.  Print trace.<CR><LF>
COM1 <-- 2.  List traces.<CR><LF>
COM1 <-- 3.  Delete last trace.<CR><LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <>
COM1 --> 2
COM1 <-- 2<CR><LF>
COM1 <-- No   Date     Start    End    SI User<CR><LF>
COM1 <--  1 03-05-21 16:41:03 16:41:03 12 0<CR><LF>
COM1 <-- Enter main menu selection (0 for list)<CR><LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <>
COM1 --> 1
COM1 <-- 1<CR><LF>
COM1 <-- Enter number of trace (0 for list, 99<CR><LF>
COM1 <-- for last trace) then press Enter<CR><LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <>
COM1 <-- <>
COM1 --> 1
COM1 <-- <>
COM1 --> <CR>
COM1 <-- 1<CR><LF>
COM1 <-- Print trace numerically? <CR><LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <LF>
COM1 <-- <>
COM1 --> Y
COM1 <-- Yes<CR><LF>
COM1 <-- Print trace graphically? <CR><LF>

Each line starts with the name of the port concerned followed by a "direction indicator":

---
Message about program actions other than bytes sent or received.
<--
Bytes received from the logger through the serial port.
-->
Bytes sent to the logger through the serial port.

This is followed by a space then the data actually sent or received which is encoded as followes: printable US-ASCII characters other than < and > are represented by themselves and all other bytes are represented by a code in angle brackets. Certain particularly interesting characters are represented by two or three letter/digit names, the remainder by two digit hexadecimal values. The "interesting" characters are:

Byte (Hex) Character Representation
01 SOH * <SOH>
02 STX * <STX>
03 ETX <ETX>
04 EOT <EOT>
06 ACK <ACK>
0A LF <LF>
0D CR <CR>
0F SI <SI>
12 DC2 <DC2>
3C < <LT>
3E > <GT>

* The characters here called SOH and STX are listed in Unicode as STX and SOT respectively, even though the first of these is called START OF HEADING there.

Actually, some of these characters are not particularly interesting for communication with EW's gliding loggers but they are in the case other closely related, non-gliding, software. The CAN (18 hex, cancel) character could also usefully be on this list, but isn't.

The notation <> (i.e., an empty angle bracket pair) is used to indicate a time-out on reception from the logger.

Lines are broken when the direction of communication changes, when the line length has got long enough and after the transmission of a byte with the value 0A hex (i.e., line feed).

Here's some sample data of an XModem upload (actually, not from EW Windows Uploader but from related software from a logger with a different format for traces, but the general principle's the same) to show the representation of more binary byte values:

COM1 --> <18><18>#LST4B<CR><LF>
COM1 <-- 03<CR><LF>
COM1 --> <ACK>
COM1 <-- 000467027FFF00047E0101010000100101010000150000<CR><LF>
COM1 --> <ACK>
COM1 <-- 00047E007FFF0004950101010005340101010005380000<CR><LF>
COM1 --> <ACK>
COM1 <-- 000495017FFF0004AC01010B00142201010B0014270000<CR><LF>
COM1 --> <18><18>#RID5F<CR><LF>
COM1 <-- 0303G0021<CR><LF>
COM1 --> <18><18>#XMU0040<CR><LF>
COM1 --> C
COM1 <-- <SOH><SOH><FE><STX><7F><FF><00><EOT>~<SOH><SOH><SOH>
COM1 <-- <00><00><10><SOH><SOH><SOH><00><00><15><00><00><FF>
COM1 <-- <F2><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00><00><00><00><00><00><00><00><00><00><00>
COM1 <-- <00><00><00>i<SI>
COM1 --> <ACK>
COM1 <-- <EOT>
COM1 --> <ACK><18><18>#GRC56<CR><LF>
COM1 <-- 01010B001723<CR><LF>

Each command is prefixed by a pair of Cancel (CAN) characters (<18>) to deal with the case of a logger being connected already in XModem transfer mode.

In this example the computer sends a LST command to obtain a list of traces in the logger. The logger replies first with the count of traces (03) then, after the computer sends an Acknowledge (<ACK>) character, details of each of the traces in turn.

The computer then requests the logger's serial number with an RID (Read Identification) command and gets that back, "0303G0021". It then sends an XMU (XModem Upload) command requesting that the trace be uploaded using the standard XModem protocol. It then sends the letter "C" requesting the first packet of the file and indicating that 16-bit CRCs are to be used for error checking.

The logger then replies with the first (and only) packet of this short trace. In this case, most of the bytes are not printable US-ASCII values; the exceptions being a byte with the value 7E (hex) which shows as ~ in the first line and the first byte of the checksum which has the value 69 (hex) which shows as i in the last line of the packet.

This packet illustrates an important point regarding the interpretation of these log files. The first byte of an XModem packet is always an SOH character - it really is the start of header (well, start of a packet, anyway). The second byte is the sequence number of the packet. For the first packet of the trace this has the value one which is also the byte code for the SOH character so it gets logged as <SOH>. The string used to represent, in the log file, a byte sent or received is only dependent on the byte's value, not its meaning.

The computer acknowledges the packet with an ACK character. The logger then sends an EOT to indicate the end of the transfer. If the trace was large enough for more than one packet, the second packet would be sent instead. Finally the computer sends a GRC (Get Real Time Clock) command which the logger responds to with the date and time in the form of six bytes represented as 12 hex digits, containing the year (0..99, 01 in this case), month (1..12, 1 here), day (1..31, 0B hex which is 11 decimal), hour (0 to 23, zero here), minute (0 to 59, 17 hex which is 23 decimal) and the second (0 to 59, 23 hex which is 35 decimal). Note that as these bytes are sent as pairs of hex characters they are shown in US-ASCII here.