ANTONIO_GELLINEAU@TZONE.CEO.DG.COM (09/13/88)
I am interested in finding an algorithm to match to a modem's baud rate with a user providing at most one or two characters. Is there such an algorithm? Is there a unique bit pattern for a character at each baud rate (.ie 300, 1200, 2400, 4800, etc) given I am receiving at a given rate? For example, if a user has called in at 2400 baud to my system and my modem adjusted to the 2400 baud and sends me (the system) characters at 2400 baud, but the system is set up for 300 baud. Can I figure out I should be at 2400 baud in a couple of characters? Thanks in advance. acg@tzone.ceo.dg.com Standard disclaimers.
thad@cup.portal.com (09/19/88)
Whew! A "loaded" question (re: autobaud) In general, autobaud detection necessitates your system being set up at some "high" baud and analyzing the bits that arrive when a caller types some character (typically a carriage return). Using a UART, you'll ALSO get framing errors (from the UART) unless the bauds are already matched. I developed some autobaud detection schemes by trial and error and discovered that if the baud disparity is greater than 4x you're gonna be SOL unless you adopt a technique as used by DEC. DEC's scheme (as with VAX/VMS), appears to start at 19,200 baud and steps down until a recognizable character is seen ... the serial channel's baud is then "set" to that rate. This may neccessitate typing 4 or 5 CRs until successful communication is established. My scheme (basically) matches incoming bits (ignoring any framing errs) against data tables determined experimentally; usually a match is found within one CR, sometimes two. Autotraining modems (such as Hayes' (tm)) use, I believe, analog circuitry. Not so bad, considering the expected range of bauds is 300, 1200 or 2400. The "older" AT&T 212A modems used pin 12 (on the RS-232 connection) as a high speed indicator. Asserted TRUE, the baud was (presumed) 1200; otherwise it wa assumed 103J (0-300) (and, note, the assertions were negative logic; but this is clear from the modem's manuals). As a side note, has anyone else used a MC68681 (dual UART) as an adjunct to an MC6801/6803? I still am tickled pink having interfaced this in a commercial product (1000's sold) when, normally, people interface 8-bit peripherals to, say, the MC68000 family. Oh well! :-) Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
mhyman@cup.portal.com (09/20/88)
Autobauding modems look at the incoming _bit_ stream. As long as the first character sent has a low order bit set the modem simply sees how long the start bit is. The letter A (as in AT) has a low order bit that is 1. [The low order bit is sent first]. --Marc ...!sun!portal!cup.portal.? rcom!mhyman mhyman@cup.portal.com
rick@pcrat.UUCP (Rick Richardson) (09/20/88)
In article <9262@cup.portal.com> thad@cup.portal.com writes: > >In general, autobaud detection necessitates your system being set up at some >"high" baud and analyzing the bits that arrive when a caller types some >character (typically a carriage return). There are three basic methods: 1) Pattern match the garbage that comes in on the UART. 2) If a USART, put in sync mode, sync char==FF at a bit rate twice the highest speed expected. Then collect the bits and analyze, and restore async mode. 3) Use a UART which supports hardware autobaud, such as AT&T's ARTI (can't remember part no). The ideal, of course, is single character autobaud. I've implemented all three of these methods. They are listed in the order I tried them over the years, which is also the order from worst to best implementation. #3 is patented (I'm one of the inventors) and I don't know if it has been licensed to any other chip manufacturer. -- Rick Richardson, PC Research, Inc. rick%pcrat.uucp@uunet.uu.net (INTERNET) uunet!pcrat!rick (UUCP, Personal Mail) ..!pcrat!jetroff (JetRoff Info) ..!pcrat!dry2 (Dhrystone Submissions)
berger@clio.las.uiuc.edu (09/21/88)
The most effective method I've seen was to use several uarts on each
incoming line. Every one was examined for proper character, framing,
and parity errors. That way only a single keypress was needed to
do autobaud detect.
Mike Berger
Department of Statistics
Science, Technology, and Society
University of Illinois
berger@clio.las.uiuc.edu
{ihnp4 | convex | pur-ee}!uiucuxc!clio!bergermatt@ncr-sd.SanDiego.NCR.COM (Matt Costello) (09/21/88)
In article <9262@cup.portal.com> thad@cup.portal.com writes: >In general, autobaud detection necessitates your system being set up at some >"high" baud and analyzing the bits that arrive when a caller types some >character (typically a carriage return). It is easy if you've got a USART rather than a UART. Place the USART into synchronous mode with a clock rate several times higher than your maximum expected baud rate. You can then measure the bit times of the first incoming character. Take the smallest bit period and that is your bps rate. Under normal circumstances you will want to constrain the bit rates to 'legal' values. This sort of thing was real common back in the days of the Intel 8251, and was the one thing I missed when the WD 8250 "ACE" replaced it as the chip of choice. With the 8251, putting it into synchronous mode gave you the raw bit data at 16 times the bps rate. At the system level the easiest autobauding consists of using a "smart" modem that will convert everything on your side to a fixed rate. It is much easier to let the modem manufacturers worry about it. -- Matt Costello <matt.costello@SanDiego.NCR.COM> +1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET> {ucsd,att,pyramid,nosc.mil}!ncr-sd!matt
blume@netmbx.UUCP (Heiko Blume) (09/26/88)
i've once seen a table with things like "a <CR> sent with 2400 looks like
'~x' when received as 1200' etc....
that was used to determine the baud rate of the caller. to avoid trouble
with line noise, one also was able to switch rates in a circular manner
through sending breaks.
fortunately modems like hst and tb allow to fix the rate between comp
& modem :-)
--
Heiko Blume | smart : blume@netbmx.UUCP
Seekorso 29 | dumb : ...!{pyramid,unido,altger}!tmpmbx!netmbx!blume
1 Berlin 22 | voice : (+49 30) 365 55 71 | bbs : (+49 30) 365 75 01
WestGermany | telex : 183008 intro d | fax : (+49 30) 882 50 65rwi@naucse.UUCP (Robert Wier) (09/29/88)
I once wrote a program for a 6800 a number of years ago
(running on a Southwest Tech - anybody remember them?) which was
to be used in an amateur radio situation. Radioteletype (or RTTY)
can come in over the airwaves from anywhere in the world and you are
likely to run into some pretty strange formats (although there are
some recognized "standards"). Since I was particulary interested
in reading the new service wires (Brazilian soccer scores, etc.),
my micro would sit there and sample the output from the TU
(terminal unit ... basically an decode from off the air modem).
Since the micro could sample tens of times at the baud rates
involved, I implemented an autobaud function by sampling some
of the bits going by, and then taking what appeared to be the
shortest mark time that appeared consistantly (to get rid of noist
spikes, etc). From this I could then calculate what the baud
rate should be. This generally worked pretty well, except on
exceptionally hight noise signals (QRM). It was less easy to
automatically decide if I was listening to Baudot or ASCII signals,
although I had some success by sampling in the 4th, 5th, and 6th
bit positions. I could determine that by waiting for an extended
mark condition, and then taking the first bit that came through
as the start bit, having already determined the baud rate. If the
6th bit (or was it 7th?) bit was consistantly a mark (or was it
space ? - things are a bit fuzzy now) then it had to be baudot
since I was seeing the stop bit. Otherwise it was probably ASCII.
Once I got it going, I saw all sorts of strange conbinations, like
450 baud with mark-space inverted. Course if they were encrypted
or multiplexing several data streams onto the same channel, it blew
me out of the water. Interesting project, though.
-- Bob Wier (WB5KXH) - Flagstaff, Az.
...!arizona!naucse!rwi