# How to demonstrate the effect of baudrate in serial communication

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.

• Depends how much data you're sending and how much latency you can tolerate. The destination isn't always to a terminal for a human to read. I use 3Mbps to coordinate a bunch of motor controllers with each other and would go faster if I could. – DKNguyen Oct 30 '19 at 1:44
• Imagine 16 bit data data is sent from uC to PC with 9600 baud rate and then with 115200 baudrate, How can we compare these two cases? Will there be a latency seeing them on HyoerTerminal and can we estimate that latency? – user16307 Oct 30 '19 at 1:47
• Think about the time it takes between when the message is started and when it is finished being received. It can only be acted on once it's received. You can start executing a command sent at 115200 baud twelve times sooner than at 9600 baud (as long as it's a machine sending it with minimal delay between bytes. A human typing it out can't do that). – DKNguyen Oct 30 '19 at 1:48
• But wouldn it be a very small time like nanoseconds? I see some codes use 115200 and when I lower it to 9600 i cant observe any difference by naked eye looking at data stream, but yet why do you think 115200 is used for sending 16 bit data for an encoder which send the angle data? Maybe if it rotates too fast? – user16307 Oct 30 '19 at 1:49
• A 16 character command takes 1.7ms to finish transmitting at 9600bps when sent by a machine. At 115200bps it takes 142us. Why is 115200 used for sending 16-bit data? Let me flip that around on you. Why use 9600bps when you can use 115200? If you're using the encoder to commutate a motor or for a control system, 9600bps might be too slow. Even 115200bps might be too slow. The encoder might work just fine, but the thing depending on the encoder might not. – DKNguyen Oct 30 '19 at 2:02

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.

• I think you gotta correct "9600 / 10 = 9600" – user16307 Oct 31 '19 at 13:43
• @user16307 Thanks, proof-reading my own text does not always work. ;-) – the busybee Oct 31 '19 at 20:21

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.

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.

• Interesting but is there a modbus protocol or something like SSI where you can clock all sensors from the same clock and poll their data simultaneously? – user16307 Oct 30 '19 at 12:15
• Modbus must be sequential. It can trigger all sensors to take a reading simultaneously (called a broadcast) but it cannot read the data back from all of the sensors at the same time - only one at a time. Regardless, that gets away from your original question about why higher baud rates are sometimes required. – DerStrom8 Oct 30 '19 at 13:14