Data Communication via Audio

Simon_Ampleman

Hello,

·· I would like to achieve data communication on a audio cable that connects between the propeller and a old PC Sound Card Microphone Input.

···I've seen the Bell 202 object (AFSK 1200 BPS) which works fine.

···However, since I am directly connected between the microcontroller and the PC with a short length cable, I am wondering if I could achieve a faster speed and a faster to decode algorithm (in terms of cpu operation) on the PC.

·· The PC has a standard sound card, so it·records at fast rate (up to 48000hz) with 8 or 16 bits per sample.

···If possible, I would like the PC to receive 1600 decoded bits per second·(200 decoded bytes/sec)·with a minimum cpu usage.

·· As I understand, the AFSK 1200 BPS·can achieve·872·decoded bits per second·(1 start bit, 8 data bits, 2 stops bits). And the PC needs to calculate Fourier Power Coefficient on 19200 sub-samples per second. That is a lot of operation I would like to avoid.

·· Any idea? Any standard protocol exists ?

Thank you!

Simon

Mike Green

There are all sorts of standard protocols, but they don't use AFSK 1200 BPS (see: en.wikipedia.org/wiki/List_of_device_bandwidths. Follow the links to articles on the various modem standards.

All of these faster protocols are more complex than the Bell 202 standard (similar to V.23) and the coding / decoding process is more complicated.

If you're directly connected via a short length cable, why not use digital signalling and bypass the sound card completely. Does your PC have a spare serial port? Does it have USB so you could use a USB to serial converter?

If you're handling specific data, how about compressing it so that you get higher throughput over a 1200 BPS channel? How about encoding whatever data you want to transfer?

Simon_Ampleman

Thanks for your reply Mike.

I want to use the audio port since I want to run my final project on iPhone, Palm Pre, Zune·and·Android.

Audio recording is always available and doesn't require to use custom connector different for each platform and their specific libraries (when available).

I thought that I·could simply use a simple·115200 bps N-8-1 protocol on·the audio·line or manchester encoding...

44000hz 8 bits sampling (352000 bps?) would be enough to read that signal, right? Why to use FSK ?

I·am·a software developer, so I can code it, but have no idea about the physical·limitation yet...·I've seen that the·BeauNet protocol can share data between two·propeller at amazing speed... The sound card·might not·have a fast enough sampling rate to achieve this particular speed, but·I can't believe it cannot·deliver more than 1200 bps...

I·don't want to add compression yet because I have a very limited number of cpu cycles·for the audio task and also because I would like to·get near·0·ms·latency.

Thank you,

Simon

tonyp12

As the audio is analog, no need not just using 1 or 0 but in analog levels in between too.

http://en.wikipedia.org/wiki/Quadrature_amplitude_modulation


·

Mike Green

The problem is that you're dealing with an audio channel with a frequency response on the order of 20Hz to 20KHz at best. You'll have a signal above the low frequency limit if only because you can include a start and stop bit which will guarantee at least one cycle per byte, but the upper frequency limit will limit the maximum Baud possible. If you want to run your final project on a wireless phone, you're even more limited. All of the ones you've mentioned use some kind of digitization of the audio and, in the interest of conserving bandwidth, limit the audio range to more like 300Hz to 3KHz maybe (if you're lucky) which is what is considered necessary for understanding voice. They get their higher speed data communications by using the underlying digital protocol directly for the data. You might be able to get the Bell 202 AFSK protocol to work through a wireless phone since it's used with an unconditioned voice channel in amateur radio, but there's no guarantee. You're unlikely to get any of the faster protocols to work through a wireless phone.

localroger

Simion, as a practical matter you're limited more by the bandwidth of the audio circuitry than by the ADC in the receiver; you have maybe 40 KHz in a very, very good quality link and that's it. 56K modems (which on real phone lines often couldn't achieve 56K) had to use very fancy tricks of encoding via both amplitude and bit sample; typically they had a low baud rate (the rate that the presented sample was changed) and got the rest of the data from the sample level. There's a lot of black magic involved, and that's best-case.

If you want to use relatively simple encoding you probably won't get much more than 1200 bits per second out of a normal monaural audio channel, and that won't be very reliable and will depend a lot on the architecture of the receiving amplifiers, ADC, and encoding scheme. I once had an off-brand 8 bit PC (circa 1977) that achieved 1200 baud on cassette tapes (when others, like the TRS-80, were doing 300 baud) by using clicks and timing the interval between clicks to differentiate between 1 and 0. On the platforms of interest to you you might even be able to get 2400 or even 4800 baud with a similar scheme. And it has the advantage of being very easy to decode with simple circuitry and simple software. But if you want to go any faster, you will need a lot of black magic both in hardware and software to make it reliable at all.

Phil Pilgrim (PhiPi)

My first computer, a Poly 88, used Manchester encoding (trade-named "Polyphase") to record data to audio tape cassettes at 2400 baud. Here is a document that includes a pretty exhaustive explanation of their encoding (data to audio) and decoding (audio to data) techniques:

www.hartetechnologies.com/manuals/PolyMorphic/Poly%2088%20Cassette%20Interface.pdf (p. 26 ff.)

-Phil

Simon_Ampleman

Thank you very much everyone for your help. It is very much appreciated!

Simon