A serial decoder needs the baud rate, and the device you are probing may not tell you. The signal does: the narrowest pulse in a serial burst is one bit, and one over its width is the baud rate. Here is how to read it, a trick that makes it easy, how close is close enough, and how to let the scope do it.
Measure several narrow pulses, not one. A pulse that looks narrow may be two bits; every pulse in the burst is a whole number of bits long, and the shortest one you find is one bit.
If you can make the device send the letter U, the job gets easy. U is 0x55, binary 01010101. Sent lowest bit first between its start bit (0) and stop bit (1), the line changes level at every bit:
Every high and every low pulse of a U is exactly one bit, so +Width and -Width both read the bit time. And when U's are sent back to back (the next start bit follows the stop bit at once) the line is a square wave of two bits a period: Frequency reads half the baud rate. 28.8 kHz means 57,600 baud. Paste a line of U's into the terminal rather than holding the key: a held key repeats only a few dozen times a second, and the gaps between characters spoil the frequency reading. Zoom so the screen holds only the inside of the burst.
One bit is 1 / rate, a character 10 bits in 8N1, and a run of U's a square wave at half the rate.
| Baud rate | One bit | One 8N1 character (10 bits) | A run of U's |
|---|---|---|---|
| 1,200 | 833 µs | 8.33 ms | 600 Hz |
| 2,400 | 417 µs | 4.17 ms | 1.2 kHz |
| 4,800 | 208 µs | 2.08 ms | 2.4 kHz |
| 9,600 | 104 µs | 1.04 ms | 4.8 kHz |
| 19,200 | 52.1 µs | 521 µs | 9.6 kHz |
| 38,400 | 26.0 µs | 260 µs | 19.2 kHz |
| 57,600 | 17.4 µs | 174 µs | 28.8 kHz |
| 115,200 | 8.68 µs | 86.8 µs | 57.6 kHz |
| 230,400 | 4.34 µs | 43.4 µs | 115.2 kHz |
| 460,800 | 2.17 µs | 21.7 µs | 230.4 kHz |
| 921,600 | 1.09 µs | 10.9 µs | 460.8 kHz |
Real devices are rarely exactly on the rate. Their clock is divided down from a crystal, and the division seldom comes out even. Our XBee-PRO S3B measured 57,236 to 57,724 baud over many runs against its nominal 57,600: from 0.6 % slow to 0.2 % fast. Digi's own manual for its older XBee S1 says its 115,200 setting actually runs at 111,111 baud, 3.5 % slow.
How much is too much? A receiver starts timing at the falling edge of the start bit and reads each bit in its middle. The last bit it reads, the stop bit of an 8N1 character, is read 9.5 bit times after that edge. If the two clocks differ, the error adds up over those 9.5 bits, and the read lands in the wrong bit once it has drifted half a bit: 0.5 / 9.5 = 5.3 % between the two ends at most. Receivers also lose a little to finding the edge, so keep the total under about 3 %, or about 1.5 % for each end. If your measurement lands within 2 % of a standard rate, it is almost certainly that rate.
NovaOS measures the rate for you. In the decode sheet, RS232's Auto rate (or Auto on the Baud keypad) measures each capture's line and decodes at what it finds; over SCPI it is :NOVAos:BUS1:RS232:AUTO ON. The sheet then says what it found, for example "Auto: 9.446 kb/s (-1.60 % from 9.60 kb/s), 8N1": the rate, how far it is from the nearest standard rate, and the framing.
How it works: it finds the line's edges between samples, takes a first guess at the bit time from the shortest pulses, finds the characters from their start bits as a receiver would, then fits one bit time across every edge of every character. Hundreds of edges give the rate to a few hundredths of a percent, where one pulse measured by hand gives it only to a sample or so. It also reads the framing (a parity bit, a second stop bit, 9-bit characters) and whether the line idles high or low. When the measurement cannot be told apart from the nearest standard rate, it uses the standard rate; when it can, it uses what it measured. A bus running 1.6 % slow is decoded at its real rate, not at 9600.
When to distrust it. It needs at least three characters on the capture; with fewer it keeps the rate it had and says "no characters on this capture" with the rate it holds. It reads the framing as known only from six characters on. It needs two samples a bit to measure and more to decode: on a slow time base, press Stop to decode the whole record. And it assumes one rate on the record: a device that changes rate partway (an XBee given a new rate with ATBD switches when it leaves command mode; some chips print boot messages at one rate and run at another) gives a result that fits neither. Zoom into one part, and check that the decoded text makes sense.
For a UART, yes: each symbol on the line is one bit, so 57,600 baud is 57,600 bits a second. The data is less: an 8N1 character carries 8 data bits in 10, so 57,600 baud moves at most 5,760 bytes a second.
Yes. Measure the narrowest pulse with the cursors or the width measurement and divide one by it. A decoder only helps you check the answer.
Because the device's clock divides down to a rate close to the standard one, not onto it, and the scope measures what is really there. A few tenths of a percent is normal; a UART tolerates a few percent.
An odd rate some chips use for their boot messages: the ESP8266 prints its boot log at 74,880 baud before the program sets its own rate, which is why a terminal at 115,200 shows garbage for a moment at power-up. More on boot logs.
An XBee radio's serial line, from the wiring to the decoded answer: the trigger on the start bit, the time base and the decoder settings.
An XBee's power-up commandsProbe DIN and DOUT, capture the whole start-up in one deep record, and read the network, channels and addresses the device sets.
Why the scope waits for a triggerAuto, Normal and Single; slope and level; and why a level that looks right still catches nothing on an idle line.