hoffman%pitt@csnet-relay.arpa (08/13/85)
From: Bob Hoffman <hoffman%pitt@csnet-relay.arpa>
I can't believe that I'm the first to find this, but I haven't seen mention
of this problem on any of the nets I monitor. In fact, I'm a bit embarrassed
that it's taken me 18 months to notice it!
The problem was: While my computer terminals would work just fine with my
TNCs, I had problems when I connected my computer. The computer is a DEC
LSI-11, and the interface used is the DLV11-E, which is a full-modem-control
interface. When the computer was connected, no data would flow. The
confusion was compounded when I inserted a breakout box between the TNC
and the computer -- it started working! Remove the box -- no data flow.
Last night, I found the cause: When TAPR designed the TNC, they wired the
Carrier Detect (CD, pin 8) as an INPUT! This is completely wrong for an
RS232 DCE. It turns out that my terminals have no connection to the CD
pin, therefore the pullup resistor on the TNC supplies a high level, allowing
the data to flow. The DLV11-E, on the other hand, does use pin 8, also as an
input. With both CD inputs in parallel, the pullup resistor is insufficient to
insure a high enough level. The TNC (actually the 6551) sees CD negated, and
no data flows. Regarding the breakout box, my guess is that inserting the box
somehow raised the voltage on pin 8 to a point where it would work.
The quick fix is to jumper pins 8 and 20 on the TNC. This makes the DTR
signal from the terminal drive both DTR and CD on the TNC. This works OK.
Another fix I have considered is to take the "connected" status line from
the parallel port (DB25P pin 16) and run it through an RS232 driver to pin
8. Then, the CD line acts like you would want it to when running a BBS.
Is there something I may have missed here? Why would TAPR design their board
this way? Your comments are appreciated.
--------
73,
Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science hoffman%pitt@csnet-relay