How to demonstrate the effect of baudrate in serial communication

Question

Regarding baudrate in serial communication, the only requirement is that both devices operate at the same rate. The common baud rates are 1200, 2400, 4800, 9600, 19200, 38400, 57600, and 115200 ect. And especially what I see is that 9600 is the most popular.

On the other hand I also see in some C codes for microcontrollers they also for instance use much higher baudrates such as 115200. Now all the time in my encounter whenever I reduce the baudrates to 9600 or even more the system still works. Last time I think I tried with an encoder and changing the baudrates did not change any functioning in practice. I simply lowered the original baudrate which was 115200 to 9600 and there was no problem. Why would they set it to high baudrate when lower works it is a mystery for me. (¿)

Since I didn't encounter any example in my micro environment and limited experience, I'm very curious to know when would baoudrate start to affect a system. Some encountered examples would help a lot. I even appreciate if one can suggest a simple setup where I can spot the error or an issue due to low baudrate. I can use an Arduino and HyperTerminal to test such a communication. What I want to observe is that lets say we have the Arduino is nonstop sending some fixed data to the serial port and we read that with a program such as HyperTerminal with a baudrate of 115200. Let's say we start to lower the baudrate and we observe at a particular baudrate we get/read nonsense. What would be the idea to create such a test? I mean I need to relate the data somehow to the transmission speed aka baudrate.

Answer 1

The baudrate determines the data rate on transmissions. If you need a certain speed you can estimate the minimum baudrate needed. Whether data is lost or "just" delayed depends on the operational conditions if the baudrate is too low.

Higher baudrates need more bandwidth on the wire, so shorter wires or "better" technologies are needed. The standards like RS232 and RS485 have some informations on this matter.

---

Some background:

The baudrate defines how many steps per second are transferred over a serial channel. The standard serial line we use can only transport 1 bit at a time, so the baudrate is equal to the bitrate.

Since you seem to use the common "asynchronous protocol" each transmission consists of:

1. The startbit;
2. 5 to 8 data bits;
3. Optionally a parity bit (mark, space, even, or odd);
4. 1, 1.5, or 2 stop bits.

The protocol is called "asynchronous" because there is no need to be synchronous to any kind of global clock. Between a stop bit and the next start bit any time gap is allowed, beginning with 0 (zero) and ending in infinity.

A standard combination is "8-N-1" which means 8 data bits, no parity, and 1 stop bit. This sums up to 10 bits per 8-bit byte to transfer. It is a nice value because we can easily calculate the bytes per second for a given baudrate. It happens to be the default on Arduino's class Serial.

With 9600 baud the transmission speed will be at maximum 9600 / 10 = 960 bytes per second, with 115200 baud it will be 11520 bytes per second. The lowest standard baudrate I know of is 75 baud, giving seven-and-a-half bytes per second.

Now try this little sketch. Note: since I don't have an Arduino at hand it is not tested and may contain errors.

int round = 0;

void setup() {
    Serial.begin(1200);
}

void loop() {
    round++;
    Serial.print("This is round #");
    Serial.print(round);
    Serial.println(". Can you follow the numbers?");
}

Try this with several different baudrates and especially with low values you should see an effect.

Note: This only holds true if there is a true serial line involved. Some devices use an internal USB unit to realize a virtual COM port. You can set up any baudrate and it will have no effect because the bytes are transferred with the USB's speed.

Answer 2

The answer is pretty obvious - baud rates define data transmission speed. If you are using AT commands and typing them by hand, you won't see any difference, because the bottleneck is you. If you are transmitting larger amount of data, there will be difference. Try setting up a serial transceiver in loopback (connect RX and TX together) and then send 1kB of data over serial. At first do it at, say, 1200 baud and then 115200. You will notice the difference, because first will go in 1024/(1200/8) 6+ seconds, other will go way under a second.

Usually people try to go for as high baudrate as the system can tolerate without failing. Only when transmission errors start appearing you would start reverting to lower baud rate.

I have a system that has to transmit images (5MB) over serial line, even at max standard baud rate of 921k it is too slow (110kBps, whole image takes 50s to transmit). I have boosted the speed to non-standard 8Mbaud, thus reducing the transmit time tenfold, at the expense of extra hardware and code - have to have packet verification and error checking, hardware that supports these high baud rates, etc.

Answer 3

We have systems that consist of around 80 sensors which all talk to the host over RS-485 using MODBUS. The host sends a 10-byte command to each sensor, which then responds with an 8-byte packet. Running at 9600 bits per second (ignoring start/stop bits for sake of simplicity) the "round-trip" communication time for the 80 sensors is around 3 seconds. That is much too long for our application as there is a substantial time difference between when the first sensor is read and when the last sensor is read. Therefore we bumped our baud rate up to 115.2 kbps, which reduces the round-trip time to approximately 250 milliseconds. This is still very slow, but it is an order of magnitude faster. We would go to a higher baud rate to reduce the cycle time, but due to run lengths and cable restrictions, going faster than 115.2 kbps could have a negative impact on signal integrity.

Higher baud rate is much preferred for applications where timing is critical. Timing is not as critical when you're simply viewing the results on a terminal because the human brain cannot really recognize small timing variations when reading text.