Can we calculate the baud rate of RS232 communication from the TX output signal?

Can we calculate the baud rate or communication speed of RS232 communication from the X output signal?

The below image is from an RS232 communication output signal. I took this picture with 0xaa, and the time period between highs is 100.us.

I heard that the external oscillator's frequency is 8Mhz. Can we calculate the baud rate from that?

• I think an EE should know that F=1/T. – Eugene Sh. Sep 11 '17 at 17:17
• I was expecting this to be a question about detecting the baud rate without the knowledge of the data to ease configuration, but this? @EugeneSh. is more than right - knowing the definition of frequency is basic knowledge when working with electronics. – NieDzejkob Sep 12 '17 at 14:35
• Hint: if you get confused by something like this, make your development machine send your best guess as to what you think you are seeing and see what that looks like on the scope in comparison. If wrong, refine your guess to bring them closer. – Chris Stratton Sep 13 '17 at 1:56
• Sigrok is open source, right? How do people think "guess frequency" works? – mckenzm Aug 14 '19 at 0:01

It looks like you have about 2.4 bit times per division, which are 250 µs. That puts each bit time at 104 µs. Inverting that yields 9.6 kBaud. That's one of the standard baud rates, so this sounds quite plausible.

Your scope shows the timing at $100\:\mu\textrm{s}$. This may either be you setting the cursors, or else the automated use of a measure function on the scope. You don't say. Either way, I agree with Olin's comment that this is close to 9600 bps, which is a common bit rate for RS-232 communications.

However, your own comment about the external clock rate would, if true, argue that an exact 9600 bps is unlikely. $8\:\textrm{MHz}$ doesn't divide down evenly to 9600 bps.

Some other thoughts:

1. If it really is a $100\:\mu\textrm{s}$ bit width, then they've exceeded the $\pm 2\%$ allowable accuracy variation allowed for the common rate of 9600 bps. (If you need to see the calculations and thoughts behind this figure, see this Maxim page.) If the scope accuracy we accept is only approximate, then it may not exceed the accuracy requirements. Regardless, it's a good idea that you know they exist.
2. This signal clearly isn't using RS-232 voltages, but instead perhaps ~$3.5\:\textrm{V}$ signalling.
3. This signal uses a HI for MARK (in RS-232, a MARK is a negative voltage), so this must be logic level output from a micro and not RS-232 signalling.

If you take the required START bit and the minimum one-bit-time STOP away, this means there is probably at least seven remaining bit times for data:

The above would be interpreted an 0x2A regardless of endianness, if I'm paying attention.

However, this would be the chart for eight data bits:

In this case, the interpretation would be either 0xAA or else 0x55, depending on the endian nature of the stream. So this could represent your 0xAA (little endian, which I believe is more common.)

As you can see, the transmitter and receiver must a priori agree on the number of data bits and the endian nature of them.

The scope results could be interpreted as even longer serial word sizes. I have seen them before (9, most commonly, as some ICs used to support it but I've even seen 10 used before.)

Without agreement, it's difficult to be sure.

As a sidebar:

I remember the days when teletypes were moving from 5 bits to 6 bits (early 1960's DTE) right at the time RS-232 was created in 1960, as my dad had such a teletype sitting at home in an home office space. Six bit RS-232 communications did actually exist for a period of time.

ASCII coding was widely used during the late 1960's and early 1970's and is a 7-bit coding. It was very common for RS-232 data communications to use 7 bits of data.

Later, as communications ICs and microcontrollers came into common use and 8-bit register sizes were abundantly available, RS-232 was often extended to transmit/receive 8 bits at a time.

I think most people today just expect it to be used for 8-bit communications. But that wasn't always the case.

• I think the data could also be the two bytes 0x98 0xE6 at 19,200, broken down as s00011001Ss01100111S [s=start S=stop]. Some characters like "A" [0x41] generate bit patterns that cannot be created by any other baud rate (likely why Hayes chose "A" as the first character for the autobaud-training sequence) but the pattern above would represent a valid two-byte sequence at 19,200 baud. – supercat Sep 11 '17 at 21:56
• I used to be the proud owner of a mechanical teletype printer machine. It was entirely mechanical and ran at 60baud. Well entirely mechanical if you don't count solenoids and a synchronous motor. The start bit released a clutch and a selector wheel started turning and things happened in sequence there after to position the print head and fire the hammer. It was so cool to watch. Had to leave it behind in the UK when I came to Canada. It was rather too heavy to ship. – Trevor_G Sep 11 '17 at 22:12
• Pretty sure that's one of the main reasons rs232 had such extreme drive voltages and currents though. There was nothing in between, just RS232 cable --> solenoid. – Trevor_G Sep 11 '17 at 22:18
• @supercat Yeah. It could be divided down in time, as well. These variations are starting to get to the point where a book is required, though. But your point is certainly taken. – jonk Sep 11 '17 at 22:21
• @Trevor I never owned one, but I had often used the KSR-35 (a very impressive mechanical cam-based machine) and the later, much cheaper ASR-33/KSR-33 units. The one my dad had in our home (before he died in a traffic accident) wasn't any of these, but was an earlier 6-bit code device similar in size to the ASR-33. – jonk Sep 11 '17 at 22:23

If this is for a microcontroller, it's not possible to determine the baud rate from it's oscillator but an 8MHz crystal is definitely able to create 9600 baud.

Can you measure and tell me the exact time from the first low to the last high? - The first space looks slightly off to me. It seems to me you are using a trigger, can you move it slightly higher because if it is an edge trigger and sitting on the peaks, the oscilloscope will possibly have trouble triggering.

• If you sample the signal and measure the smallest width encountered it is trivial to calculate the rate. Sooner or later a start bit has to be followed by a '1'. – mckenzm Aug 14 '19 at 0:03

Determining baud rate from a scope trace is sometimes but not always possible.

The baud rate is the inverse of the bit period but the signal can remain in the same state for many bit periods so you can't always unambiguously determine the bit period from the scope trace.

Assuming 8 bit data and no parity your waveform could represent a single byte with a bit period of ~100ns but it could also represent two bytes with a bit period of about 50ns.