Testing server serial port?

Discussion in 'Windows Server' started by NetGear, Jul 20, 2009.

  1. NetGear

    NetGear Guest


    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?
    NetGear, Jul 20, 2009
    1. Advertisements

  2. 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.
    Dusko Savatovic, Jul 20, 2009
    1. Advertisements

  3. NetGear

    NetGear Guest

    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.
    NetGear, Jul 20, 2009
  4. 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
    Meinolf Weber [MVP-DS], Jul 20, 2009
  5. 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.
    Dusko Savatovic, Jul 20, 2009
  6. 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 Morton, Jul 20, 2009
  7. NetGear

    NetGear Guest

    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.
    NetGear, Jul 20, 2009
  8. NetGear

    Adrian C Guest

    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.
    Adrian C, Jul 20, 2009
  9. NetGear

    Paul Guest

    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.




    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, Jul 20, 2009
  10. 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.
    Dusko Savatovic, Jul 21, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.