Autochanging of Rx baudrate on the fly

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

After reading the thread about the baud rates to a remote console
changing during the boot process, I got to wondering if it is possible
to keep the console at 115200 baud and then have a layer that
decodes the data at various "baud rates". I.e. is it possible to
actually decode the original data sent at the lower rates if the uart
is set to a higher rate ?

   Anton Erasmus

Re: Autochanging of Rx baudrate on the fly
Quoted text here. Click to load it

I was discussing this the other day, in relation to how (modern) modems
can operate at whatever baudrate you send to them.
You could either get the similar serial uart hardware into your PC, but i'm not
if this exists -i think it'd be a good idea and can't see it being very

I think we also decided it would be possible in software too, although i've
seen anything out there already and only have vague ideas on how to convert the
hardware clock-syncing methods into software algorithms.

if you write one yourself, let me know :)

Damion de Soto - Software Engineer  email:
We've slightly trimmed the long signature. Click to see the full one.
Re: Autochanging of Rx baudrate on the fly

Quoted text here. Click to load it
i'm not sure
Quoted text here. Click to load it
i've never
convert the

As far as I knew, the way modems handle "autobaud" is to measure the timing
of characters comming in, and try to match it to a sensible rate on the
assumption that it is an "A" (0x41) character at the start of an AT command.
Once they spot an "A", they lock on to that baud rate and can't easily be
changed.  I can't see how it would be practical to implement anything like
that on a PC without extra hardware.

What is practical, and I have done it many times (on small micros rather
than embedded linux, but the principle's the same) is to have two or three
different baud rates and switch between them.  If you hear incoming data
that makes sense, then "lock" to that baud rate (and maybe start switching
again after a certain timeout without new valid data).  It makes more sense
when using a telegram-oriented protocol rather than when using a simple
serial console, but it could be done (tell the user they must press "return"
a few times until they get a command prompt).

Re: Autochanging of Rx baudrate on the fly
Quoted text here. Click to load it

I suppose that might be possible, if the other site is required to send
one or more predefined characters.

When you receive such a character (e.g. a "U" = 0x55 which [8 databits,
no parity] has equally spaced high and low bits) it will show a
different pattern (one or more characters) when received at a high baud
rate and sent with different baud rates.


Re: Autochanging of Rx baudrate on the fly

Quoted text here. Click to load it

On 15 Sep 2003, wrote:

Quoted text here. Click to load it

   " "

In this thread, we discuss some ways to use UART error codes to detect
whether to increase or decrease the baud rate.  This is better than
plain cycling (order n) as oppose to the higher/lower scheme (order
ln2 n)...  N is the number of baud rates to search.

Niall Murphy gives a good link and there is some other interesting
information in the thread.  The implications are dependent on,

 1) Is a fixed character set to begin?
 2) Do you have access to UART break, parity, frame error, etc?
 3) Can you limit the baud rates to search?
 4) Can any garbage be accepted?

The auto-bauding modems probably have hardware that determines the
width of a start bit.  This is tricky as the modem might be
transmitting a zero.  However, at least one sections (start/stop)
should have a minimum width pulse from the transmit side and the exact
baud rate can be determined from the framing.

Bill Pringlemeir.

The lack of reason is overcome by the passion of belief - Anonymous

Site Timeline