Connect with us

Monitor RS232 Line Communication - PC hookup

Discussion in 'Electronic Design' started by Klaus Vestergaard Kragelund, Jan 6, 2004.

Scroll to continue with content
  1. Hi

    I'm communicating to a HP33120a function generator. PC and instrument are
    both DTE devices and I use a null-modem cable as described by HP.

    When I run the software I have written in LabWindows I sometimes get errors
    from the instrument. Header errors and "Input Buffer Overflow" errors

    Also for purposes of setting up a larger test system which includes scopes
    and multimeters too I have purchased some USB-Serial Adaptor devices. But
    when I use those with the same serial flow as with the null-modem cable I
    get more errors.

    So I need to do some debugging, but it seems too difficult with the scope. I
    have an old portable PC, can I somehow hook that up as a second idle PC to
    the same serial line with some sort of port state logging software to get an
    idea of where my problems comes from?


  2. Guest

    "Input Buffer Overflow" almost always means that your PC can't keep up with
    the amount of data coming into the serial port. I expect you're using a
    high baud rate (115,200?). Do you still get these errors when you reduce
    the baud rate to something like 1/2 or 1/3 of the current setting??

    Are you using any flow control??
    Sure. There are several generic serial logger products available, but unless
    you already know what's supposed to be on the serial line, you may end up
    just seeing a bunch of bytes and not know what to do with them. Is the
    protocol between the HP and the PC documented? Does the protocol include
    a checksum of sorts? And can you spend any real money on the troubleshooting
    or do you have to make due with the tools at hand?

    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email:
    Klos Technologies, Inc. Web:
    ==================== What goes around, comes around... =====================
  3. I should have specified more explicitly it is the instrument that is
    reporting the error, sorry for that...

    I'm just sending data at 2400baud without any handshaking using SCPI
    commands to debug the interface before I use any drivers from the instrument
    manufactors (In fact I have tried theese, but they also produce errors)
    No flow control. XON/XOFF is disabled and hardware handshaking is also
    turned off. So, in essence I'm just running so slow that the device will be
    able to catch up
    I know exactly what I am sending due to the software I have written. What
    I'm after is a device I can hook up on the instrument end to capture what
    bytes are received and what status/control signals are activated


  4. moocowmoo

    moocowmoo Guest

    As the other guys have said, you need to switch on handshaking because you
    are still sending the data too fast and the function generator isn't
    catching up. If you really don't want to implement handshaking then as well
    as using a low baud rate you also need to leave gaps in the transmission and
    it will be very slow.

    One way that we use an old PC for monitoring serial comms is using a special
    cable and Hyperterminal. All that it consists of is a couple of diodes to OR
    together the send and receive lines then you can monitor the dialog both as
    long as the devices don't talk in full duplex.

    Here is a link to a similar idea.

  5. Or, don't send commands that exceed the device's buffer limit and then
    wait for completion of each command before issuing the next one.
    Application level flow control if you will. You can't go any faster than
    the device can process commands anyway.
  6. Marco

    Marco Guest

    Google for an program called ComTap, make a tap cable, use a DOS PC to
    run ComTap and see exactly what happens on the RS232...

    I've used this several times to reverse-engineer binary (non-documented)
    protocols, it works great.
  7. Reed Blake

    Reed Blake Guest

    Klaus Vestergaard Kragelund wrote in message
    As others have commented, you really need to turn on handshaking. I strongly
    suggest hardware handshaking over Xon/Xoff. Use the LabWindows SetCTSMode()
    function to enable hardware handshaking.

    For your larger system, consider using GPIB instead of serial, especially if
    you are going to download lots of data from your scopes.

    That said, there are a couple of ways to do serial port monitoring.

    1. Install a serial port sniffer / protocol analyzer on a second computer.
    This software uses two com ports and a special cable to monitor and display
    activity on the serial link. This will work for communications between any
    two devices, not just PCs. This is an excellent solution, but can be a bit
    expensive for a one time use. I used to use ViewComm from Greenleaf, but it
    looks like the program has changed a lot in the last decade, so I really
    can't comment on it now.

    2. Install serial port monitor program on your control (LabWindows)
    computer. These programs typically replace the serial driver, and let you
    see the data flow and control signals. This is typically less expensive, and
    likely won't work with your USB serial adapters. Caveat - I haven't
    used this type of program.

    Do a google search for serial monitor to see lots of products in both

    If you want to use a scope, turn on RTS/CTS hardware handshaking on the HP,
    and watch the RD and RTS lines on the HP side of your null modem cable. You
    will likely see the HP drop RTS while the PC continues to send data.

    Feel free to email me if you need more info.
  8. Tried going down to 300baud with the cable, that works fine

    Then tried 300baud with the USB to serial adaptor, and plenty of errors
    (header errors, not buffer overflow). Then tried killing the program when I
    had run the stream of data for a couple of seconds. When I do this the data
    seems to keep flowing even when the program is killed. Some buffer must be
    active. Then went to "Control Panel->System->Device Manager" and set the
    port (USB psedu-port) to disable 16650 FIFO. This changes nothing

    I think maybe the USB device buffer is doing something like getting data too
    fast or something

    Moreover, now I remember why I dropped my efforts the last time. Now my PC
    boots without warning when I use the USB->Serial adaptor. This happens with
    both types of adapters I have :-(

    I Think Bill Gates is angry with me and won't let me succeed ;-)


  9. Just tried hooking up a RS232 mini tester (LEDs on all the lines). It does
    continue to send lots of data after the program is killed. The DSR line is
    toogling in sync with the errors from the instrument. Will try to block
    transfers to the instrument when this line is active, perhaps this will help
    my buffer problem too....


  10. Alex Pavloff

    Alex Pavloff Guest

    They sell software for Windows and DOS that lets you monitor serial
    communication, with a PC+adapter between the 2 devices. I've used the
    DOS version for years and it works great. Never tried the Windows
    version. The DOS version needs 2 serial ports -- not sure about the
    Windows version.
  11. Thanks Reed

    I should have done this when I first started working on the instrument. Now
    using the null-modem cable with the DTR line from the instrument hooked up
    to CTS at the PC I can run at 9600 baud with CTS/CTS/DTR hardware
    handshaking. No errors :)

    But using the USB to serial converter still runs bad, but at least now I
    know the connection is correct and can chase the problem of the buffer in
    the USB adapter...



  12. Many people have found that the USB serial ports have their share of
    quirks. Notably, they tend to be quite slow to respond to and make
    control signal changes, and often have considerable amounts of
    unexpected buffering built in. Pretty much anyone who's tried to
    rapidly toggle DTR, for example, or to toggle it with any timing
    precision, has been pretty quickly burned. As you noticed, most of
    them can also transmit a fair while after getting a flow control
    signal to stop.

    This is usually because these are pretty dumb devices, and most of the
    responses to changing conditions (eg. hold transmitting) has to
    propagate over the USB link to the device driver in the CPU before
    they're acted on, and buffers going the other way are gone as far as
    the DD is concerned. In short your application is a *long* way away
    from the actual serial port.

    If you've got a fairly conventional serial device, with lots of input
    buffer, and no tricky timing requirements on the control signals (IOW
    a modern modem), you'll be fine.

    Also, if your device is powered off the serial port (which has always
    been iffy, rather more so of late), the USB serial ports tend to be a
    problem as well.

    Some of the USB serial ports appear to be a bit better than others, at
    least as regards hardware flow control.

    Oh yeah, you mentioned buggy drivers for these things? It's a bloody
    serial port, you'd think it wouldn't be that hard to get right, but

    Allow me to recommend any of the nice PCI serial port cards. The
    PCMCIA serial ports seem OK as well.
  13. Yep, I just bought a Maxo PCI board with 4 serial ports - at least thats
    going to work :) (and included is software to log the transmission on the
    serial port, which was my initial request)

    But on the subject of the USB serial port. I refuse to give up - but the
    next step seems to write my own driver and access the USB device directly.
    Thats an entirely other project, but I'll give it a try. The USB adapter I'm
    using from Prolific has a pdf file describing all the low-level

    (it's called the "PL-2303 USB-Serial Driver Specification" - link: It speaks of DDK and WDM which is completely
    new for me)



  14. I looked because I was curious - that sort of low-level interface data
    is not generally published, unless the vendor intends to support
    Linux, or under and NDA. Indeed, it is not published here either
    (unless you provided a link to the wrong document). All that 2303.pdf
    describes is how the serial port driver appears to the OS. The I/O
    Request Packets (IRPs) are what the OS sends to a device driver (IOW,
    this document define the "API" exported by the driver). All they've
    done is taken the MS sample serial port driver (which is included with
    the DDK), and produced a document which describes what functions
    *their* device driver implements. In fact they've almost exactly
    matched the MS Sample, which you'd expect for a serial port (IOW, this
    document would apply, with only minor changes to any driver, for any
    hardware, that claimed to be a more-or-less "normal" Windows serial

    Unfortunately, none of that actually tells you anything about how you
    talk to the serial port thingy on the other end of the USB cable.
  15. Well, that just goes to show the saying RTFM certainly applies to me ;-)


  16. Finally found a workaround for the USB to Serial adapter problem.

    Even though the adapter was set to 9600 baud with the correct handshaking,
    the software program would stream off the data much faster. Well, I simply
    inserted a delay of approx 2/baud inbetween all bytes written to the USB
    adapter and now it functions beautifully. This probably avoids filling up
    the USB input buffer and also limits the speed of the communication line.

    I think however I will use the PCI board with multiple serial outputs if I
    see any more warmboots due to the adapter. Thanks for all your help :)


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.
Electronics Point Logo
Continue to site
Quote of the day