Path: utzoo!attcan!uunet!tektronix!tekcrl!tekfdi!videovax!bill
From: bill@videovax.Tek.COM (William K. McFadden)
Newsgroups: comp.dcom.modems
Subject: Re: 9600 baud over high-quality audio channel
Keywords: modem
Message-ID: <5063@videovax.Tek.COM>
Date: 24 Jun 88 00:06:24 GMT
References: <17507@glacier.STANFORD.EDU>
Reply-To: bill@videovax.Tek.COM (William K. McFadden)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 49

In article <17507@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes:

>     I'd like to transmit 9600 baud, simplex, (one-way) over a good-quality
>audio channel that can handle at least 10KHz.

This might seem too obvious, but why not connect the output of your RS-232 port
directly to the input of your audio channel (using suitable attenuation and DC
blocking)?  At the receive end you would probably want some sort of active
filtering and schmitt triggering to recover the data.  The problems I could
see with this are: no error correction, and the DC level of your data is not
guaranteed to be constant.  Using software, you could encode your data to avoid
these problems.  This would be cheapest from a hardware standpoint, but rather
dependent on software.

Another method is one that a friend of mine used to build a cassette interface.
In this method you use a microprocessor to generate one frequency for mark and
a different one for space.  For example, if your highest frequency has a period
of t, then one transition (high-to-low or low-to-high) per period would be a
zero, and two transitions would be a one.  This has an advantage over the
previous method because the output has a constant DC level (e.g., it is always
an AC signal).  The receive end would be the same as the last example with a
microprocessor decoding the input.

A (very) little theory:

In the first example, the raw data is sent over the interface.  Somebody's
(Shannon's?) theorem says you need b/2 bandwidth for data where b is the baud
rate.  We can see this by looking at an RS-232 link sending
an uppercase U (ignore the start and stop bits for the moment).  This gives a
bit pattern of 0 1 0 1 0 1 0 1.  Each of these bits occupies 1/b seconds (e.g.,
1/9600 for a 9600 baud link).  We can see it takes two of these bauds to
complete one cycle, so the frequency is b/2 (e.g., 4800 Hz for a 9600 baud
link).  Thus, a 10 KHz channel could carry data at 19200 baud.  Likewise, 9600
baud data would require a 5 KHz channel.  This all assumes a noiseless channel,
of course.  Adding noise would reduce the maximum data rate for a given
channel, but I don't remember the exact relationship.

In the second channel, you can see the bandwidth is b, rather than b/2 because
now we are using a half-cycle of carrier for zero and a whole cycle for one.
Hence, a continuous stream of ones would produce a tone of frequency b.  A 9600
baud link would require a 10 KHz channel.

Well, there's a couple of ideas.  The implementation is left as an exercise for
the reader.  If I got any of this wrong, I'm sure we'll all hear about it.

-- 
Bill McFadden    Tektronix, Inc.  P.O. Box 500  MS 58-639  Beaverton, OR  97077
UUCP: bill@videovax.Tek.COM,  {hplabs,uw-beaver,decvax}!tektronix!videovax!bill
GTE: (503) 627-6920         "How can I prove I am not crazy to people who are?"