Multiplexer serial port card on Linux server to connect HP dumb terminals

[Celio Correia]

We have a HP ProLiant ML570 running Red Hat Linux 4 and we installed a Perle UltraPort16 SI PCI serial multiplexer card that we'd like to use to connect our legacy HP 700/70 dumb terminals using CAT5 cables in order to allow access to a console based application.

The network cabling in the building is UTP/CAT5 and that is why we have chosen the RJ45 type connection for the UltraPort16 card. The HP 700/70 terminals which are configured in VT220/19200bps are connected through a RS422/DB-25 port, thus a converter is used in order to connect the RJ45/UTP cables from the Perle card to the RS422/DB-25 port on the HP terminal.

We have been given the pin-out schema below and we have set up a DB-25/RJ45 converter accordingly but a connected HP terminal does not output the login screen correctly.

Converter pin-out schema:

Ultra RJ45 10-pin DB25 HP terminal

3 (txd+) --------------- rxd+ 3
5 (txd-) --------------- rxd- 18
6 (rxd+) --------------- txd+ 9
8 (rxd-) --------------- txd- 10

7 (sgnd) -------------- sgnd (optional)

I have checked the /proc/tty/driver/perle-serial file and it does show TX/RX activity on the port on which the terminal is connected:

Serinfo:1.0 driver:3.3.0 revision:2006-07-28
0: uart:XR16L788 port:4400 irq:209 baud:19200 tx:517 rx:243 few:118 brk:125 RTS|DTR
1: uart:XR16L788 port:4410 irq:209 baud:19200 tx:200 rx:0 RTS|DTR
2: uart:XR16L788 port:4420 irq:209 baud:19200 tx:100 rx:0 RTS|DTR
......

However, only weird characters are output on the terminal's screen.

Here's the inittab file contents:

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
7:2345:respawn:/sbin/agetty ttyS0 19200 vt220
8:2345:respawn:/sbin/agetty ttyPS0 19200 vt220
9:2345:respawn:/sbin/agetty ttyPS1 19200 vt220
......

All ports are configured for RS422 using the Perle's configuration command:

setultrap -f /dev/ttyPS0,/dev/ttyPS15 -m 422

What are we missing?

Please check the attachment for more information on the problem.


Thank you very much for your help.

[Ivan Ferreira]

>>> However, only weird characters are output on the terminal's screen.


Are you sure you specified correctly the line speed according to you terminal settings?

[Celio Correia]

Yes, I've checked that the terminal is configured for 19200bps.

Thanks.

[Luk Vandenbussche]

Your baudrate is important but also the number of bits (7/8), the stop bit (0/1) and the parity bit (even/odd/none)

[Celio Correia]

I think everything is correct but how do you set that on RH Linux?

[Celio Correia]

I have seen man for agetty and I'm wondering if the agetty is configured properly.

What do you think?


EXAMPLES
This section shows examples for the process field of an entry in the /etc/inittab file. You'll have to prepend appropriate values for the other fields. See inittab(5) for more details.

For a hard-wired line or a console tty:
/sbin/agetty 9600 ttyS1

For a directly connected terminal without proper carriage detect wiring: (try this if your terminal just sleeps instead of giving you a password: prompt.)
/sbin/agetty -L 9600 ttyS1 vt100

For a old style dial-in line with a 9600/2400/1200 baud modem:
/sbin/agetty -mt60 ttyS1 9600,2400,1200

For a Hayes modem with a fixed 115200 bps interface to the machine: (the example init string turns off modem echo and result codes, makes modem/computer DCD track modem/modem DCD, makes a DTR drop cause a dis-connection and turn on auto-answer after 1 ring.)
/sbin/agetty -w -I 'ATE0Q1&D2&C1S0=1\015' 115200 ttyS1

[Stuart Browne]

Something to check.. If you hit 'enter' on the terminal, do you get the same garbage repeated?

If you echo something down the TTY repeatedly, do you get the same garbage?

If you do for either of these, then you've got either a baudrate mismatch, or an emulation mismatch (although with the latter, you should get more sensical stuff out, just not laid out pretty).

If you don't, and it's truely garbage which is in no way associated with what should be displayed, then you've got a wiring issue.

The other thing you'll want to double check is the flow-control. With so few pins, you're not using hardware, so ensure you've got the port set up for xon-xoff (software) flow control.

Whilst I could find the pin-out of the serial boxes, I couldn't find the pinouts for the HP 700/70's (I don't have a manual handy either), so I couldn't verify the pinnings. I'll check the car boot tomorrow for the documentation CD I've got floating about, i'm pretty sure it has 700/60 docco's on it which should be the same.

[Celio Correia]

When I hit enter on the terminal I either get garbage again or "?" characters.

- How do I echo something into the TTY?

- How do I check if I have the port set to Xon Xoff ?

Thanks.

[Steven Schweda]

> The other thing you'll want to double
> check is the flow-control.

Bad flow control won't cause a few manually
sent characters to come back as garbage.

Can you describe the garbage better?

There are times when the simplest thing to do
is hook up an oscilloscope, which can provide
information on speed and signal quality.

First, lacking a 'scope, I'd probably try to
find a voltmeter, and check that each TXD is
really talking to an RXD, not to another TXD.
Sometimes there can be enough crosstalk on a
cable that a sensitive receiver will see
(faint) garbage when its input is floating,
especially with a long cable.

How long is your cable, by the way?

If no real test equipment is available, you
could try constructing a loop-back connector
or cable (TXD <-> RXD) with which you could
verify that the terminal can talk to itself,
first on a short cable, then, if that works,
on your real cable. From the other end, you
could use "cu", or "tip", or whatever you
have, to do the same kind of check from the
computer end.

You can also try conecting what you think are
the two TXD's together (and the two RXD's),
to see if you really needed a null-modem
cable in the first place. It's not as
satisfying as measuring the voltage, but it
could be informative. (I believe that these
things are designed not to destroy each other
when connected backward.)

If both the terminal and the computer can
talk to themselves over the real cable, and
if the wiring is really right, then a speed
(or parity) difference is the most likely
remaining problem. Have you tried all the
terminal's speed (and parity) choices? (I
assume that it's easier to change the
terminal's settings and be confident that you
know what they are than it is on the computer
end.)

[Rob Leadbeater]

Hi,

Looking at the manual for the Perle card here:

http://www.perle.com/support_services/documentation_pdfs/5500152.pdf

would suggest that the pinouts that you're using on the RJ-45 end are wrong. Take a look at the table on page 124. (I think there's a misprint there though - the 4th column should I guess be EIA-422 which you need).

Also note that if you're using standard CAT-5 then you need to be looking at the RJ-45 8 pin, not 10 pin.

Also bear in mind that the unshielded nature of UTP, could be catching you out - although I'm assuming in your testing that you're using a short patch lead between the Perle and the terminal which shouldn't cause problems.

Hope this helps,

Regards,

Rob