jbn@glacier.STANFORD.EDU (John B. Nagle) (06/21/88)
I'd like to transmit 9600 baud, simplex, (one-way) over a good-quality
audio channel that can handle at least 10KHz. The transmit end must be
small and consume modest power; this is a telemetry application. Telephone
oriented modems assume a much narrower audio bandwidth (about 3-4KHz) and
thus must use very elaborate techniques to cram 9600 baud into that narrow
a bandwidth. I'm looking for something simpler, with about 1 baud/Hz
channel utilization. This should be about as complex as a 2400 baud modem,
for which there exist single-chip versions such as the Fairchild
F2224. But that chip can't be turned up to 9600 baud, as far as I know.
Any better ideas?
The guys who want to push more bits through VHF FM repeaters might
have some ideas on this.
John Naglebill@videovax.Tek.COM (William K. McFadden) (06/24/88)
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?"
brian@cbw1.UUCP (Brian Cuthie) (06/26/88)
In article <5063@videovax.Tek.COM> bill@videovax.Tek.COM (William K. McFadden) 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 The first problem I see with this is that the audio path is not DC coupled and thus you would have big problems with data that was all marking. Now if you MFM encoded the data you might get by, but I doubt it. This is why people invented modems for phone lines (audio channels -- right ?). -brian CASE Communications Inc. High Speed Modem Group Columibia, MD 21046 -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu "Captain, Captain! All the stars have gone out!" "No, you fool,you've leaned on the button. Turn the viewer back on!"
charles@c3engr.UUCP (Charles Green) (06/27/88)
In article <189@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >In article <5063@videovax.Tek.COM> bill@videovax.Tek.COM (William K. McFadden) writes: >>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 >The first problem I see with this is that the audio path is not DC coupled >and thus you would have big problems with data that was all marking. Now if I would expect his Schmitt trigger to take care of that; data that was all marking would be seen as approaching 0 volts at the receiving end. The trigger will fire only on the edges of the input waveform, as the output voltage exceeds the hysteresis. For example: +V --- --- --- --- --- Input 0V (data all marking) -V --- -------------------------- --- --- --- _ ++V -- _ +V -__ -__ (ac coupling goes to 0) -- -__ __ Output 0V ____------------------- __ Threshold +V _-- _-- - _-- _-- -- Note that after the marking condition, you have a higher-than-normal positive voltage, but provided that your receive threshold is correctly set, you should still be okay, although noise certainly needs to be dealt with. >you MFM encoded the data you might get by, but I doubt it. This is why >people invented modems for phone lines (audio channels -- right ?). I would expect that the technique of locking onto a frequency-shift signal (a la Bell modems) to be relatively immune to noise, as is FM ("No Static at All!"). -- #ident "@(#).signature 1.5 :~charles/s..signature 04/27/88 21:40:43" TwoBitNet: 460 Herndon Pkwy, Herndon, VA 22091-1928 UUCP:decuac!c3*!charles
johng@trwind.UUCP (06/29/88)
In article <189@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >In article <5063@videovax.Tek.COM> bill@videovax.Tek.COM (William K. McFadden) 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 > >The first problem I see with this is that the audio path is not DC coupled >and thus you would have big problems with data that was all marking. Now if >you MFM encoded the data you might get by, but I doubt it. This is why >people invented modems for phone lines (audio channels -- right ?). > This type of thing has been done before by Standard Microsystems Corporation (SMC) with their ARCNET chipset. Data Rates of up to 2.5 MegaBits/sec have been acheived on standard phone line. The Network driver IC (COM9032 I think) is rather extpensive (~$30) but the concept it operates on can be done descreetly for little money. It transmits a 'dipulse' for a logical 1 and nothing for a zero. Since RS232 characters are framed with a start and stop bit, it should not require anything special to reconstuct the signals. The data book is pretty decriptive on how it works and I think that it even has a partial schematic of what is inside of the chip. Hope this helps. -- John E. Greene "People are just like frankfurters....You have to decide if you're going to be a hot dog or just another wiener" DLR TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505 ARPA: johng@trwind.ind.TRW.COM USENET: ..trwrb!trwind!johng
brian@cbw1.UUCP (Brian Cuthie) (07/03/88)
In article <403@trwind.UUCP> johng@trwind.UUCP (John Greene) writes: >In article <189@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >>In article <5063@videovax.Tek.COM> bill@videovax.Tek.COM (William K. McFadden) 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 >> >>The first problem I see with this is that the audio path is not DC coupled >>and thus you would have big problems with data that was all marking. Now if >>you MFM encoded the data you might get by, but I doubt it. This is why >>people invented modems for phone lines (audio channels -- right ?). >> > >This type of thing has been done before by Standard Microsystems Corporation >(SMC) with their ARCNET chipset. Data Rates of up to 2.5 MegaBits/sec have >been acheived on standard phone line. The Network driver IC (COM9032 I think) Actually, the reason that works is because you have a whole lot more bandwidth over that line that you would think. If you want to pass data through the PSTN (public switched telephone network) or any other bandwidth limited channel, then you MUST modulate the data on a carrier that will be passed by the channel. The "di-bit" scheme will not work through audio channels (phone lines, other than 3002 DC continuity circuits, are considered to be audio paths) because the channel will act as a low pass filter and change the shape of the pulses to the point that they will be completely meaningless by the time the get to the other end; if they even pass. What a modem does, is modulate the data onto a carrier that is well within the bandwidth limits of the channel presented by a phone line. You can get away without a modem so long as the channel (read: wire) doesn't have any low pass filters (like loading coils). This is exactly how the ISDN system is supposed to work. Since most audio paths are bandwidth limited to about 20 to 20k hz (at best), you are going to have big troubles passing raw di-bits through them. Good luck though. If you can make it work you will put the whole modem industry out of business (of course so will ISDN -- eventually). cheers, Brian Cuthie CASE communications Columbia, MD 21046 -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu "Captain, Captain! All the stars have gone out!" "No, you fool, you've leaned on the button. Turn the viewer back on!"