I'm still trying to debug this RS232-to-TTL converter board that I've made, shown below.

My RS232-to-TTL board and my setup

Now I think I've narrowed down the problem to speed:

  • it works fine at 57,600 baud;
  • but it inserts some errors during comm at 115,200 baud.

This time I tested the board with a simple echo firmware below, which basically echos back whatever comes into the serial port.

void setup() { 
void loop() {
  if (Serial.available() > 0) {

At 57,600 baud, it returns a series of B chars without errors, as below.


At 115,200 baud, a few errors make into the output.


The error rate seems to be fairly constant and it's always the same. Note that the difference between B and  ASCII char codes is just one bit negated and another one shifted one position left.

B - 01000001
 - 11000010
    ^     ^

The MAX232 datasheet says it works up to 120 kbps, so I think my board is causing the problem.

So, that's the new evidence I've got so far. My question is: What would be the likely reason for the problems with my converter?

Here's a picture of my board design, if that helps. Disregard the TX and RX LEDs, I've disconnected them.

enter image description here

  • 1
    \$\begingroup\$ Does your board use a 16MHz crystal the same as an Arduino? I had a look and at wormfood.net/avrbaudcalc.php and the error will be 3.7% - should be OK if the USB converter is accurate (which they normally are) but could be worth checking the bit timing of the TX line on both with a scope. \$\endgroup\$ – PeterJ Apr 1 '14 at 2:29
  • \$\begingroup\$ @PeterJ - Yes, my target board, where the ATmega328 sits, does have a 16MHz crystal, just like an Arduino. \$\endgroup\$ – Ricardo Apr 1 '14 at 2:33
  • \$\begingroup\$ @PeterJ - I'm getting about 4.5% error at 115,200, which is compatible with that table. But I'm not getting the 2.1% for 57,600 (I'm getting zero). But I would be surprised if that was the cause of my problem, because I have an Arduino Single Sided Serial board that has a similar converter and doesn't show that error rate at that speed. Anyway, that's helpful advice, thanks! \$\endgroup\$ – Ricardo Apr 1 '14 at 2:40

It is probably the crystal on your target board.

A 16 MHz rock probably can't generate a clock for 115200 baud exactly enough. Over a long enough continuous stream of characters, the clocks on the two devices will slide out of sync. Eventually, you will get a framing error and a bad character, and the devices will resynchronize on the next falling edge (START bit).

The fact that your errors are roughly periodic tends to support this hypothesis. I saw a similar problem (at much lower speed) on a modem line to a minicomputer many, many years ago.

If you can feed your UART with a clock that is exactly correct for 115200, do that, and see what happens. (If you have access to a really good, EXPENSIVE, signal generator, use that.)

|improve this answer|||||
  • \$\begingroup\$ That may be it, yes. But the strangest thing is that I have another converter board (without the MAX232 IC, just using the transistor trick) that doesn't give me the same problem even connected to that same target Arduino board. It must be something in the converter board that's adding noise or error, but I'm not sure. I don't have an high-end signal generator, but I'll probe the board with my scope (again) just to check the timing. Thanks! +1 \$\endgroup\$ – Ricardo Apr 1 '14 at 11:55
  • 1
    \$\begingroup\$ @Ricardo: When you probe the board, you might try setting your test pattern to be a continuous stream of upper-case U. The ASCII code is 0x55, which gives you a perfect square wave at 1/2 the baud rate. Probe in both directions. \$\endgroup\$ – John R. Strohm Apr 1 '14 at 12:44

I suppose it's 16MHz crystal problem as mentioned in comment. You should get 3.7%@115200, not 4.5%. Hence maybe 0%@57600 instead of datasheet's 2.1% may be crystal inaccuarcy. Anyway I also cannot use 115200@16MHz against any "precise" serial device. No problem at Arduino 2560 board using 2560<->16u2<->USB chain because 2560 and 16u2 have the same crystal (i.e. baud error) and USB serial speed is just a virtual rate.

Try echoing of char with more one-bits and inspect what bit shift occurs in response.

The error nicely reveals if you connect logic analyzer with UART decoder ;-)

|improve this answer|||||

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.