EW Logger Models A to D Hardware Handshaking

Introduction

This page provides background information on the hardware handshaking used between the EW models A, B and D loggers with various versions of the EWView/DOS and EW Windows Uploader software.

The information for the A and B loggers would also apply to C and F models. Similarly, the information for the D would presumably apply to any E models in existence.

Any inferences regarding the behaviour of other software (such as the Microsoft Windows programs EWView II or III or Naviter's SeeYou) or that provided by other sources is up to the reader. This information is, of course, totally inapplicable to the more recent EW microRecorders.

Signal Levels

For ease of reference and to clarify terminology for further discussion here are the signal levels for RS-232 as used on this interface.

Voltage Negative Positive
State Marking Spacing
Data One Zero
Control Off On
TTL 1 0
LED Red Green

The Data row indicates the interpretation of the two voltage ranges on the data lines, that is transmit data (TxD) and receive data (RxD). Control indicates the interpretation on the control signals, such as data terminal ready (DTR). Note that, slightly surprisingly, one on the data lines is represented by the same voltage range as off on the control lines.

The TTL row gives the logic levels which correspond to the voltage ranges using the industry-standard style of RS-232 to 5V TTL logic signal converters, including those used internally in these EW flight recorders. These converters act as voltage inverters which is "the right way up" for data signals but logically inverted for control signals.

LED indicates the LED illumination on my RS-232 break-out box. I suppose there's a slightly better than 50% chance that yours are the same.

Pin Outs

Again for convenient reference, here are the pin-outs for the relevant RS-232 signals.

Signal EW 9 pin ("AT") 25 pin RS-232
Receive Data (RxD) 2 2 3
Transmit Data (TxD) 3 3 2
Ground (Gnd) 5 5 7
Request to Send (RTS) 7 7 4
Clear to Send (CTS) 8 8 5
Data Terminal Ready - 4 20

Printers

When the EW Barograph was first produced there was no associated computer software; all output of traces was done to a printer, typically Epson-compatible Seiko thermal printers. These provided a signal on the DTR line (pin 20 of a 25-pin connector) to indicate that they were ready to accept more characters (on/positive/TTL 0) or busy with the input buffer full or nearly full (off/negative/TTL 1). This was therefore what was used by the Barographs for flow control.

Actually, prototype Barographs also supported the use of the XOn/XOff protocol for flow control. As the software was finalized there was a shortage of memory and this function, not then being used, was taken out to free up a few bytes. This has long been a source of regret.

The line on the barograph to which this DTR signal was connected was pin 8 (CTS) and this has remained the handshake input since.

Flight Recorder Behaviour

In general, the behaviour of the FRs is to check the CTS (clear to send) signal just before sending each byte. If CTS is high (i.e., TTL 1, corresponding to an RS-232 Off control signal state) the code loops until it is low (TTL 0, RS-232 On control signal state).

In both loggers there are two routines related to sending bytes: PrintByte used for most transmission and XModemSendByte used for sending bytes via the XModem protocol (except, of course, A & Bs earlier than about version 9305 which don't implement XModem).

A & B FR Behaviour

In all available versions the code for the A & B FRs the PrintByte routine checks for CTS being On. While it is looping waiting for CTS to come On (and for the transmit data register to be empty, i.e., for the serial port to be ready to accept another character) it checks for the keyboard being pressed. If the Off key is pressed it abandons the byte transmission.

In all the available versions in which it is implemented (basically 9503 and later) the XModemSendByte routine checks and waits for CTS to be On. It does not, however, check the keyboard while waiting so in the case of a broken or not-connected CTS wire it would hang indefinitely. It's probably a good thing that the XModem protocol for this model is not normally used.

D FR Behaviour

The following information is based on the source code for this logger which I have available. It is labelled version "9942" but the file name is 9942x.asm so, though it is clearly very nearly the released version, I'm not certain it is absolutely the final code.

The PrintByte routine has the check for CTS commented out. Therefore it does not check the state of the CTS signal and will send bytes even if this signal is Off.

The XModemSendByte routine, on the other hand, does check CTS, requiring it to be On for transmission. I don't know if this difference was deliberate because of the XModem packets are longer than other responses sent by the logger or if it's just an oversight. The wait code does not check for the device's off button being pressed but does have a timeout to prevent indefinite hangs.

EWView/DOS

EWView/DOS uses the serial port directly; it accesses the UART registers and hooks into and handles hardware interrupts directly. In the DOS days this was the only way to get properly responsive handling of flow control.

As far as I can see from the available versions of the code (starting with code dated late 1992/early 1993) no version of EWView/DOS applies any flow control to characters sent to the logger. Characters are, for the most part, sent immediately the computer's UART transmit buffer is empty. However, in the case of the A & B loggers a short delay is inserted after each digit of a trace number sent to the logger when selecting the trace to upload; this is the only case where messages with more than two characters are sent to the logger which might not be processed by the logger quickly enough to avoid an overrun error in the logger's receive buffer.

For flow control of characters from the logger to the computer the operation evolved slightly during the lifetime of the program so the different versions are discussed separately below.

Original EWView/DOS

Versions of EWView/DOS up to and including 9824A (i.e., mid-summer 1998), and perhaps one or two versions immediately after that, simply asserted (set to on) the DTR signal when they were ready to receive characters from the logger and de-asserted DTR when their internal buffer was nearly full.

RTS is asserted when the serial port is first used and left asserted through-out the operation.

The only known change in these versions was that early ones used a buffer size of 200 bytes and de-asserted DTR when the empty space got down to 20 bytes then reasserted DTR when the number of bytes waiting to be processed dropped to 20. Later versions increased the buffer size to 300 bytes and set the corresponding margins to 100 bytes.

Later EWView/DOS

The early versions described above worked fine in a pure DOS environment. However, when run in DOS-emulation under Windows there was a problem. I'm not sure which Windows versions it applied to; from the date code discussed below it's tempting to assume Windows 98 but I suspect it actually applied to earlier versions, probably Windows 3.11 and onwards.

The problem was that the Windows virtualization intercepted the direct accesses to the UART registers and redirected them as calls to its internal serial port drivers. Because of the general latency of operations introduced by the multitasking Windows environment this introduced an extra level of buffering. Presumably in an attempt to hide this in the case where the serial port is used to communicate with a standard modem the drivers "helpfully" cleared out the receive buffer every time EWView/DOS de-asserted the DTR signal (that being the normal way to indicate to a modem that it should "hang-up" the telephone connection). The consequence was that every time EWView's input buffer nearly filled up received characters were lost.

(My recollection is that this was not typically a problem until large traces were uploaded unless the computer was particularly slow.)

To work around this problem EWView/DOS was changed to have the option of using the RTS signal instead of the DTR signal for flow control. Version 9845A (autumn 1998) has this option. Maybe one or two versions before that also had this capability, but not 9824A or before.

This option is accessed from the main window using ConfigurationUpload:

The choice between DTR and RTS handshake is made using the menu option shown expanded.

Of course, this meant the use of a differently wired upload lead. What I'm not sure about is how many people actually did this. There was a pretty strong prejudice against Windows at that time with regard to competition scoring in the UK and FAI badge and record claim processing so maybe it was not many.

Whichever handshake signal was selected (DTR or RTS) the other was left asserted irrespective of the flow control operation required.

EW Windows Uploader

EW Windows Uploader is a 32-bit Windows program designed for use on Microsoft Windows 95 and NT 4.0 and later. As such it does not do the direct UART access which EWView/DOS does but rather accesses the serial port via the standard Windows API CreateFile function and the associated file-level serial-port-specific functions like SetCommState and SetCommTimeouts.

Late in the development of this program a bug/gotcha was found in versions of Windows 95 and its derivatives (98 and ME) but not NT 4.0 and its derivatives (2000, XP, ...). This is related to handshaking and described in 32bit Windows Serial Port Bug.

The initial approach taken with EW Windows Uploader (that is, with versions up to and including 0428A) was to use both the DTR and RTS signals for receive flow control. In that way the program would work with either the original type of upload cables intended for DTR operation or with ones modified for RTS signalling for EWView/DOS under Windows.

USB Problem

The versions of EW Windows Uploader which used both DTR and RTS for flow control worked perfectly satisfactorily on real serial ports and on some USB-to-serial adaptors including (perhaps unfortunately) my own Belkin F5U103. However, it was pretty rapidly found that they did not work with some USB-to-serial adaptors but it was difficult to track down either what aspect of the adaptors or what behaviour(s) of the program were incompatible.

The general advice is to find an adaptor which works and stick with it. To this end EW sells a known good adapter.

In 2005 June I borrowed a USB adaptor which gave problems from Jim White and made various modifications to the Windows Uploader code to see what was causing the problem. What I found was that setting the RTS signal for handshake (dcb.fRtsControl = RTS_CONTROL_HANDSHAKE;) caused the problem whereas simply asserting RTS (dcb.fRtsControl = RTS_CONTROL_ENABLE;) worked fine.

It seems that certain USB-to-serial drivers misinterpret the RTS_CONTROL_HANDSHAKE setting to mean use the RTS and CTS signals to control transmission from the computer.

Experimental Fix

I therefore produced an experimental version (0523X) which set RTS_CONTROL_ENABLE and released that with a request for feedback on how well it worked.

However, that was not a good solution for anybody using a lead set up for EWView/DOS under Windows with the RTS line connected for handshaking. I therefore continued to recommend the previous main version (0330A) for everybody except those having problems with USB-to-serial adapters.

Permanent Fix

While awaiting feedback on the usefulness of that I produced another version (0525X) intended to be a long-term solution to the problem: able to work with buggy USB-to-serial adapters and with upload leads wired for RTS handshake though not the two together, of course.

This version makes the use of RTS handshaking on a particular port optional. DTR handshake is active whatever the setting. If RTS handshaking is not selected then the RTS line is asserted when the port is opened and is left asserted through-out the operation.

The program-wide default is to not use RTS for handshaking. This can be overridden by the manufacturer specific command line switch -xr which indicates the use of RTS handshaking for the port(s) opened when the program starts and as the default option for any ports opened manually during program operation.

The use of RTS handshaking on individual ports can also be controlled by a check box on the Open Port dialog box.

Checking this box enables the use of the RTS signal for handshaking. Unchecking it causes the RTS signal to be asserted but not used for handshaking.

The choice was between activating RTS handshake by default thereby breaking things for users with bad USB-to-serial adapters or deactivating RTS handshake and breaking things for users with leads wired for RTS handshake. The decision was made to leave RTS handshake deactivated by default because it was thought that more people would have bad USB-to-serial adapters and also because those with leads wired for RTS handshake would likely to be experienced users who would work out what the problem was quicker.

A little feedback on the 0523X version was received - none indicating that the basic premise of the experimental fix was wrong. However, there were no apparent problems with the two versions of the code (other than that it's messy for people to have to choose between the two) so there was no particular motivation to get the combined version (0525X) out the door (other than any temporary versions for special purposes - 0526Z appears to be the only one).

EW Windows Uploader version 1019A

Version 1019A implements changes to support setting declarations for Model D loggers from programs like TaskNAV. It's based on the 0523X version so incorporates the RTS handshake changes described above.

For most users most of the time there's no need to do anything special. Do not specify the -xr command line switch and leave the Enable RTS Handshake check box on the Open Port dialog box unchecked. This should work with all real serial ports and known USB-to-serial adaptors.

However, it will not work if the upload lead is wired for RTS handshaking. In that case, use the -xr command line switch or open/reopen any serial ports used setting the Enable RTS Handshake check box. This should work with all real serial ports and those USB-to-serial adaptors which correctly implement the RTS_CONTROL_HANDSHAKE setting.

It is not possible, and never has been possible, to use a lead wired for RTS handshake with a USB-to-serial adaptor with a faulty implementation of RTS_CONTROL_HANDSHAKE. The options are to get a known good USB-to-serial adaptor or rewire the lead for DTR handshake.

The only known adverse effect of changing the lead to DTR handshake is that it will break operation of EWView/DOS when run under Windows.