reverse engineering a serial protocol with a scope

Question

In lieu of a serial capture device are we able to look at the output of an rs-232 feed and correlate what we see on the scope with ASCII/hex representations (do certain voltages tend to correspond with this character representation or that character representation? Line feeds and carriage returns come to mind) or are there too many variable to reverse engineer a serial protocol in this manner?

Answer 1

The difficulty in capturing and analyzing RS-232 signals on a scope is that the start pulse -- where the voltage first drops from a high logic level to a low one (if one is looking at UART levels), or rises from a negative voltage to a positive one (if one is looking at RS-232 levels) -- looks the same as any other bit, so it can be difficult to trigger on the first edge (whether trailing or leading) of the start pulse of the first character.

If you do trigger on one of the beginning edges of of the bits (whether the start bit or another one, if your sweep set so that you can capture more than one character, then you will be able to see any complete characters after the trigger -- the signal should break up into characters since the stop bit is longer than the others. Look at the start bit, and then from the middle of the start bit, the middle of the bits that follow it will be dependent on the baud rate. At 9600 baud, that is 104 µS, and at 115,200 baud it is 8.68 µS for example.

The data in the two bytes (0x3D and 0x68) could either be hex data with the values as shown, or ASCII characters, also given. Without other context it is impossible to tell.

The top diagram shows the RS-232 levels that you would see on a PC COM port (seldom seen anymore) or a USB to RS-232 cable. The spacing or idle condition (0) is a negative voltage between -5 and -12v, and a marking condition (1) is a positive voltage between +5 and +12.

This bottom diagram shows the logic levels that you would see on the TX and RX leads of a UART. Note that the bits are inverted -- a high logic level is a 0 (called spacing) and a low logic level is a 1 (called marking).

Here is a table to convert the bits to ASCII.

That said, many scopes now come with protocol analyzers for UART, I2C and SPI either standard or an optional module you can buy. Or you can buy a stand-along logic analyzer that display the waveform on using a PC as the the display.

Answer 2

I have no idea what you mean by "X" and "Z".

Standard way to reverse engineer an RS-232 signal would be:

• Use the oscilloscope to figure out the baud rate. e.g., 0.104 ms pulse width would indicate 9600 baud. (\$ \frac {1}{0.104m} = 9600) \$.
• Use the oscilloscope to figure out the number of bits.
• Count the bits and see if the last bit changes state to keep the parity even or odd. If you can't see a pattern you can assume no parity bit.
• Hook up to a PC running a terminal emulator such as PuTTY.
• Set the baud rate to match and try various combinations of parity and stop bits until you start to see sensible data.

That will give you the raw serial data. You now have to figure out what it means.

Answer 3

Determine the baud rate, stop, start, parity with scope. Then use a computer terminal window to capture traffic. Even better would be to use Wireshark with PCAP and usb to rs232 converter. If the serial protocol is one of known protocols by Wireshark, it will detect and dissect the packets of data automaticly.

Answer 4

Note RS232 is a voltage standard, it does not define a protocol. It defines what a one is and a zero, and pinouts for the connectors.

As far as decoding the serial protocol on a scope, it is not always possible (often not possible), and although scopes have uart, i2c, etc decoders, they dont always do a good job so it is better to take anything the scope tells you with a grain of salt and decode it yourself. You will waste a lot of time debugging something assuming the scope software is right (for any serial protocol not just a uart style protocol).

As far as a serial protocol, the only time you are going to have a chance is if there is a long (more than a character) period between the stop bit and the next start bit. From the scope with enough characters you can determine the baud rate.

By inspection with or without software or hardware for that matter you may not be able to determine how many data bits, if there is parity or not, how many stop bits. If you manage to capture one character in isolation (has many idle/stop bits before and many after (and elsewhere you have determined the bit rate), you can figure out how many bits make up a character but you still wont know if there is parity or not, so you still cannot make any assumptions as to the values of those characters.

If you happen to know the size of the character and the parity, you can get there faster, but still have to work through framing errors deciding from the the middle of a continuous stream. If there are enough idle periods before a start bit to insure that is really a start bit, and you know the data length and if there is parity, what kind and the number of stop bits, that is your best bet for decoding by hand (or having the scope software try to do it, hand check the first few characters or more of the scope's guess to make sure it is doing it right).

The scopes decoder if any and any real uarts are all going to have their own opinion of how the data is decoded, starting in the middle of a stream each will have its own way of working through framing errors and trying to sync up again, eventually they should all, if they know the protocol parameters (data bits, parity, stop bits, baud) should lock on if they are uarts worth using. You may not have captured enough data in a stream to work through that either with the scopes software or by hand.

So you will need enough different characters in order to convince yourself what the baud/bit rate is. But need some dead periods around single characters to isolate one and determine bits in a character. And if you capture a dead period before a stream of characters, then you at least have a good start at decoding if you know the data bits, parity and stop bits.

Remember RS232 is basically inverted, a one is a negative value and a zero is a positive. And uart protocols are normally lsbit first.