Serial port monitor

I have done this before in the following way. It is easy if you are using Linux. It may be easy if you are not.

Make a dual-snooper cable. You need two ports on your working computer. Tee off TX-East to computer port 1 and TX-West to computer port 2.

Write a very simple serial reader. Set the ports up raw (see my post from a couple of day ago). Loop, doing a blocking read on each character on the serial port. Print this out with a timestamp. Run this on each port. Stream the outputs to files. Then paste the files and sort on the timestamp.

You could also do this in one program, but the blocking read way is better than having to poll for characters.

If this is a half duplex protocol, you can also monitor the traffic with a single serial port and two diodes. Connect the cathodes of these diodes to the snooping port Rx line. Connect the anodes of these diodes to the Tx-East resp. TX-West signals.

If you do the time stamping in user mode, the accuracy of the time stamp is questionable. If you timestamp in the ISR (e.g. by reading the TSC on Pentium systems), quite accurate timings can be extracted.

Of course the traditional way is to use a dual channel oscilloscope and measure the time of Tx/Rx switchover.

Paul

As long as there is no context switch between the read and the timestamp (unlikely as coming out of a blocking read is the beginning of the timeslice), you would be surprised how well this works - and you can use the TSC in userspace also, if necessary (using inline asm).

That would be required to veryify the results.

HI

I use the cable option for ViewComm. It is an excellent product. Once you have it you don't know how you got on without it.

Phil W

The time between the user mode return from the read request and the TSC snapshot is usually not the issue.

However, in operation systems like standards Windows or standard Linux, the time between the ISR return and reawakening of the user mode thread (that issued the read request) may by several milliseconds if there are other activities in the system.

If the UART FIFO is in use, you might have several characters in the FIFO when the interrupt is served, thus, several reads will get the same time stamp.

One more thing to watch out when using an oscilloscope is the problem of determine, when the last character of the request ends. The idle state, the stop bit(s) and the "1" bits are all in the Mark state. For instance if the last character is 0xFF and no (or odd) parity is used, the last transition you see is the start bit (in the Space state) and after that the line remains in the mark space during the 8 data bits, (the parity bit,) the stop bit and will also remain there in the idle state.

The first start bit of the reply message is easy to detect (first Mark to Space transition), but visually detecting of the end of the last character of the request is much harder, thus, there will be a +/- 5 bit time variation, if you measure between the last Space to Mark transition of the request to the first Mark to Space transition (start bit) of the reply.

Paul

You may find that you can do what you want with "portmon" from

This lets you log all activity on a serial port, with a timestamp.

Andrew

already worked with listen32 from win-tech.com has some restrictions with baudrate setup and reliable, hm most time if you do not have XP.

MicroTAP at

will do what you need out of the box under any DOS box. I use this at very high baud rates where it can log data and time stamp with good resolution.

Newer versions work under windows.

There is even a DOS freeware version called ComTAP.

Good luck!

John

[...]

Right. This should be attempted on a very idle system (no windows, no daemons, minimal drivers loaded). I've used this setup to snoop protocols, and used the timestamp just for sorting the output. And there will be hiccups, but the average should be usable.

The OP asked for resolution of milliseconds, so maybe this would work.

Hemanth M S wrote in news: snipped-for-privacy@remove-me.netscape.net:

Hi,

Try

Sam