DEC VT420 no hardware flow control?

[Matthias Czapla]

Hi!

Does the VT420 really not support hardware flow control? The manual seems
to suggest this. Maybe there is an undocumented pin on the DB-25 connector
for this?

Regards
Matthias

[Keith F. Lynch]

Post by Matthias Czapla
Does the VT420 really not support hardware flow control?

The VT420 does support hardware flow control.

Post by Matthias Czapla
The manual seems to suggest this. Maybe there is an undocumented
pin on the DB-25 connector for this?

What DB-25? It uses a six pin DEC-423 connector instead. Pins 1 and
6 provide the hardware flow control in each direction. (2 and 5 are
data each way, 3 and 4 are ground.)

[Matthias Czapla]

Post by Keith F. Lynch

Post by Matthias Czapla
Does the VT420 really not support hardware flow control?

The VT420 does support hardware flow control.

Good to hear :)

Post by Keith F. Lynch

Post by Matthias Czapla
The manual seems to suggest this. Maybe there is an undocumented
pin on the DB-25 connector for this?

What DB-25? It uses a six pin DEC-423 connector instead.

There are three different versions of the VT420 (North American, worldwide
and worldwide with PC TERM mode) according to the Service Guide. The NA
version has only two DEC-423 connectors but the worldwide model has an
additional DB-25 connector that can be used instead of the first DEC-423.

Allthough I looked very hard I cannot find a supplier of the DEC-423
plugs so Im left with the DB-25 connector. I connected the terminal's
DTR pin to the CTS pin of the host's serial interface, enabled RTS/CTS
hardware flow control at the host and disabled Xon/Xoff flow control.
But it doesnt work (i.e. produces garbage after certain amount of
characters have been received).

I noticed that there is an option "Modem Control" in the "Comm"
directory of the VT420's setup, however when I enable it the terminal
stops responding and displays "Waiting" in its indicator line. I
guess this is because the modem control lines are not connected.
Im not sure what pins have to be shorted in order to trick the
terminal into thinking that there is a modem connected. Can somebody
give me a clue please?

Regards
Matthias

[Skipper]

You have mixed up the actual signaling of the pins. The following
represents the hardware handshaking signals for a DTE device (Data
Terminal Equipment, like a computer or terminal):

RTS ==> Ready to Send (DB25 pin 4)
- terminal raises this to signal that it has data ready;
primary hardware flow control
CTS <== Clear to Send (DB25 pin 5)
- terminal listens to this to see if connected device is ready
to accept data; if not raised terminal must pause output;
primary hardware flow control
DTR ==> Data Terminal Ready (DB25 pin 20)
- terminal raises this to indicate that is has powered up,
initialized, and is ready to begin communicating (stays on)
DSR <== Data Set Ready (DB25 pin 6)
- terminal listens to this to see if connected device is powered
up and initialized; must stay on for communications; is usually
ignored in most UNIX drivers, though some drivers can option
this in
CD <== Carrier Detect (DB25 pin 8)
- terminal listens to this to see if connected device has made
any protocol negotiation and is now satisfied how to communicate;
most device drivers depend heavily on this to indicate that a
connection is "up" or "down"

When connecting a terminal to a computer you want to connect the DTR
signal to both the DSR and CD of the other side. This tell both devices
that the other is powered on and communicating. Hardware flow control
then depends on the RTS and CTS signaling -- RTS of one side is connected
to the CTS of the other.

True RS232 null-modem connections are this:

TX ==> RX \
RX <== TX / data pair

RTS ==> CTS \
CTS <== RTS / handshaking pair

DTR ====> DSR \
\==> CD \
DSR <==== DTR / connection conformation pair
CD <==/ /

Gnd === Gnd - and of course you can't forget ground

You'll find this is true for printers, computers, terminals, barcode
readers -- any two DTE devices connected together.

Post by Matthias Czapla

Post by Keith F. Lynch

Post by Matthias Czapla
Does the VT420 really not support hardware flow control?

The VT420 does support hardware flow control.

Allthough I looked very hard I cannot find a supplier of the DEC-423
plugs so Im left with the DB-25 connector. I connected the terminal's
DTR pin to the CTS pin of the host's serial interface, enabled RTS/CTS
hardware flow control at the host and disabled Xon/Xoff flow control.
But it doesnt work (i.e. produces garbage after certain amount of
characters have been received).
I noticed that there is an option "Modem Control" in the "Comm"
directory of the VT420's setup, however when I enable it the terminal
stops responding and displays "Waiting" in its indicator line. I
guess this is because the modem control lines are not connected.
Im not sure what pins have to be shorted in order to trick the
terminal into thinking that there is a modem connected. Can somebody
give me a clue please?
Regards
Matthias

[Matthias Czapla]

Post by Skipper
You have mixed up the actual signaling of the pins. The following
represents the hardware handshaking signals for a DTE device (Data
RTS ==> Ready to Send (DB25 pin 4)
- terminal raises this to signal that it has data ready;
primary hardware flow control
CTS <== Clear to Send (DB25 pin 5)
- terminal listens to this to see if connected device is ready
to accept data; if not raised terminal must pause output;
primary hardware flow control
DTR ==> Data Terminal Ready (DB25 pin 20)
- terminal raises this to indicate that is has powered up,
initialized, and is ready to begin communicating (stays on)
DSR <== Data Set Ready (DB25 pin 6)
- terminal listens to this to see if connected device is powered
up and initialized; must stay on for communications; is usually
ignored in most UNIX drivers, though some drivers can option
this in
CD <== Carrier Detect (DB25 pin 8)
- terminal listens to this to see if connected device has made
any protocol negotiation and is now satisfied how to communicate;
most device drivers depend heavily on this to indicate that a
connection is "up" or "down"
When connecting a terminal to a computer you want to connect the DTR
signal to both the DSR and CD of the other side. This tell both devices
that the other is powered on and communicating. Hardware flow control
then depends on the RTS and CTS signaling -- RTS of one side is connected
to the CTS of the other.
TX ==> RX \
RX <== TX / data pair
RTS ==> CTS \
CTS <== RTS / handshaking pair
DTR ====> DSR \
\==> CD \
DSR <==== DTR / connection conformation pair
CD <==/ /
Gnd === Gnd - and of course you can't forget ground
You'll find this is true for printers, computers, terminals, barcode
readers -- any two DTE devices connected together.

Well, very interesting. Thank you! But my Wyse 160 definitely uses the
DTR pin to signal the host that it is ready to receive more data. Even
the entry in the setup menu is called "DTR" (other choices being
"Xon/Xoff" and "Both"). But if the VT420 uses RTS instead it's obvious
why my DTR->CTS cable does not work :)

Has the terminal to be set to "Modem Control" (as opposed to "Data Leads
Only") for hardware flow control? I guess so. Will try out tomorrow...

Regards
Matthias

[Matthias Czapla]

Post by Skipper
You have mixed up the actual signaling of the pins. The following
represents the hardware handshaking signals for a DTE device (Data
RTS ==> Ready to Send (DB25 pin 4)
- terminal raises this to signal that it has data ready;
primary hardware flow control
CTS <== Clear to Send (DB25 pin 5)
- terminal listens to this to see if connected device is ready
to accept data; if not raised terminal must pause output;
primary hardware flow control
DTR ==> Data Terminal Ready (DB25 pin 20)
- terminal raises this to indicate that is has powered up,
initialized, and is ready to begin communicating (stays on)
DSR <== Data Set Ready (DB25 pin 6)
- terminal listens to this to see if connected device is powered
up and initialized; must stay on for communications; is usually
ignored in most UNIX drivers, though some drivers can option
this in
CD <== Carrier Detect (DB25 pin 8)
- terminal listens to this to see if connected device has made
any protocol negotiation and is now satisfied how to communicate;
most device drivers depend heavily on this to indicate that a
connection is "up" or "down"
When connecting a terminal to a computer you want to connect the DTR
signal to both the DSR and CD of the other side.

So I made this cable where TX/RX and RTS/CTS are wired in a cross over
fashion. Then I connected the terminal's own DTR to it's own DSR and CD.
Like this:

Terminal Host
TX (2) ---> RX (3)
RX (3) <--- TX (2)
RTS (4) ---> CTS (5)
CTS (5) <--- RTS (4)
GND (7) <--> GND (7)
DSR (6) <-.
DCD (8) <-|
DTR(20) --'

getty is set to "local mode" and to enable RTS/CTS flow control.
But the result is not satisfying. After a few pages of cat'ed text
the terminal starts displaying garbage. The "dpa" utility for my
Digi AccelePort serial card (which monitors the state of the pins)
also never indicates that CTS is negated and probing with a voltmeter
confirms this - the RTS pin on the terminal constantly stays at
+5.5 Volts. But I don't know if the time interval where it's negated
is just too short to be recognized.

But what's even more strange is that previously with software flow
control I could send plain text to the terminal without problems at
19200 bps but curses-based apps made problems. Now it's exactly the
opposite, curses-based apps seem to work flawlessly so far but
directory listings, cat'ing text files etc. reliably produce garbage.

Please help! This VT is so much nicer than the (working) Wyse 160 ;)

Regards
Matthias