1

I want to read values of arduino pins and send it to PC via USB cable. The problem is that byte writing/reading happens at a rate which is ~10 times smaller than specifies baud rate of a serial port.

I writing a 8 chars to serial 'abcdefgh' and then println adds two more symbols '\r\n', so it is 10 bytes per line (I have separately checked that reading time scales linearly with number of bytes per line). Here is my arduino code for the case of specifed baud rate = 9600.

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

void loop() {
  for (char c ='a'; c < 'h'; c++)
    Serial.print(c);
  Serial.println('h');
}

Next I am using python to read serial port and measure elapsed time (I have also used Matlab and got the same results)

import numpy as np
import serial 
import time

ser = serial.Serial('COM5', 9600);

bytes_per_line = 10;
num_lines = 1000;
lines = np.empty(num_lines, dtype='|S11');

t0 = time.time()
for i in range(num_lines):
    lines[i] = ser.readline();
t1 = time.time()

ser.close();

baud_calc = bytes_per_line*num_lines/(t1-t0);

For the specified baud rate of 9600 I only measure 837, I also test baud rates of 38400, 74880, 230400, 5e5, 1e6, 2e6 (I scale number of lines to read with the baud rate such that total read takes ~10 seconds). You can see result on the graph below.

Measured baud rate

Legend of the plot the following:

  • blue: measured baud rate
  • red: unachievable perfect baud rate (i.e. measured = specified)
  • black: baud rate of 230400 that I would like to achieve for my applications.

P.S. The reason I want baud to be 230400 is that I am reading values on GPIB cable and I see that data I measure does not correspond to what I know about GPIB protocol. To be more precise, I see that number of different states of GPIB cable increases when I increase baud rate.

4
  • Baud is in bits per second, or at least symbol per second. With a start bit and stop bit, you get a byte per serial 10 bits. Is that a surprise or am I misreading something? – timemage Jun 17 at 23:06
  • 1
    @timemage yes, that is a surprise. Thank you. I guess my question is stupid and you have answered it. I still don't understand why my readings are not fast enough for GPIB though. – David Saykin Jun 17 at 23:24
  • Well, it's certainly formatted and everything. If there remains part of the question unanswered you can always edit it to remove the the more trivial byte/bit mixup and leave the question about the other parts. – timemage Jun 17 at 23:26
  • 2
    Your measuring method is flawed. At the time you record t0, the Arduino may be resetting, and will not start transmitting until quite some time later. It is also very likely that at t0 the RX buffer of your PC is already full, and the first calls to ser.readline() just read (very fast) form that buffer. I suggest reading many kilobytes before recording t0. This would ensure that you have reached the steady state. In steady state, the receiving speed should match the transmission speed. – Edgar Bonet Jun 18 at 7:29
0

As timemage points out, Baud is Bits per second. Since the default frame format for the serial port uses 8 Data Bits, 1 Start Bit, 1 Stop Bit and no parity, that makes 10 Bits per character. So the theoretical limit at 9600 Baud is 960 characters (or bytes) per second. If that's transmitted as single chars as you do it in your example, some software overhead is added as well that will cause a small gap between the transmission of two characters. I would guess that's about 10%. With that in mind, your measurements are completely reasonable.

To improve performance, try changing your arduino code to

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

void loop() {
  Serial.println("abcdefgh");
}

That should reduce the overhead a bit and increase your throughput, so you get closer to the theoretical limit. But achieving 230400 Bytes/Second is probably not possible (I suspect the "dent" in your curve comes from approaching another limitation, such as the CPU speed).

4
  • Yeah, I definitely made a mistake and confused bytes and bits, but now that I am updating my measurements, they still don't make sense to me. For example now sometimes measured baud becomes larger than specified baud. – David Saykin Jun 18 at 6:08
  • @DavidSaykin That's weird. Can you share your updated graph? – PMF Jun 18 at 6:18
  • 1
    There is no software overhead. The UART transmitting the bytes and the CPU processing instructions happen in parallel. Only at the highest baud rates, when the UART starts emptying the TX buffer faster than the CPU can fill it, you start getting gaps in the transmission. – Edgar Bonet Jun 18 at 7:21
  • 2
    Pedantic note: a baud is a symbol/second and with binary data, a baud corresponds effectively to a bit/second. – Sacha Jun 18 at 8:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.