Searching \ for 'VoicePorts---Audio->A/D->UART->RS-232 TX & RX rvrs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/audio.htm?key=voice
Search entire site for: 'VoicePorts---Audio->A/D->UART->RS-232 TX & RX rvrs'.

Truncated match.
PICList Thread
'VoicePorts---Audio->A/D->UART->RS-232 TX & RX rvrs'
1996\08\22@045003 by John Welling

flavicon
face
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)

 RX AUDIO<--DAC0808<--74HC154<--16550<------MAX232<-----RS-232--<
                        (D/A conv.)      (ser/par)    (UART)    (Level
Shifter)
                          (convert)

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?

TIA,
-John
spam_OUTsirejohnTakeThisOuTspambbs-la.com

1996\08\22@093921 by liebchen

flavicon
face
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

--

+-----------------------------------------------+
! Wolfram Liebchen, .....liebchenKILLspamspam@spam@ipserv.ffo.fgan.de !
!        Forschungsinstitut fuer Optik          !
+-----------------------------------------------+

1996\08\22@100938 by mfahrion

flavicon
face
> 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.

-mike
mfahrionspamKILLspambb-elec.com

1996\08\22@213646 by Lee Jones

flavicon
face
>> 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             .....leeKILLspamspam.....frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

1996\08\23@113014 by Dana Frank Raymond
flavicon
face
>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).

Hope this helps.

Regards, Dana Frank Raymond
EraseMEdfrspam_OUTspamTakeThisOuTicom.ca

1996\08\23@140437 by peter

flavicon
face
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
> dfrspamspam_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@peterKILLspamspamcousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,

1996\08\24@164811 by peter

flavicon
face
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
> KILLspamdfrKILLspamspamicom.ca
I think this should have been sent to the piclist
--
Peter Cousens
email: RemoveMEpeterTakeThisOuTspamcousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,

1996\08\27@134248 by Dana Frank Raymond

flavicon
face
>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
spamBeGonedfrspamBeGonespamicom.ca

1996\08\27@192204 by Robert Lunn

flavicon
face
>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.

       PCM     64,000 bps
       ADPCM   32,000 bps
       G.728   16,000 bps
       G.729    8,000 bps

       These are all ITU standards.  I don't think G.729 has been
       formally ratified, though.

       G.728 and G.729 are computationally intensive and are normally
       implemented with DSP's.

___Bob

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...