Searching \ for '[EE] byte stream to audio and back to byte stream.' 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=audio
Search entire site for: 'byte stream to audio and back to byte stream.'.

Exact match. Not showing close matches.
PICList Thread
'[EE] byte stream to audio and back to byte stream.'
2005\02\11@135110 by crayola

flavicon
face
A while back I asked for some help regarding converting
a stream of data (made up from the following set of data)
into an audio signal that could be recorded on a cdrom. When the audio was played back it needs to be converted back into the original stream of data and fed out a serial connection (to control some servos).

Sync/Command bit     Servo number            Position
255                           1-254                        1-254
       
Several of you suggested looking into a modem on a chip type
IC to do the generation and decoding of the audio and them record
audio or process the resulting data. I looked into this quite a bit but I cant seem to find a modem IC that doesn’t require training/synchronization to occur before sending or receiving data.
So I looked into DTMF tones to represent the data but I found
out that DTMF decoding requires a minimum 20ms tone and a minimum 40ms pause between tones. This would only allow me to send a couple sets of data per second. I am shooting for 30 sets of data per second.
Does anyone else have ideas on how to generate an audio signal that can cleanly encode 90 bytes per second (3 bytes per set X 30 sets/ Sec). And then decode that audio signal back into the original data stream from a recorded source (Some sort of simple IC that could be
interfaced with a PIC would be great:)
Thanks, Mike

2005\02\11@143153 by Howard Winter

face
flavicon
picon face
Mike,

On Fri, 11 Feb 2005 13:50:26 -0500, spam_OUTcrayolaTakeThisOuTspamoptonline.net wrote:

{Quote hidden}

You're talking about chips designed for full-duplex cable communications.  Did you look at the MX614P as sold by "Glitchbuster"?  It's used (among other things) for Amateur Radio Packet modems - and they certainly don't "train or synchronise" because the communication is one-way at a time (and there may be multiple recipients)  and any error detection and correction is done higher up the stack.  Have a look at  http://www.glitchbuster.com  and follow the link he has to a project using it.

Cheers,


Howard Winter
St.Albans, England

2005\02\11@151146 by Mario Mendes Jr.

flavicon
face
I was not part of the list when the original thread came around, but this
sounds to me exactly what older computers (tandy, trs80, etc) did to
access programs/data stored in tapes.  You just plugged the tape recorder
to the back of you PC and that was it.

90 bytes/sec = 720 bits/sec, less data than the older 2.4 Kbaud modems
used to handle.  I think you can easily use a pic or some other mcu
connected to a nice set of ad/da converters do to the job for you, or at
least one of these new generation DSP chips from Microchip, TI or
Motorola.

-Mario

{Quote hidden}

>

2005\02\11@155551 by Jinx

face picon face
> sounds to me exactly what older computers (tandy, trs80, etc) did to
> access programs/data stored in tapes.  You just plugged the tape
> recorder to the back of you PC and that was it.
>
> 90 bytes/sec = 720 bits/sec, less data than the older 2.4 Kbaud
> modems used to handle.  I think you can easily use a pic or some
> other mcu connected to a nice set of ad/da converters do to the job
> for you, or at least one of these new generation DSP chips from
> Microchip, TI or Motorola

The Commodore 64's Datasette amplified and logic-squared output
goes straight to the 6526 CIA /FLAG pin, which is an edge-sensitive
input like the PIC's PortB.0. From memory that signal was at least a
volt or two either side of 2.5V. Some commercial tapes were weaker,
probably high-speed copied, but the signal still managed to cross the
logic levels on /FLAG. Also the program was written on to tape twice
and a verification done between the two loads

BTW, disk input processing through the serial port was based on tape
processing s/w and terribly slow until someone came up with a turbo
wedge for the 1541 drive routines. The 6526, a wonderful little IC,
was capable of much faster throughput than the conservative storage
density of original tape/disk. Later tapes/floppies installed a turbo first
and then were able to use much faster transfers from denser data


2005\02\11@165402 by Martin K

flavicon
face


.....crayolaKILLspamspam@spam@optonline.net wrote:
{Quote hidden}

I'm interested in your application because you say you need to record to a CD and play it back.
Is it limited to the audio interface?
CDs are digital by nature of course, having native digital outs as well as linear audio, for a computer CD drive...
Perhaps you could do some experiments with making a wave file with your streamed data converted to audio via a "1-bit DAC" (fully on/fully off)
data would come out as SPDIF which could either be handled by itself or downclocked by a counter (the 1x audio rate is many more bps than you need)

Maybe you could do FSK with 10/15khz
(or not, I don't know anything about FSK really)

-- Martin K
http://wwia.org/sgroup/biofuel

2005\02\11@210557 by Michael Cunningham

flavicon
face
> You're talking about chips designed for full-duplex cable
> communications.  Did you look at the MX614P as sold
> by "Glitchbuster"?  It's used (among other things) for
> Amateur Radio Packet modems - and they certainly don't
> "train or synchronise" because the communication is one-way
> at a time (and there may be multiple recipients)  
> and any error detection and correction is done higher up the
> stack.  Have a look at  
> http://www.glitchbuster.com  and follow the link he has to a
> project using it.

I never thought of Packet Radio.. dam that is exactly what I need.
I looked into the MX614P and the project he links to... turns out
that there is a kit avaliable from "far circuits" which does the
entire conversion process for me. This is perfect.

Audio in serial out and vice versa... Plus it supports 1200 baud which
should be more then enough to send 90 bytes per second.

Thanks for the advice,

Mike


2005\02\11@213945 by Mark Jordan

flavicon
face
On 11 Feb 2005 at 21:05, Michael Cunningham wrote:

> I looked into the MX614P and the project he links to... turns out
> that there is a kit avaliable from "far circuits" which does the
> entire conversion process for me. This is perfect.
>
> Audio in serial out and vice versa... Plus it supports 1200 baud which
> should be more then enough to send 90 bytes per second.

       The MX614P doesn't do full duplex communication.

       Mark Jordan


2005\02\11@221028 by Russell McMahon

face
flavicon
face
> I never thought of Packet Radio.. dam that is exactly what I need.
> I looked into the MX614P and the project he links to... turns out
> that there is a kit avaliable from "far circuits" which does the
> entire conversion process for me. This is perfect.
>
> Audio in serial out and vice versa... Plus it supports 1200 baud
> which
> should be more then enough to send 90 bytes per second.

When I provided information a while ago I mentioned several 1200 baud
modem ICs. None require training of any sort.
However, you may need a short period of channel time prior to data
being sent for the received signal to stabilise at "mark" level. Prior
to this, if a modem IC sees an empty channel it is liable to output
random symbols due to noise. Sending a "marking" level (logical one,
usually +Vdd data input) to the modem will stabilise the output. It is
possible to produce a modem which will not toggle its output in the
absence of a clear signal, but this usually adds to the complexity
beyond what you need. In your case, if you are able to always have a
clear "carrier"/mark signal present when not sending data then you
will have no problems. If you system defaults to "silence" in the
absence of data, you will need to do some extra work. Still not
complicated.


       RM

2005\02\11@221337 by Russell McMahon

face
flavicon
face
> The MX614P doesn't do full duplex communication.

AFAIK - His application is off tape or CD so it's very much half
duplex.



       RM

2005\02\14@050833 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu]
>Sent: 12 February 2005 03:11
>To: Microcontroller discussion list - Public.
>Subject: Re: [EE] byte stream to audio and back to byte stream.
>
>
>> The MX614P doesn't do full duplex communication.
>
>AFAIK - His application is off tape or CD so it's very much half
>duplex.

If it's off CD it's more likely to be simplex n'est pas?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

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