Interpreting Packets

Assuming that, for whatever reason, you cannot capture the serial traffic using a software running on the desktop PC as @grahamb suggests, the way you took is still quite complex.

Whatever method you use to capture the data, the first thing to do when analysing serial communication is to identify the data speed and format on the wire. Of course it is best if you know them in advance, but if you don't, an oscilloscope is your best friend, as it can show you whether the communication is "asynchronous" (most likely if one of the ends is a standard serial port of a standard PC) or "synchronous" if some kind of specialized adaptor is used, what is the duration of a single bit on the line (which is the inverse of the transmission speed, 10 bits per second mean that a single bit is present on the line for 0.1 second).

For standard serial adaptors, possible speeds are 50, 100, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, or even faster with newer hardware. So the inverse value of the bit duration measured (quite inaccurately) using the oscilloscope should be close to one of these. If asynchronous mode is used and the signal is not modulated onto any carrier, the line is at the same voltage level (stop bit, i.e. logical 1) if no transmission is ongoing, so you need a memorizing oscilloscope.

Next, for an asynchronous communication, you have to determine

• how many data bits are used (5 to 8 are typical values),
• whether a parity bit is used, and if it is, whether it is odd or even,
• how many stop bits are used (1, 1.5 and 2 are typical values).

For synchronous communication, the task would be more complex as in such case, the boundaries of individual bytes are not marked as clearly as in the asynchronous case (using start bit and stop bit(s)) but either some kind of bit oriented protocol like HDLC is used or some multi-byte synchronisation pattern is occasionally present in the data stream.

Knowing all the above, you can set the serial adaptor you use to monitor accordingly. Then, you can use some own software to read the incoming data from that port and dump them in hex and ASCII for further analysis. If there is a gap longer than one byte time, this may indicate a message boundary, so you may want to print a newline and a timestamp before printing the first byte after the gap, so you'd get something like

10:00:03.20 41=A 62=b 63=c
10:00:04.15 43=C 30=0 35=5 FE=.
10:00:07.11 41=A 63=c 65=e

If you want to use Wireshark's ability to dump USB communication, you have to understand how the serial to USB adaptor packs the data into the bulk transfer. I'm afraid that no dissector capable of extracting the serial data from communication of the serial-to-USB adaptor with its driver exists so you would have to write it yourself.

If you insist on going that way, I'd recommend you to do the following:

• disconnect the RS-232 side of the USB to serial adaptor from the monitored cable and the USB side of it from the PC
• connect pins 2 and 3 on the RS-232 connector of the adaptor
• start capturing
• insert the USB end of the USB to serial adaptor back to the PC
• configure the serial port representing the adaptor for "no handshake" and for some speed, parity, number of stop bits etc.
• connect a text terminal software to the serial port and type some string like "hello world", you should see it echoed
• stop the capture.

In the capture, you should see the enumeration phase, including the vendor and product id, which you would later use to tell Wireshark to use your dissector to dissect USB bulk transfers of this vendor and product. You should also see in the bulk transfers' payload substrings of what you typed on the terminal. The substrings may be as small as a single character or they may be longer; they may be even encoded in some unexpected way so you won't be able to match the bulk transfer payload to what you wrote at all.

Your own dissector, if properly registered for the vendor and product id, would then receive the bulk data from Wireshark for analysis, and it would be up to you how you would reassemble them into some logical units. A typical behaviour of Wireshark dissectors is that if a protocol data unit (PDU) is spread across several frames of a transport protocol, the complete reassembled PDU is added to the dissection tree of the last one of the transport frames carrying it.

So after writing your dissector, Wireshark would show you about the same as suggested above - chunks of bytes with timestamps.