4 Answers 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.
enter image description here
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.
Share
Cite
Follow
edited Apr 10, 2016 at 6:51
answered Apr 9, 2016 at 17:43
tcrosley's user avatar
tcrosley
48.2k55 gold badges9999 silver badges163163 bronze badges
@tcrosley--After baud rate and the comms parameters have been
determined can we make an educated guesses to what kind of data is being
sent? ASCII/HEX/Binary LF/CR terminators etc? –
inbinder
Commented Apr 9, 2016 at 18:02
1
As I mentioned in my answer, knowing where the start bit is, you can
decipher the remainder of the character by looking at the voltage (high or
low of the signal at the middle of each bit. The bits are inverted, i.e. a
low is a logic one, and a high voltage is a logic zero. Put all the bits
together and you have one byte It's impossible to say whether for sure a
that byte is ASCII or binary, however if ASCII, it will never have the
most significant byte a 1 where with hex, some bits will probably have
some bytes with the first bit 1. I'm currently working on a drawing to
better explain this. –
tcrosley
Commented Apr 9, 2016 at 18:06
I'm confused about the bit interpretation in the UART graph above. Since
the START bit always switches the line to a SPACE, why is it decoded as a
logic 1? Furthermore, since the START bit is a SPACE (Logic 0), why are
all the other decodings inverted here. Here's one reference on the matter.
–
ephsmith
Commented Oct 21, 2018 at 20:34
Let me add that the binary decoding of the RS-232 signal in the graph is
also inverted--based on references I've read and signals I've measured.
another reference –
ephsmith
Commented Oct 21, 2018 at 20:39
Add a comment
8
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. (10.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.
Share
Cite
Follow
answered Apr 9, 2016 at 17:39
Transistor's user avatar
Transistor
177k1313 gold badges191191 silver badges409409 bronze badges
Add a comment
6
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.
Share
Cite
Follow
answered Apr 9, 2016 at 18:18
Marko Buršič's user avatar
Marko Buršič
24.1k22 gold badges2020 silver badges3434 bronze badges
Add a comment
0
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.