How to snif full-duplex UART protocol between two nodes

Not quite what you asked for, but I've used:

logic analyser software, which will decode UART signals. You can get some very cheap modules that it works with, eg: $10 from the usual marketplaces, search for 'CY7C68013A', 'EZ-USB' or 'FX2LP') if you aren't fussy about buffering. Sigrok also supports a wide range of other logic analysers - perhaps you already have something.

The nice thing about the CY7C68013A chip over regular logic analysers is that it's capable of realtime streaming. Assuming your PC's USB stack is up to it and doesn't randomly pause (or have some other chatty USB device on the bus stealing bandwidth) you can record for as long as your memory and storage subsystem can keep up. Given it's 480Mbps USB2.0, that is probably quite a long time.

Being a logic analyser the inputs are by definition synchronised and timestamped relative to each other.

Theo

As Theo says, there are a number of different "Protocal Analyszers" that you just insert into the communications link and it records all of the data sent between the units, with time stamps, for display on a PC.

They are very handy for debuging such links.

The main thing you need to make sure of is that the module understands the voltage format of your link, be it "TTL", RS-232, RS-422, or RS-485, or whatever you have. And that it can capture at the baud rate of your link.

If the link might be variable baud, you need a unit that captures like a logic analyizer and then lets you process later, which is a bit more complicated. You also want something like that if you need to check if there are bit-level timing issues with the link.

There is a traditional hack where you make or buy a Y cable that lets you tap the serial i/o and listen to both directions from a PC. Then just log the data going in and out. When I did it I used a simple Python script and it was able to keep up with the device we were dealing with (might have been 1200 bps, I don't remember). It's possible something like that already exists for Wireshark.

If you have to do that "many times", then buy a serial protocol analyzer widget that has hardware that has two capture ports and timestamps every bit/byte.

I have and older version of this and it works brilliantly:

There are similar but cheaper products from other vendors, but if it's something you need to do often, then it's worth a few hundred dollars/euros to get a decent one.

The latency/buffer in the USB adpaters is awful. Spend some money and by a real serial analyzer.

You could fairly easily modify my "connect.c" to do this, works in Linux or OS/X. It does two-way communication between a serial port and the terminal console you run it from, similar to `cu`, minicom` and similar programs - but this is very simple, you don't have to navigate a wealth of features to make changes.

Change it to configure two serial ports and copy data between them, logging data to a file in the same way the Unix program `script` does. Then plug in two USB/RS232 dongles and connect your two devices.

Clifford Heath.

Try searching for "RS232 analyser", "RS232 datascope" and similar. A quick look found a number of possible candidates. I won't make any recommendation myself as last time I needed something like this I went back to an old DOS tool.

Try searching for "RS232 analyser", "RS232 datascope" and similar. A quick look found a number of possible candidates. I won't make any recommendation myself as last time I needed something like this I went back to an old DOS tool.

Do you mean "joining electrically" (AND for UART TTL levels) the two signals and connect the result to the RX signal of a single serial port on the PC?

It couldn't work in my case, because the protocol could be full-duplex, so both nodes could transmit at the same time. The AND result would be corrupted.

Since this involves two devices communicating and two serial ports, one to monitor the data in each direction, wouldn't this be an X cable? Or am I missing something?

I guess you could call it an X cable. This has a diagram that looks about right:

I've never made one of these myself. I used one that a co-worker made, and wrote the code to log the data. I said 1200 bps earlier, but I think it was actually 9600 bps. The connected devices were a POS terminal and a receipt printer.

I think it could work with a 'diode-OR' (or open-collector) kind of a arrangement: either end can pull the line to the active state, but otherwise the line will fall back to the inactive state. The diodes prevent the line being driven to opposite potentials.

It would only really work protocol-wise if you could be sure both sides weren't talking at the same time. That might work if there was a command/response protocol where you could be sure everything was half-duplex. And you also wouldn't be able to tell which end a byte came from, unless there was internal structure in the messages (like ASCII commands with carriage returns on the end).

But could work as a kind of poor-man's sniffer if you had no better option.

Theo