Testing server serial port?

[NetGear]

Hi,

We have a HP Proliant server and it seems that there is some kind of a
problem with the serial port.

The server is used to control quite a large CCTV camera system and after a
system crash it seems that some of the camera movement functions are not
working. I think there must be a problem with the integrated com port.

Is it possible to test the port with some easy way?

 

[Dusko Savatovic]

Well, I remember that in the old days I had a diagnostic program that ran
from MS-DOS diskette. I also had a loopback plug, so that it would test the
RS232 handshake signals as well.

MS-DOS 6 had two programs InterSvr and InterLnk. You would start InterSvr on
one computer and InterLnk on another. You would connect two computers with
parallel data cable or serial null modem cabel. After you establish
connection, you could transfer files between computers. So if you've got two
computers, a null modem cable and MS-DOS 6 diskette with two mentioned
programs, you can easily do your test.

If you have an external modem, you can connect a modem to your COM port
using your modem cable. You can then test your modem from Windows, or you
can issue simple 'AT' commands using HyperTerminal (part of Windows 2003).

If you have an old dot matrix printer, they were usualy equipped with serial
port. You can connect a printer to serial port. Again MS-DOS diskette is
your friend you can simply copy a text file autoexec.bat or config.sys to a
COM port. for example:

copy autoexec.bat COM1:

Note. Laser and InkJet printers are generally not good for this sort of
test because they are page (not line) printers. So, to print a page you
would have to send a FormFeed character.

You can also find some comms equipment that (still) use COM ports. For
example I have an old Wireless Access Point that does initial config
(password reset) using COM port. I attach it to my PC using null modem cable
and HyperTerminal.

BTW, as I write this post, I don't find HyperTerminal on my Vista. However,
you can download many freeware terminal emulators, for example PuTTY. PuTTy
works on Win32 systems.

 

[NetGear]

Thank you very much. I think that this would not the best method for
testing, however.

There are eight directions that the cameras can be pointed using the camera
control software and joystick. Seven of them work. One direction stopped
working after the system crash.

Maybe it would be easiest to disable the internal com port and buy a cheap
add-on serial port card and test with it first.

 

[Meinolf Weber [MVP-DS]]

Hello NetGear,

If you think it is hardware related i would get in contact with HP support.
Was it a hardware crash or software? When hardware maybe the drivers are
not that actual, make sure you have the latest versions installed. If software
i think this will be more related to the software then to the port itself.
Therefore i would talk to the software vendor.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm

 

[Dusko Savatovic]

Hm, I was under impression that your COM port was totally unresponsive.
However, if seven out of eight directions work, I would not assume there's
anything wrong with the physical COM port. COM port is rather simple. You
have transmit, receive lines and a few control lines. If you're able to send
commands for seven directions, there's no reason why the eighth would not
work (from the COM port perspective).
Anyway, it's easy to add a new card with a COM port and eliminate it as a
source of the problem.
Go ahead and good luck.

 

[Andrew Morton]

There are eight directions that the cameras can be pointed using the
camera control software and joystick. Seven of them work. One
direction stopped working after the system crash.

That sounds more like the camera is faulty. The serial port uses one
connection to do the controlling, regardless of direction. Or maybe the
camera has simply "forgotten" where it is and needs to be reset.

Andrew

 

[NetGear]

That sounds more like the camera is faulty. The serial port uses one
connection to do the controlling, regardless of direction. Or maybe the
camera has simply "forgotten" where it is and needs to be reset.

Andrew

Thank you. There are tens of cameras that are controlled by the system,
however. They all behave the same way.

I'm on holiday now and the whole system is actually quite a strange for me.
I'm going to see it probably tomorrow.

 

[Adrian C]

Hi,

We have a HP Proliant server and it seems that there is some kind of a
problem with the serial port.

The server is used to control quite a large CCTV camera system and after a
system crash it seems that some of the camera movement functions are not
working. I think there must be a problem with the integrated com port.

Is it possible to test the port with some easy way?

If there is a possibility that the unit or system has suffered an
electrical 'spike', ground fault or servere overload, the line drivers
of the serial interface could easily have been damaged. Testing this
would be conclusive with access to an oscilloscope just to monitor the
waveforms and their loading when moving cameras about etc.

I'd go for a replacement com port card and additionally I'd make sure it
features optical isolation of the control cable signals. Last thing you
want is a wreaked motherboard.

 

[Paul]

Hi,

We have a HP Proliant server and it seems that there is some kind of a
problem with the serial port.

The server is used to control quite a large CCTV camera system and after a
system crash it seems that some of the camera movement functions are not
working. I think there must be a problem with the integrated com port.

Is it possible to test the port with some easy way?

In the example of camera protocol here, each packet sent on the
RS232/RS485 has a checksum on it. At least some percentage of
transmission errors, would potentially result in the camera
ignoring the command.

http://www.232analyzer.com/RS232_Examples/CCTV/Pelco_D_Pelco_P_Examples_Tutorial.HTM

http://en.wikipedia.org/wiki/Rs485

http://en.wikipedia.org/wiki/Rs232

For asynchronous serial devices to be able to communicate, they have
to agree on baud rate. A 16x clock, for example, may be used to sample
the data bits, and identify the middle of the data bit. If the clocking
signals used on either end, have too large a difference in frequency, the
sampling process moves further and further from the center of
each data bit, and if bad enough, the last bit in the sent byte
can get corrupted. We used to have a lot of trouble with that,
25 years ago, as baud rate generators were not very clever, and
the frequency error got seriously bad up around 19200 or higher.

None of that should be related to a system crash. As long
as the serial port parameters have been set properly
(8-N-1 or whatever), and the baud rate is correct, it should
just work.

You may end up needing an oscilloscope, to verify there isn't a problem
with the wiring itself. If the oscilloscope has digital storage (as
a lot of recent generation equipment would), you can also look
at a packet sent on the port, and verify the bit pattern sent.

The debugging procedure you use, may vary a bit depending on the
actual physical protocol being used. An oscilloscope with digital
storage, makes it possible to unambiguously determine what is
going on. Any other techniques (such as using a second serial port
to "listen in" on the first serial port's TXD signal), may not
tell you enough to fix anything. You may be able to see the
transmissions are garbled, but not know why.

Paul

 

[Dusko Savatovic]

I'd like to add a piece of my experience. We had trouble with proper
handshaking. The simplest, most elementary handshaking is XON/XOFF protocol.
This only uses Tx/Rx lines without any control lines. The drawback is that
you don't know when the remote device is powered on and ready so you may
send your data "into the void". The better handshaking uses proper signals
(or signal pairs) DTR-DSR, RQS-RFS(or CTS), but these need more wires and
more carefull configuring. We were using modem eliminators for longer
distances. I just did a web search and I'm surprised that they are still
sellling. The good old serial communication is still used in the industry.