What is BAUD?

Status
Not open for further replies.

Marks256

New Member
Ok, before you (the reader) even give me the link to google (with a snotty comment), or the link to wikipedia's article, i will say that I ALREADY READ THEM.

That being said, what is baud? I didn't understand the wikipedia article. From what i got from wikipedia, it is number of bits/second. Is that right? I really don't get it. Also, what would some examples be?
 
The BAUD rate is the speed on either a SPI or a I2C line. It's the hardware in e.g. a PIC that determines the maximum baud rate for data transmission.
 

I won't try and compete with wikipeda but let me try and give you my simple definition. It's a term from the telecommunications industry and was/is used as a speed signaling element description for modem communications.

In that context baud does not necessarily mean bits-per-second, it depends on the modulation method used. There are modulation methods that cause a higher bits-per-second rate then the baud rate, however many of the simpler and slower modems did have a one to one relationship between bps and baud rate.

Modem modulation methods can be quite complex and it all related to trying to come up with methods to get higher and higher bps rates over landline voice channels that have a fixed bandwidth of around 3 khz.

Now a days when referring to baud rate it is usually in reference to the clock speed used to convert digital serial data from and to parallel data in UART type hardware or software and has nothing to do with any modulation method, and in that reference baud and bits-per-second are equal.

Lefty
 
BAUD is the speed in which a signal changes on a dataline. Not to be confused with Bits/second.

If a BIT takes 2 Signals too send, (high/low/whatever), than a Byte (8 BITS) will take 2 * 8 = 16 Signals.

So, if you have 9600 BAUD and the serial protocol your using requires 2 signals/bit, then you’re transmission speed would be
9600 / (2*8)
9600 / 16 = 600 Bytes/Second.

2 signals/bit was just an example... it could be anything, for example Manchester encoding and USART would have different Bytes/Second with the same baud
 
the signal change - what ever it maybe (High to Low, or Low To High To Low) - that represents a Bit (1 or 0) is one baud.

How many signal changes per second = BAUD.

BAUD / Number Of signals Per Bit = Bit Per Second

Bit Per Second / 8 = Bytes Per Second
 
You have to factor in overhead such as start, stop, and parity bits.

In ansync mode if you use 8 data bits, 1 start bit, 1 stop bit, and even parity that would be 3 bits of overhead. So it would be
Bit Per Second (on the line) / 11 (bits to send a byte) = Bytes Per Second.

The thing that may be confusing about the Wikipedia info is the phrase "distinct symbol changes" (signalling events). Most everything you do with the PIC will use two signals. High and Low. It does not matter if it is RS232, RS485 or I2C, there are only two things we can do with our two signals. We can go from "Low to High" or "High to Lo". If we were using a modem of some sort there would be many more symbols.
 
When sending data at 300 baud, the data line is clocked at the speed of 300 bits per second. So every 3.33ms the data line is updated/read (based on sending/receiving) for a data bit (1 or 0). If your sending binary 11111111 (or 00000000 if the protocol is inverted) the data line will just stay hi for those 8/300 of a second. The extra bits come from Start, Stop, and Parity bits. If the protocol you used included all 3, each byte took 11 bits to send. So even though you where running at 300 bits per second, 81 of those bits where part of the protocol and you only sent 219 data bits. BUT, you where still running at 300baud, which is 300bits per second.

edit: Looks like 3V0 posted while I was posting, but you get the idea
 
Last edited:

Not really correct, consider Manchester encoding. Each Bit requires two signals (high-low or low-high) to represent a bit (1 or 0).

What I'm trying to say is, it depends on the encoding/protocol used - but BAUD will always = Signal Changes/Second (Inclusive of start/end/data bits/CRC checks/parity/anything), and is not to be confused with Bits/Second, or Bytes/Second
 
Last edited:
No need to be sorry.

If one includes the details the next poster simplifies it.

If one keeps it simple the next poster adds the details.

etc. etc.
 
gramo said:
Not really correct, consider Manchester encoding. Each Bit requires two signals (high-low or low-high) to represent a bit (1 or 0).

Sorry, you are correct.

gramo said:
What I'm trying to say is, it depends on the encoding/protocol used - but BAUD always = Signal Changes/Second (Inclusive of start/end/data bits/CRC checks/parity/anything)

Agreed.

Goes to show how confusing it can be to figure out what protocol a device uses when they specify XXX Baud.
 
Gaston said:
so would it be correct to say that the baud rate is the clock frequency??

Depends on the protocol, USART doesn’t use a clock signal, but its baud must be very stable, and the number of bytes/second depends on the settings (start bits/stop bits/parity etc) as they will eat away at the baud

I2C does use a clock, and in that case BAUD = Clock speed, Same too with SPI. But both have small differences such as ACK, BSTART, BSTOP used with I2C (they are not data bits, but signals required by the protocol)

1-Wire is different again. It uses large addresses/CRC data to ensure the data is legit and for the right device. So the baud will be much higher than the Bytes/Second.

All depends what encoding/protocol you use, but the concept is the same, BAUD = Actual Signals Per Second
 
Beautiful Gramo, Beautiful! The Baud has often confused me myself and I see that you have a profound understanding of this & have explained it well. I shall be consulting this some time again.
 
Let's not forget Monsieur Baudot who originated the whole thing by coming up with a code for sending alphanumeric data to teletypes.
 
aibelectronics said:
Beautiful Gramo, Beautiful! The Baud has often confused me myself and I see that you have a profound understanding of this & have explained it well. I shall be consulting this some time again.

Hey, no problems, just sharing some insight
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…