"Ivan Shmakov" <oneingray@gmail.com> wrote in message news:86sj7iuetv.fsf@gray.siamics.net...> BTW, is there an easy way to autodetect the baud rate while > using an AVR UART? (Preferably something that works with > ATmega8, given that those MCU's are such a cheap thing > nowadays.) > > There're some ideas (and 8051 code) for that on [1], but I'd > like to know if there could be any better techniques. >Here's how I've done it in a commercial product that has to support auto-baud between 4800 and 57600 Baud on a fixed 8N1 format: Check the framing error bit in the receive interrupt handler. After 20 framing errors, switch to the next baud rate and reset the framing counter. Works like a charm. Meindert
baud rate autodetection on AVR 8-bit?
Started by ●December 7, 2012
Reply by ●December 10, 20122012-12-10
Reply by ●December 10, 20122012-12-10
>>>>> Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> writes: >>>>> "Ivan Shmakov" <oneingray@gmail.com> wrote in...>> BTW, is there an easy way to autodetect the baud rate while using an >> AVR UART? (Preferably something that works with ATmega8, given that >> those MCU's are such a cheap thing nowadays.) [...] > Here's how I've done it in a commercial product that has to support > auto-baud between 4800 and 57600 Baud on a fixed 8N1 format: > Check the framing error bit in the receive interrupt handler. After > 20 framing errors, switch to the next baud rate and reset the framing > counter. > Works like a charm. Doesn't it mean that the host has to transmit considerable amount of data for the device to adapt to the baud rate used? Given the possibility of "interactive" use, such a delay doesn't seem all that reasonable. Might work as a last resort, however. -- FSF associate member #7257
Reply by ●December 10, 20122012-12-10
"Ivan Shmakov" <oneingray@gmail.com> wrote in message news:8638zerqmq.fsf@gray.siamics.net...> >>>>> Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> writes: > > Here's how I've done it in a commercial product that has to support > > auto-baud between 4800 and 57600 Baud on a fixed 8N1 format: > > > Check the framing error bit in the receive interrupt handler. After > > 20 framing errors, switch to the next baud rate and reset the framing > > counter. > > > Works like a charm. > > Doesn't it mean that the host has to transmit considerable > amount of data for the device to adapt to the baud rate used? > Given the possibility of "interactive" use, such a delay doesn't > seem all that reasonable.It takes some time indeed. But in my application (receiving a constant data stream from navigation instruments), this is no problem. Meindert
Reply by ●December 10, 20122012-12-10
On 12/10/2012 04:24 PM, Meindert Sprang wrote:>> > Here's how I've done it in a commercial product that has to support >> > auto-baud between 4800 and 57600 Baud on a fixed 8N1 format: >> >> > Check the framing error bit in the receive interrupt handler. After >> > 20 framing errors, switch to the next baud rate and reset the framing >> > counter. >> >> > Works like a charm. >> >> Doesn't it mean that the host has to transmit considerable >> amount of data for the device to adapt to the baud rate used? >> Given the possibility of "interactive" use, such a delay doesn't >> seem all that reasonable. > > It takes some time indeed. But in my application (receiving a constant data > stream from navigation instruments), this is no problem.The time could be improved by keeping track of both well received data, and framing errors. At first, you could try a new baud rate after 2 or 3 framing errors, but as soon as you receive a couple of good chars, increase the tolerance for further framing errors. To improve detection time, save a good baudrate in non-volatile memory so it can be used as the first guess when the device powers up again.
Reply by ●December 12, 20122012-12-12
On Saturday, December 8, 2012 3:17:16 AM UTC+13, Ivan Shmakov wrote:> BTW, is there an easy way to autodetect the baud rate while > using an AVR UART?Most AutoBaud designs also send a known character to calibrate, and a pause. If you want to auto-detect on random data, that is more complex, and you will (usually) discard info while you are deciding. Then, even if your hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit... So there is no magic solution, but you can make systems that behave in a known way, reliable. Another approach is to start a baud dialog at a known low speed, and then exchange information about mutually supported higher rates, and then switch to that. If you want highest speeds, and widest clock-choice tolerance, that is the best approach.> PS. It seems that I'm slowly drifting into designing my own, AVR-based > Bus Pirate clone. The good news is that the parts for this one > will likely cost under $10... (connectors included.)Just to reality check that aspiration, I see Bus Pirate have moved to use a 256K Flash device. ["We didn't want to run out of space again soon, so we used a PIC 24FJ256GB106 with 256K of space."] So you might want to look at the ATXmega parts, as they have some good prices on smaller USB models. -jg
Reply by ●December 12, 20122012-12-12
On Tue, 11 Dec 2012 21:22:45 -0800 (PST), j.m.granville@gmail.com wrote:>On Saturday, December 8, 2012 3:17:16 AM UTC+13, Ivan Shmakov wrote: >> BTW, is there an easy way to autodetect the baud rate while >> using an AVR UART? > >Most AutoBaud designs also send a known character to calibrate, and a pause. > > If you want to auto-detect on random data, that is more complex, and you will (usually) discard info while you are deciding. Then, even if your hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit... > > So there is no magic solution, but you can make systems that behave in a known way, reliable.It's impossible to make baud autodetection 100% reliable without the cooperation of the sender. Consider that at 8-N-1, the single byte 0xB5 is indistinguishable from the pair 0x67, 0x67 at double the baud rate. Hardly the only such example, just a handy one. For a simple doubling of the baud rate at 8-N-1, an indistinguishable pair of bytes exists at the higher baud rate for any byte where the fourth bit (from the high end) is one and the fifth is zero at the lower baud rate.
Reply by ●December 12, 20122012-12-12
In article <nh8gc81516b289uhcdla34qrm3d1dhmsd0@4ax.com>, robertwessel2 @yahoo.com says...> > On Tue, 11 Dec 2012 21:22:45 -0800 (PST), j.m.granville@gmail.com > wrote: > > >On Saturday, December 8, 2012 3:17:16 AM UTC+13, Ivan Shmakov wrote: > >> BTW, is there an easy way to autodetect the baud rate while > >> using an AVR UART? > > > >Most AutoBaud designs also send a known character to calibrate, and a pause. > > > > If you want to auto-detect on random data, that is more complex, and you will (usually) discard info while you are deciding. Then, even if your hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit... > > > > So there is no magic solution, but you can make systems that behave in a known way, reliable. > > > It's impossible to make baud autodetection 100% reliable without the > cooperation of the sender. Consider that at 8-N-1, the single byte > 0xB5 is indistinguishable from the pair 0x67, 0x67 at double the baud > rate. Hardly the only such example, just a handy one. For a simple > doubling of the baud rate at 8-N-1, an indistinguishable pair of bytes > exists at the higher baud rate for any byte where the fourth bit (from > the high end) is one and the fifth is zero at the lower baud rate.I think that's true if you define " without cooperation" to mean that the receiver has absolutely no prior knowledge of the message from the sender and the data stream is continuous with no significant inter-character intervals. If you know that the data is ASCII text in a given language, you probably have enough data to get the baud rate correct, given a large enough sample size. It the data stream is encrypted binary data in a continuous stream, you've got more to worry about than just the baud rate! Mark Borgerson
Reply by ●December 12, 20122012-12-12
On Tue, 11 Dec 2012 23:43:54 -0800, Mark Borgerson <mborgerson@comcast.net> wrote:>In article <nh8gc81516b289uhcdla34qrm3d1dhmsd0@4ax.com>, robertwessel2 >@yahoo.com says... >> >> On Tue, 11 Dec 2012 21:22:45 -0800 (PST), j.m.granville@gmail.com >> wrote: >> >> >On Saturday, December 8, 2012 3:17:16 AM UTC+13, Ivan Shmakov wrote: >> >> BTW, is there an easy way to autodetect the baud rate while >> >> using an AVR UART? >> > >> >Most AutoBaud designs also send a known character to calibrate, and a pause. >> > >> > If you want to auto-detect on random data, that is more complex, and you will (usually) discard info while you are deciding. Then, even if your hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit... >> > >> > So there is no magic solution, but you can make systems that behave in a known way, reliable. >> >> >> It's impossible to make baud autodetection 100% reliable without the >> cooperation of the sender. Consider that at 8-N-1, the single byte >> 0xB5 is indistinguishable from the pair 0x67, 0x67 at double the baud >> rate. Hardly the only such example, just a handy one. For a simple >> doubling of the baud rate at 8-N-1, an indistinguishable pair of bytes >> exists at the higher baud rate for any byte where the fourth bit (from >> the high end) is one and the fifth is zero at the lower baud rate. > >I think that's true if you define " without cooperation" to mean that >the receiver has absolutely no prior knowledge of the message from >the sender and the data stream is continuous with no significant >inter-character intervals. If you know that the data is ASCII >text in a given language, you probably have enough data to get >the baud rate correct, given a large enough sample size. > >It the data stream is encrypted binary data in a continuous >stream, you've got more to worry about than just the baud rate!I'd consider sending a known (or at least constrained) stream to be cooperation. Obviously the tighter the constraints, the more quickly you can get to a required confidence level in your baud rate detection. As for inter-character gaps - it depends on the speeds and characters in question - so long as the low speed characters meet the xxx10xxx format requirement, then the double speed stream simply looks like two immediately adjacent characters, and gaps between individual low speed characters are just gaps between high speed pairs. My point was more that automatic baud rate detection is a hack, albeit a useful one in some circumstances, although it will always have limits. And frankly the use of RS-232/async ports should not be a first choice these days.
Reply by ●December 12, 20122012-12-12
On Mon, 10 Dec 2012 16:24:46 +0100, "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote:>"Ivan Shmakov" <oneingray@gmail.com> wrote in message >news:8638zerqmq.fsf@gray.siamics.net... >> >>>>> Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> writes: >> > Here's how I've done it in a commercial product that has to support >> > auto-baud between 4800 and 57600 Baud on a fixed 8N1 format: >> >> > Check the framing error bit in the receive interrupt handler. After >> > 20 framing errors, switch to the next baud rate and reset the framing >> > counter. >> >> > Works like a charm. >> >> Doesn't it mean that the host has to transmit considerable >> amount of data for the device to adapt to the baud rate used? >> Given the possibility of "interactive" use, such a delay doesn't >> seem all that reasonable. > >It takes some time indeed. But in my application (receiving a constant data >stream from navigation instruments), this is no problem.Here https://www.dropbox.com/s/tslyhurkxpnri32/BaudRateDetermination.pdf is an example of watching the pulse widths to infer the baud rate. It decides on the rate by the end of the NMEA identifier field, leaving the rest of that sentence available for sanity checks (framing errors, reasonable character set, etc.). There are certainly other approaches but I've been pretty successful with this. -- Rich Webb Norfolk, VA
Reply by ●December 12, 20122012-12-12
In article <rufgc89c170lh0o16ddk022rrsrhgq5qtd@4ax.com>, robertwessel2 @yahoo.com says...> > On Tue, 11 Dec 2012 23:43:54 -0800, Mark Borgerson > <mborgerson@comcast.net> wrote: > > >In article <nh8gc81516b289uhcdla34qrm3d1dhmsd0@4ax.com>, robertwessel2 > >@yahoo.com says... > >> > >> On Tue, 11 Dec 2012 21:22:45 -0800 (PST), j.m.granville@gmail.com > >> wrote: > >> > >> >On Saturday, December 8, 2012 3:17:16 AM UTC+13, Ivan Shmakov wrote: > >> >> BTW, is there an easy way to autodetect the baud rate while > >> >> using an AVR UART? > >> > > >> >Most AutoBaud designs also send a known character to calibrate, and a pause. > >> > > >> > If you want to auto-detect on random data, that is more complex, and you will (usually) discard info while you are deciding. Then, even if your hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit... > >> > > >> > So there is no magic solution, but you can make systems that behave in a known way, reliable. > >> > >> > >> It's impossible to make baud autodetection 100% reliable without the > >> cooperation of the sender. Consider that at 8-N-1, the single byte > >> 0xB5 is indistinguishable from the pair 0x67, 0x67 at double the baud > >> rate. Hardly the only such example, just a handy one. For a simple > >> doubling of the baud rate at 8-N-1, an indistinguishable pair of bytes > >> exists at the higher baud rate for any byte where the fourth bit (from > >> the high end) is one and the fifth is zero at the lower baud rate. > > > >I think that's true if you define " without cooperation" to mean that > >the receiver has absolutely no prior knowledge of the message from > >the sender and the data stream is continuous with no significant > >inter-character intervals. If you know that the data is ASCII > >text in a given language, you probably have enough data to get > >the baud rate correct, given a large enough sample size. > > > >It the data stream is encrypted binary data in a continuous > >stream, you've got more to worry about than just the baud rate! > > > I'd consider sending a known (or at least constrained) stream to be > cooperation. Obviously the tighter the constraints, the more quickly > you can get to a required confidence level in your baud rate > detection. > > As for inter-character gaps - it depends on the speeds and characters > in question - so long as the low speed characters meet the xxx10xxx > format requirement, then the double speed stream simply looks like two > immediately adjacent characters, and gaps between individual low speed > characters are just gaps between high speed pairs. > > My point was more that automatic baud rate detection is a hack, albeit > a useful one in some circumstances, although it will always have > limits. And frankly the use of RS-232/async ports should not be a > first choice these days.I still find them useful when connecting to oceanographic instruments. I have been able to get full-speed usb (12mb) through a pair of waterproof connectors, despite the impedance problems. I haven't yet tried to get USB through the connector and 20meters from the deck to the dry lab on a research vessel. I've also tried Zigbee radios, but they run into problems with aluminum pressure cases and deckhouses. One advantage that serial ports have over USB is that, with a properly designed receiving system, you have controlled latency that can allow time-stamping of incoming data. That's more difficult with USB or radio links where the data gets mashed together into packets and the reception time has little relation to the transmission time. Mark Borgerson
