I am seeking a simple expedient path to a "VoicePort" audio digital
sampler to RS-232 port driver. Parameters for this device and
complementary receiver of reverse process are:
Telephone handset Audio into A/D converter sampling 8-bit bytes at
22,050 sample rate with serial data fed to UART(16550) outputting 57,600
bit rate to MAX-232 RS-232 driver.
Also needed is the reverse process for RS-232 data RX to D/A to decoded
audio from a SEPARATE port.
I would prefer standalone hardware for dedicated function without the
usual bulk of programming and debugging associated with 57k port speeds
to keep UNBROKEN STREAM OF DIGI-AUDIO DATA FLOW IN REAL TIME.
Basic Device Layout:
TX
AUDIO-->ADC0831------->16550------->MAX232--------------->RS-232-->
(A/D conv.) (UART) (Level Shifter)
I am reasonably sure about this design, but not experienced at how to
program/initialize the 16550 UARTs. Perhaps init/config data can be
loaded thru a parallel port buffered into the UART. This design was
chosen to avoid lengthy programming of any CPU's
because these VoicePorts are a mere FUNCTIONAL expediency to demo voice
thru RS-232 .
Also, if there is a more timely design to accomplish the objective,
I would be open to consider it. The above design is not mandatory. I
considered a PIC 16C74 with A/D and serial I/O with drawbacks of extra
hardware and interface for 8-bit D/A reverse process and extra load of
programming.
Tried to link PC soundcard Record & Play A/D-D/A functions to
RS-232, but 57,600 port speed precludes anything but custom Visual C++
pgrm to pipe .wav streamed I/O thru Win32 API (Win95 platform).
Does anyone have a better notion, preferably in specific chipset readily
available?
John Welling wrote:
>
> (snip)
> Telephone handset Audio into A/D converter sampling 8-bit bytes at
> 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
> bit rate to MAX-232 RS-232 driver.
> (snip)
John,
I can't follow your computation. If you have 22 kSamples/s, you would
need almost 200,000 bits/s (assuming 9 bits for asynchronous protocol).
> John Welling wrote:
> >
> > (snip)
> > Telephone handset Audio into A/D converter sampling 8-bit bytes at
> > 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
> > bit rate to MAX-232 RS-232 driver.
> > (snip)
>
> John,
>
> I can't follow your computation. If you have 22 kSamples/s, you would
> need almost 200,000 bits/s (assuming 9 bits for asynchronous protocol).
>
> Wolfram
I get the same result - but still shouldn't be a big problem. Using
"special" 232 transceivers you can easily go 230Kbaud and possibly
460Kbaud. That's a lot of interrupts though - I'd consider using a
16750 UART instead of the 16550A (64 byte FIFO's instead of 16) or
even something more specialized.
>> Telephone handset Audio into A/D converter sampling 8-bit bytes at
>> 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
>> bit rate to MAX-232 RS-232 driver.
Why bother with 22,050 samples/second with telephone handsets? They
were designed for a frequency range of ~300 to ~3000 Hertz. Most of
the carbon microphones and little speakers used in handsets just don't
have the frequency response to justify this high a sample rate.
Telephone companies chose 8,000 8-bit samples/second to give an upper
frequency response of ~4000 Hertz (Nyquist limit).
This is why the telephone companies use a 64,000 bits/second digital
data rate for each call. It's reflected in the ISDN bearer (B) and
DS1 (aka T-1 in USA, E-1 in Europe) channel signalling rates. [FYI:
56,000 bps is the result of stealing the low order bit for "robbed
bit" signalling of on-hook/off-hook state].
> I can't follow your computation. If you have 22 kSamples/s, you would
> need almost 200,000 bits/s (assuming 9 bits for asynchronous protocol).
Common asynchronous serial transmission uses 10 bits consisting of
1 start bit, 8 data bits, no seperate parity bit, and 1 stop bit. Thus,
22,050 8-bit samples per second requires 220,500 bits/second or higher
(ignoring flow control and error checking).
If you use a synchronous protocol, you could approach 176,400 bits per
second (22,050 samples/sec * 8 bits/sample). The actual data rate
would be higher due to frame synchronization data, packet size, etc.
> I get the same result - but still shouldn't be a big problem. Using
> "special" 232 transceivers you can easily go 230Kbaud and possibly
> 460Kbaud.
RS-232 was not designed to run at those speeds. It may; but EMI/RFI
may be a real issue. I'd switch to RS-422, RS-423, or RS-485.
Lee Jones
-------------------------------------------------------------------
Jones Computer Communications .....leeKILLspam.....frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711 voice: 909-621-9008
-------------------------------------------------------------------
>I am seeking a simple expedient path to a "VoicePort" audio digital
>sampler to RS-232 port driver. Parameters for this device and
John, when dealing with telephone audio a simple method of data compression
is frequently used: CVSD (Continuous Variable Slope Delta). I've seen CVSD
chips (called CODECs) used in PBXs and other telephony equipment - the
resulting audio quality is comparable to what Ma Bell delivers.
CVSD works as is follows:
A continuous single 8-16Khz digital bit stream is used to represent the
audio data. The Encoder keeps track of previous audio samples and only
indicates if the new sample is higher or lower than the last (0 vs 1) by a
step size (delta threshold). If the audio samples moves faster than the bit
rate can keep up with, a series of 3 zeros or ones will be sent and the
Encoder will increase the step size for the next sample (the Decoder will do
likewise).
Hence, CVSD is a Continuous, Variably Sloped, Delta system.
This method increases the digitization noise for high slew rate signals
(upper frequencies) but lowers it for the lower frequencies. Since the
frequency response of your typical phone system is 300-3300hz, but voices
contain most of their energy below 1.5Khz, the tradeoff works well.
CVSD enCOers/DECoders (CODECs) used to be readily available. However, you
can easily implement such an approach in PIC firmware! Think of it:
Acceptable telephone audio quality for 8Kbps instad of 8Ksps. This
translates into a data rate compression ratio of (roughly) 8:1. Even if you
have to go to 16Kbps to give good results you still save plenty of bandwidth.
I tried to find CVSD CODECs in my IC Master and library, but PCM now seems
to dominate. There was one from Plessy (MA367) but I don't have a datasheet
for it. I wanted to confirm that the data rate was in the 8-16Kbps range as
its been over 10 years that I dealt with this technology (in the Prodigy PBX
from Ericsson).
Dana Frank Raymond wrote,
snip,snip
> I tried to find CVSD CODECs in my IC Master and library, but PCM now seems
> to dominate. There was one from Plessy (MA367) but I don't have a datasheet
> for it. I wanted to confirm that the data rate was in the 8-16Kbps range as
> its been over 10 years that I dealt with this technology (in the Prodigy PBX
> from Ericsson).
>
> Hope this helps.
>
> Regards, Dana Frank Raymond
> dfrspam_OUTicom.ca
I used Motorola MC3517/8 they were very easy to use, but I don't know
current availability. Data was in the Motorola linear and interface
I C book
--
Peter Cousens
email: @spam@peterKILLspamcousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,
Dana Frank Raymond wrote:
>
> >I used Motorola MC3517/8 they were very easy to use, but I don't know
>
> Yes, thats them! I quote from Motorola's Q3/89 DL136 Rev.2
> (Telecommunications Device):
>
> "With minor modifications the circuit in Figure 14 may be operated anywhere
> from 9.6 kHz to 64 kHz clock rates. Obviously the higher the clock rate the
> higher the S/N performance." ... "Voice bandwidth systems will require no
> higher than 9600Hz. Some radio systems will allow 12Khz. Private 4-wire
> telephone systems are often operated at 16kHz and commerical telephone
> performance can be achieved at 32K bits and above. Other codecs may use bit
> rates up to 200 K bits/sec."
>
> Also... another, more modern technology that compresses voice band data is
> ADPCM. You may want to check into that if data rate is a problem.
>
> Regards, Dana Frank Raymond
> KILLspamdfrKILLspamicom.ca
I think this should have been sent to the piclist
--
Peter Cousens
email: RemoveMEpeterTakeThisOuTcousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,
>I used Motorola MC3517/8 they were very easy to use, but I don't know
Yes, thats them! I quote from Motorola's Q3/89 DL136 Rev.2
(Telecommunications Device):
"With minor modifications the circuit in Figure 14 may be operated anywhere
from 9.6 kHz to 64 kHz clock rates. Obviously the higher the clock rate the
higher the S/N performance." ... "Voice bandwidth systems will require no
higher than 9600Hz. Some radio systems will allow 12Khz. Private 4-wire
telephone systems are often operated at 16kHz and commerical telephone
performance can be achieved at 32K bits and above. Other codecs may use bit
rates up to 200 K bits/sec."
Also... another, more modern technology that compresses voice band data is
ADPCM. You may want to check into that if data rate is a problem.
bbs-la.com
