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?"