Audio over wireless serial

GaryT

I've been working on sending audio from Prop to Prop for a while and with help from Mike, Peter, and Tim, I've had some success. I'm sending low (very low) quality voice data, "Watson, I need you"[noparse];)[/noparse] Thanks guys!
Then I thought it would be REALLY cool without a wire, so, I'm wondering if anyone has done anything with transmitting audio using the Propeller and some kind of wireless device? Wireless analog seems like it would be great for that, is there a digital option? Just doing some quick math, it seems like at a rate of 115K (typical Zigbee type rate, I think) transmission rate would be too slow to send the data stream I'm generating now, and it's very poor anyway. Would there be some kind of compression possible? A CODEC type IC that's made for this? Or am I so naive that I'm asking stupid questions?(please be gentle if the answer is that I'm stupid.)

Thanks for any help, and all the other very useful posts!
Gary

BradC

64Kbit ADPCM at 8Khz should be easily doable over that.
That's usually enough for *excellent* voice quality.

Even without any processing, 8 bit - 8Khz is good voice quality.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

GreyBox Tim

Question - what do you consider quality? The amount of data you have to move depends on the quality of audio you need. For example if you are moving an 8-bit sample at 16kHz, you need to have a link with the capacity to send 128kbps just for the raw data (and this would sound pretty bad). As you say, the 115kbps Zigbee is still even too slow for that, but add in the over-head for the data alignment and clocking, and it's game over...

The least complicated thing to do would be to replicate a simplified version of the S/PDIF interface (specified by the AES3-2003 document). Take a look at this wikipedia entry on biphase mark code. Basically you take a clock at 2x the data rate, and every time there is a "1" for the data bit there is a transition at each (rising/falling) clock edge, for a "0" there is only a transition for the rising edge of the clock. This makes clock recovery fairly easy, as there are only two possible edge delays (either half a clock period for a "1" or a full clock period for a "0"). The AES and S/PDIF interfaces use a "frame header" pattern that does not conform to the biphase mark encoding scheme - where there is always an edge at least every clock cycle, but with the headers (three unique patterns for AES and S/PDIF since it's a stereo interface, and needs to encode low-speed meta data) this is not the case. To make it not look like an encoded bit, use three bit periods (6 clock edges), but invert the output from the previous state for three edges and then invert it again for another three (instead of two or one for valid data). This will maintain the favorable zero-DC average (less noise) and polarity agnostic characteristics - this is great if you need to drive a fiber-optic LED with a low-side switch as that will not require inversion on the receive side, or if you use an RS-485 transmitter and get the polarity of the wires swapped at either end .

A header would be encoded as: invertstate-laststate-laststate-invertstate-laststate-laststate
A "0" would be encoded as: invertstate-laststate
A "1" would be encoded as: invertstate-invertstate

As an example:

if the previous bit was "0" the header would be 1-1-1-0-0-0
if the previous bit was "1" the header would be 0-0-0-1-1-1
if the previous bit was "0" a zero data bit be would be 1-1
if the previous bit was "1" a zero data bit be would be 0-0
if the previous bit was "0" a one data bit be would be 1-0
if the previous bit was "1" a one data bit be would be 0-1


On the receive side, you look for edges. When you find an edge, you start counting until the next edge. You are looking for three lengths, of "multiple" value (i.e.: 1x, 2x and 3x). When you have enough samples of each (I'd aim for at least four instances of a "header" to get the initial average), then you'd wait for the next "3x" ("header") pattern to arrive, and then start decoding bits and writing them into your output word. The data should not be considered "valid" until you successfully get the next "header" where it is expected to be (if you don't get the header where it should be, it's probably a safe bet that something is wrong with the link). Additionally you can add a checksum to the stream (at the cost of more bandwidth being required), but at least do a parity bit encoded as data for another "gut-check" on the receive-side. For example, you can "add" the bits together (i.e. for 4-bits: 1 + 1 + 0 + 1 = 3) and take the LSB of that addition and use it as a parity data bit. This way, if you sent the example four bits, but got a "0" for the parity - the receiver should not consider the data "valid". You can output the result of this parity check (1/0 or Valid/Invalid respectively) at the end of each pattern's receipt then logically "AND" that result with the check that ensures the new header arrived when expected (1/0 or correct-spacing/incorrect-spacing respectively). The result from that logical AND can be sent to an indicator LED as a fairly simple "link good" status indicator for your receiver.

For a 16-bit sample at 16kHz, which would sound about like a telephone, you'd need 20 bit periods (three for the header, one for the parity, and 16 for the data). This would necessitate a link that could support 640kpbs (320kbps for the data itself, but with the clock embedded it's 2x). This rate is very do-able with cheap RS-485 transmitters or fiber-optics.

-Tim

Post Edited (GreyBox Tim) : 11/22/2008 6:34:19 AM GMT

GaryT

Brad, Thanks for the info! I looked into PCM and I think it's what I was looking for. Is something like a ETC5054N from STMicroelectronics a suitable device? The PCM info I found was a block diagram showing a microphone hooked to a CODEC device sending AD data to a PCM device at some rate and the PCM was compressing it and/or changing the rate, then sending it to the micrcontroller and then over a serial connection for de-compression in a mirror circuit at the other end. It looks like the ETC5054N is a CODEC and PCM combo, am I seeing that right? Any tips on where an beginner might find some circuit diagrams or examples for ADPCM use?

Thanks for any help,
Gary

BradC

Ok, that device is an aLaw/uLaw codec. It will give you standard telephone voice quality audio on a 64kbit connection. No examples, sorry.. but they are easy enough to interface to. ADPCM is a compression technique for audio, it will allow you to squeeze more samples or resolution down a given pipe but requires significantly more processing power and memory to implement. I was thinking you could quite comfortably implement a/uLaw codecs in software inside the propeller using the Sigma-Delta A/D on a pair of port pins. All those codecs do is take a 13 or 14 bit sample and use it to generate an 8 bit codeword, so you effectively compress 13 or 14 bits of dynamic range down to 8 (which is very effective for voice use). Have a read up on aLaw or uLaw encoding, it'd not be hard to do in software on the prop and save you an external chip!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

GaryT

Thanks Tim! That is a great explanation of how to use a protocol for this type of communication. A sample rate of 16Khz does sound pretty bad, using the Microphone-to-headphones spin example having a sample rate of 39Khz is getting better 78Khz sounds great! It seems like there is going to have to be some compression, have you used a PCM? It looks like that may be the way to go, any ideas?

Thanks,
Gary

GaryT

Thanks Brad, I'll read up on aLaw/uLaw, I'll have to get some PCM chips and try it out.
Thanks again for the direction, if I have any luck I'll let you know.
Gary

Tomvn

Hi GaryT, can you show me how to send sound over wireless , and with Prop do you use , thanks.