Searching \ for '%VoicePorts---Audio->A/D->UART->RS-232 TX & RX%' 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'.

Sub string 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@040110 by John Welling
flavicon
face
I am reposting updated message as my mail server was down due to T-1
upgrade.
All response are most welcome amd encouraged!  Please RePost previous
responses!

PI>>> Telephone handset Audio into A/D converter sampling 8-bit bytes at
PI>>> 22,050 sample rate with serial data fed to UART(16550) outputting 57,600
PI>>> bit rate to MAX-232 RS-232 driver.

PI>Why bother with 22,050 samples/second with telephone handsets?  They
PI>were designed for a frequency range of ~300 to ~3000 Hertz.  Most of
PI>the carbon microphones and little speakers used in handsets just don't
PI>have the frequency response to justify this high a sample rate.

PI>Telephone companies chose 8,000 8-bit samples/second to give an upper
PI>frequency response of ~4000 Hertz (Nyquist limit).

'Scuse me for the bungled numbers.  I composed the Email from 3
categories of calculations not interchangeable.

The following is more reflective of reality:
57,600 baud Port * .8=46080 net data baud (less start & stop bits) /8
(bits per byte)=
5760 bytes/sec  / 2 = 2880 max Nyquist frequency.

I am going to try PIC 16c74 A/D sampling to its UART with BASIC and  'C'
code.
Does anyone know the Maximum A/D sampling and UART port speeds when
using:
1> PIC or ETI BASIC
2> compiled 'C' code (.OBJ)

ALSO, does anyone have info for intializing 16550 UART as standalone
FIFO-serial/parallel port interface

1996\08\23@091906 by Mark K Sullivan

flavicon
face
>I am going to try PIC 16c74 A/D sampling to its UART with BASIC and  'C'
>code.

You really ought  to do this in assembler.  It's not hard.  In fact, I bet it
will be much harder to make the project work in BASIC than it will be to learn
enough assembler.  It's going to be less than 100 lines of code, maybe less than
50.

- Mark Sullivan -

1996\08\23@094209 by root

flavicon
face
{Quote hidden}

       Having just finished a project with the 16550, I can tell you it
is very easy to use and initialize...  I would suggest checking out
National Semiconductor's web site (http://www.natsemi.com) where they have .PDF
documents on line with the complete 16550 manual being one of them
(you'll need to do a search on 16550 to find it).  The only thing I found
annoying about the 16550 was the Intel-ish practice of requiring the R*
and W* lines to only be active when CS* is.

Good Luck!


Larry Battraw

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\23@150803 by peter

flavicon
face
Mark K Sullivan wrote:
> You really ought  to do this in assembler.  It's not hard.  In fact, I bet it
> will be much harder to make the project work in BASIC than it will be to learn
> enough assembler.  It's going to be less than 100 lines of code, maybe less
than
> 50.
>
> - Mark Sullivan -
Sorry this must be the most popular question
how do you start to program in assembler. I have mplab,embedded
controls handbook etc.
Will mplab run ok without hardware.
Is mplab good to start on
--
Peter Cousens
email: KILLspampeterKILLspamspamcousens.her.forthnet.gr
snailmail: Peter Cousens, karteros, Heraklion, Crete, 75100, Greece,

1996\08\24@061647 by John Welling

flavicon
face
PI>        Having just finished a project with the 16550, I can tell you it
PI>is very easy to use and initialize...  I would suggest checking out
PI>National Semiconductor's web site (http://www.natsemi.com) where they have .PDF
PI>documents on line with the complete 16550 manual being one of them
PI>(you'll need to do a search on 16550 to find it).  The only thing I found
PI>annoying about the 16550 was the Intel-ish practice of requiring the R*
PI>and W* lines to only be active when CS* is.

1> Is it possible to feed a sequence burst of init/config bytes to the 16550,
say from a PC parallel port buffered into the UART so that it could be a
standalone UART without CPU supervision?

2>Can the RX & TX sections be linked together as a standalone serial data time
shifter
( 8Kbps serial data in->Parallel FIFO Buffer->57.6 Kbps serial data out
)?

Many DANDY Answers received from around the World...Keep 'em coming!

TIA, John
RemoveMEsirejohnTakeThisOuTspambbs-la.com

1996\08\24@065913 by Clyde Smith-Stubbs

flavicon
face
John Welling <spamBeGonesirejohnspamBeGonespamBBS-LA.COM> wrote:

(quoting someone else, presumably)

> PI>The only thing I found
> PI>annoying about the 16550 was the Intel-ish practice of requiring the R*
> PI>and W* lines to only be active when CS* is.

This is not correct - the RD, /RD, WR and /WR lines are ignored unless the
chip is selected. It is a little unusual in providing both active high and
low read and write lines - they are or'ed so you must tie the unused ones
to an inactive level.

>j 1> Is it possible to feed a sequence burst of init/config bytes to the 16550,
> say from a PC parallel port buffered into the UART so that it could be a
> standalone UART without CPU supervision?

You could do that, if you could arrange to drive the address lines as well. The
16550 has 8 register addresses, and intialising the chip requires writing
to a number of these. You may be able to use some of the control lines from
a parallel port as address lines.

> 2>Can the RX & TX sections be linked together as a standalone serial data time
> shifter
> ( 8Kbps serial data in->Parallel FIFO Buffer->57.6 Kbps serial data out

You would need an external baud rate generator for the receiver, a data latch
and some glue logic (a 16V8 GAL should do it). Something like the old AY-5-1013
would be easier - if there is an equivalent still available (they were a 40
pin chip with basically an independent RX and TX with non-multiplexed data
in and out and control).

Clyde

--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
TakeThisOuTclydeEraseMEspamspam_OUThitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
---------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email RemoveMEinfospamTakeThisOuThitech.com.au

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
> dfrEraseMEspam.....icom.ca
I think this should have been sent to the piclist
--
Peter Cousens
email: EraseMEpeterspamcousens.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
RemoveMEdfrEraseMEspamEraseMEicom.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...