rs232 baud rate error and crc16

Discussion in 'Embedded Systems and Microcontrollers' started by bug13, Jun 29, 2015.

  1. bug13

    Thread Starter Well-Known Member

    Feb 13, 2012
    1,208
    38
    Hi guys

    I am working on a project, a PC needs to send a packet (40 bytes) of data to my board. According the formula in the pic datasheet, my MCU is running at 16MHz, my baud rate error is: 0.16% (a little too high for my application)

    From what I can understand (I just learn this yesterday), if I use CRC-CCITT (CRC16) for error detection, the error of each byte in my packet of data is 0.0015%. If error detected, packet will be transmitted.

    So is it safe for me to say that the error rate is 0.0015% for the data I received at my MCU?

    Thanks guys!
     
  2. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,908
    2,168
    That is the clock error rate not the transmission error rate. Because typical RS232 is asynchronous, effectively resets clock drift every start bit and most of the USART devices can sample several times per bit , the clock error for 8 bits at 0.16% is undetectable at almost any usable baud rate. There are very good reasons to use CRC16 for error detection but that's not one of them.
     
    Last edited: Jun 29, 2015
  3. bug13

    Thread Starter Well-Known Member

    Feb 13, 2012
    1,208
    38
    So two more questions:
    • So I don't need CRC16? Or do I still need it for other reason, like detecting error cause by an electrical spike?
    • And I want to use higher baud rate, if I use 57.6K, it has error of 2.12%, and 115.2K has error of 8.51%, are they detectable? How do I work out if an error rate is too much?

    Thank you!
     
  4. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,908
    2,168
    I would use it for those reasons and if you have dropped bytes due to overruns caused missed interrupts or something like that. How much of a baud rate error the system can tolerate depends on the sender and receiver rates. If both are off by the same 8.51% in the same direction + or - speed it's much less of a problem than if it was the opposite directions for 2*8.51% then you would tend to get framing errors with noise on the signal at high speed. I would recommend keeping the baud error rate to about 2%. Sending 55 hex codes at the max system rate while looking for data or USART errors should give you an idea of what the transmission error rate is.

    You can also include error detection and correction in the packets.
    http://techref.massmind.org/techref/method/errors.htm
     
    bug13 likes this.
  5. Papabravo

    Expert

    Feb 24, 2006
    10,144
    1,790
    The best solution to your problem is to use a system frequency that is an integral multiple of the baudrate.
    For example I use 7.3728 MHz. in place of 8 MHz since it is 64 times 115,200 bits per second
    You could also use 14.7456 MHz.
     
    bug13 likes this.
  6. RJohnson

    New Member

    May 29, 2011
    21
    3
    Agree with Papabravo. One has to decide what's important, com port timing or timer timing with an even count crystal (ie: 8Mhz).
    If using an even count crystal only some baud rates will give the smallest error. 8 % is too much error for my taste.
     
    bug13 and Papabravo like this.
  7. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,908
    2,168
    I don't think you really need those higher rates for a 40 byte packet. The odds of having receiver overrun errors at 115.2K from missed interrupts (unless you have a FIFO or DMA) far exceed any gain in speed even if the baud rate error is zero.
     
    bug13 likes this.
  8. bug13

    Thread Starter Well-Known Member

    Feb 13, 2012
    1,208
    38
    I am using an internal osc, so I don't think I can get those frequency. But thank you for the advice, I will choose those frequency in the future if I need a good serial connection.
     
  9. Papabravo

    Expert

    Feb 24, 2006
    10,144
    1,790
    OK. So is it possible to use a nonstandard baudrate in such a way that your PIC with the internal oscillator is dead nuts and the other end adjusts to whatever odd baudrate you happen to be using? I seem to remember that 111,500 is workable on an ATmega128 @ 8 MHz.
     
    bug13 likes this.
  10. RJohnson

    New Member

    May 29, 2011
    21
    3
    Years ago I did a spreadsheet where I could plug in the crystal frequency and it would calculate all the register settings and error rates for the different baud rates.
    This was for Microchip parts. I still use it today. :)
     
Loading...