Automatically Detecting Serial Baud Rate As discussed on the prior page, the transmitter and receiver each needs to be within 2% of the agreed bps/baud rate to ensure accurate serial communication. Usually this means pre-programming or configuring the rate in both devices, and using either an individually compensated oscillator or a crystal. Correct USART communication requires the transmission and reception baud rates to be matched reasonably closely, otherwise communication errors may occur. Automatic baud rate detection is useful when establishing a communication link between two devices, where the slave device is able to detect the baud rate of the master controller.
Google brings this site:
www.iol.ie/~ecarroll/autobaud.html
In this scheme, a known ascii character - [noparse][[/noparse]Return] key - is sent to the micro which initially starts rec'ving at 9600. If the sending baud rate is different then the rec'ving 9600, the rec'vd data is 'corrupted' in a known fashion which the code in the micro can distinguish and adjust for, ending up with the correct timing.
Well, I don't have the luxury of sending out a known character to calibrate , so to speak, the rec'ing baud rate of the micro. I'm connecting to devices with unknown data streams at odd baud rates (8800, for example).
I'm thinking of measuring the period of bits first rec'vd , finding the shortest one and assuming that's the period for the correct baud rate. I need to figure out the proper baud rate after rec'ving one byte and respond correctly to continue the handshakes.
Is there any another algorithm for auto baud rate detection I could consider?
Thanks,
Kevin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!
Comments
- edited 2008-11-29 17:13All of the methods for automatic Baud detection rely on some knowledge of the incoming character stream, usually that there are characters coming in with a little time between them so that the start bit can be detected. Usually the characters are odd in value so that the start bit (0) is always followed by a one bit and the width of the start bit is used to set the Baud.
Your suggestion to measure the width of pulses received and assume that these represent received bits, finding the shortest one and using that for determining the Baud, is reasonable, but don't expect any reliability with arbitrary data streams. I don't think you'll find any better algorithm though. The problem is that the first character that comes along may have no single isolated bits and you'll end up with a Baud that's half or a third of the correct Baud. If there's any noise in the datastream, your Baud detection will be thrown off by that.
Basically, you've got a bad situation. There is no good solution, but what you suggest will work some of the time. If you can put in a timeout where the whole system resets if synchronization fails and it starts over from the beginning, you at least will have some chance of achieving communications. - edited 2008-12-12 16:31Thanks, Mike for the reply.
As an aside to dealing with non-standard baud rates, I've found a neat and free terminal program called RealTerm. Works great for diagnosing serial streams.
realterm.sourceforge.net/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!
DNC Wizard | |
| |
| |
| |
| |
|