Is Realterm for Real?

I'm afraid there is no "best". Look at

Windows?

AFAIK Sysinternals Portmon only shows the communication between the application and the driver. If the application doesn't ask for a byte (and it stays in the buffer), you likely won't see it.

FIFO problem? Try to set the FIFO to zero (needs admin rights).

You can use a second PC with two comm ports and BinTerm or one of the other analyzers. But they are not 100% accurate unless they use a special driver.

DigiView DV3100 from

If you buy your next scope, consider a Hameg HMO.

Oliver

I think this is going to range between hard and impossible, especially on windows. Incoming and outgoing serial data passes through several layers of buffers and fifos - hardware fifos on the UART chips, buffers in the interrupt handlers, buffers in the OS, buffers in the programs that use the data. Much of the timing information is lost along the way. And obviously it is even worse if you are using USB serial adaptors.

If you are trying to monitor a protocol where only one side sends at a time, then one trick is to attach the receive line of another serial port to the original receive and transmit lines using a couple of diodes and a resistor. That way your monitor line sees all the traffic. Of course, you don't get timing information or direction information - but often you can separate the tx and rx data if you know the protocol.

Other than that, a two channel digital scope with plenty of memory is perhaps the easiest to view the timing and synchronisation.

However, as was mentioned by David Brown, you may be asking Windows to do more that it's really capable of. To do what it looks like you're wanting to do, I would use one of the USB logic analyzers that have async serial interpreters. That gives you real timing of multiple serial streams as well as letting you "see" the characters without having to count bits and punch an ASCII table.

I use (and love) an Intronix from

This

That is correct.

As far as I know, not without external hardware support.

One of my employers had a line of products controlled via a multidrop RS-485 network. The "network controller" on every node was wathever UART was available in the micro used in that node, but the protocol had very tight timing requirements that required to be creative on using that UART. To debug the protocol itself as well as new products, they designed a small analyzer based on a common 8-bit micro. It had an RS-485 connector on one side for the network, an RS-232 on the other to connect to a PC. It will decode the messages on the '485 line, flag badly formed messages, etc. but its main function was just to log traffic attaching precise timing stamps to packets and individual bytes. This internal project was approved after it was found it was impossible to do what they (and you) needed with PC-based software-only solutions. But it was trivial to do with dedicated hardware. (low level HW, as in a 6800 or less...)

I think that's the way to go. (Lacking the expensive logic analyzer you mentioned before.)

-- Roberto Waltman

The older hp protocol analysers are pretty affordable now, especially on Ebay, though the baud rates are limited. I have a 4952 and 4957 series in the lab here and they get a lot of use. They monitor both sides of the line and have a built in macro language capability that lets you write a program to either stimulate the line with data or selectively monitor receive data. Timing resolution is around 1mS and you can either have data only, or data mixed with graphical representation of control line state.

Really can't understand why hp stopped making them, other than the fact that serial comms is not quite so mainstream now...

Regards,

Chris

It sounds like you need a protocol analyzer. Most of the ones I've used were all stand-alone units made by HP, but they seemed to have abandoned that market many years ago.

These days most similar products seem to use a PC for the UI and attach to the capture/timestamping hardware via USB.

You can't. At least not what I would consider "exact". But, there are products that come pretty close. The one that I've used in the past is a very old product from Greanleaf. It was DOS-based, but they still advertise something called "ViewComm II" that looks pretty similar:

They claim a timestamp accuracy of 100ns.

Interesting - They offer a demo here:

-- Roberto Waltman

What you're describing isn't a terminal emulator. It's a serial port monitor. Years ago I used MicroTap from Paladin Software, who are still in business. See

Their software included a cable that uses the Rx inputs from two serial ports on a DOS (!) computer to listen to both directions of transmissions. (Computer A talks bidirectionally to computer B while comptuter T runs MicroTap and logs traffic, entire setup uses the special cable which has four ends). It works and does what you want it to (display bytes in order as they are transmitted) and more.

When I was younger and had extra time on my hands, I built my own cable and wrote my own SECS-II traffic analyzer under DOS. That's no small job but it's not huge either. It just shows that it's a doable DIY investment if you have the time. I still have the cable in a box gathering dust for who knows what.

JJS

I don't see how Windows could be messing this up just because of it's bulk or whatever. The last char NEVER shows up until a new command is sent and the response returned. Something in the driver or application is messed up. Like I said, I have send the command manually and then manually polled looking for the last char. It isn't there as far as the interface code is concerned.

Funny, this unit is nearly the same as the Intronix that they seem to have dropped. I wonder if someone made a knockoff? One of my customers uses the Intronix and loves it. The mage of the CSI5034 display shows a sine wave. Is that from the digital data or does this thing have mixed signal capability?

Rick

You may find either of these might be suitable for your needs.

I have the USBee SX unit, only because I needed one in a hurry a couple of years ago and it was the fastest for me to get at that time.

Take care.

Mike

ty

h,

ry

Thanks for the pointers. I know about all sorts of tools that will do this, but I don't want to spend $150 to solve this problem. Of course that is likely money not wisely saved in some sense. It has cost me more than $150 of my time to talk about the problem most likely. But this tool won't solve the issue, it will just help me pin down the source of the trouble.

I am actually looking for a good Oscope with 16 bits of logic analyzer together. I haven't found one that actually had good scope capabilities. They are mostly also rans including the Agilent PC based scope. It only uses 8 bit ADCs and cost over $1500!

I may never find one that is good enough really. The scope market seems to include the bench units with good analog and ADC inputs and the PC attached units with not so good analog and ADC inputs. I've seen a project that is developing a high quality scope, but the guy is doing everything himself, refuses help and is going at a very slow pace. Engineers! What is wrong with us??? ;^)

Rick

I agree that it's probably not the Windows serial driver. I've done lots of binary data exchanges between various loggers I've designed and homegrown Windows host programs. I've never noted this behavior. With today's faster Windows machines, I generally don't have to worry about dropped characters due to buffer overflow unless I'm transferring ASCII data and trying to display it as it arrives.

I also haven't had this problem with USB-serial converters----which use an altogether different driver at the hardware layer.

That said, I don't think I'd want to try time-stamping the incoming data with microsecond resolution! ;-) That sounds like an interesting project for one of the STM32 boards with one receive uart port for each of the device-to-windows serial lines and a USB link to the same or a separate PC to send the time-stamped data.

Mark Borgerson

You can always use SetupComm() to specify the queue size from the interrupt service routine to the user mode program. For more than a decade ago, Windows accepted at least 60 KB buffers, so you should be able to capture at least 6 seconds of traffic at 115k2 speeds.

These days you don't even have to worry of brain dead VGA/Ethernet/floppy cards capturing the interrupt line for extended periods of time.

You know that UART decoding and triggering is an expensive option in Agilent's MSOX?

Oliver