# Common methods of transmitting digital data through an extremely noisy audio signal?

I am developing software for transmitting data from a computer to a mobile device using audio. Specifically, from the computer's speaker to the device's microphone. (I am developing both the sender and the receiver software.) This is one channel, and the sample rate is a standard 44.1Khz. It needs to be VERY resilient to noise - it will be used in environments with street noise, people talking, background music, etc., which may be 10dB louder than the signal itself.

Knowing almost nothing about DSP, thus far I have apparently implemented frequency-division multiplexed on-off keying, without realizing it until now :) Basically each of 96 frequencies corresponds to a bit, and on the receiving end, if the frequency is present, the bit is on. I then use some custom error correction code to whittle those 96 bits down to 8 very reliable bits.

My system works very well and is very robust, but unfortunately has an EXTREMELY low data rate (~80 bits/sec). I have some ideas about how to improve bandwidth, like using more than 96 frequencies, and using the phase component to encode additional data. Also it appears I should look into frequency-shift keying and phase-shift keying.

So - my question is simply this:

What are the options for encoding data in a noisy broadcast audio signal, and what kind of bandwidth and error rates can be expected with each technique?

-
Does the signal need to be inaudible to the human ear? What are the transmitter limitations in terms of frequencies and power? What are the receiver limitations in terms of frequencies? How are you achieving reliable data transmission in the face of -10 dB SNR? –  Jim Clay Jan 16 '13 at 15:16
Great questions. We are actually using audible frequencies at the moment (4-16KHz), but would like to move to the inaudible (17-21Khz) - the receiver can only hear up to 21Khz. (This is partly why I am looking to increase bandwidth, to cram the same data into that 17-21Khz range that we had in the much wider 4-16Khz range.) As for power and frequency, the transmission needs to work whether sent with a laptop speaker or a PA system. –  Keith Jan 16 '13 at 15:35
As for the SNR - the receiver can still clearly hear these 96 frequencies (via FFT) even when music is playing 10dB louder than the signal itself. Seems like magic to me too, but it works :) –  Keith Jan 16 '13 at 15:39
Be careful if you move the data to the 17KHz and above range. The transducers available on many devices are not particularly reliable in that range. Just something to check out. –  user2718 Jan 16 '13 at 16:10
I don't have enough details to make this an outright answer, but you may want to look into amateur radio weak-signal transmission modes. For EME (earth-moon-earth or "moon-bounce") communications, you are looking at extremely weak signals even with huge antennas on both ends and kilowatt RF levels (the moon being used as a passive RF reflector). Modes used for meteor scatter communications might provide better bandwidth (in terms of data bits per second per Hz). –  Michael Kjörling Jan 16 '13 at 19:18

The scheme you are using is called On/Off Keying. It is not terribly efficient, but it is simple and gets the job done.

When you say that the signal is 10 dB below the noise floor I suspect what you mean is that if you add up all the signal energy and all of the noise from 0.3 - 14 kHz the signal is 10 dB weaker, but that the signal uses a much narrower frequency range, making the signal stronger at very specific frequencies. If it wasn't, you would not be getting reliable data transmission without doing long synchronous averaging, and it sounds like you aren't.

There are a number of different ways you could do this. The state of the art would be to use an OFDM signal in the 17-21 kHz band. A much simpler but not as efficient way to go (but still much more efficient than your OOK) would be to use a QPSK signal in the 17-21 kHz band. If you have enough transmission power you could modify it to 8-PSK or 16-QAM for higher throughput. Since it sounds like the transmission power is more of a limitation than the bandwidth (you can get a lot more data through 4 kHz of bandwidth than 80 bits/s), I would add a forward error correction (FEC) code to the data stream.

With QPSK you can get (ignoring the potential reduction in throughput from the error correction code) 1 bit/s/Hz, so you would have an upper limit of 4 kbits/s. With 8-PSK it would be 6 kbits/s, and with 16-QAM it is 8 kbits/s. The price of going with the higher data rates is that you are more likely to have errors.

The data rate for OFDM is more complicated. Given your level of DSP knowledge I would go with QPSK, and then modify from there if needed. It sounds like you would be thrilled with anything even close to 4 kbits/s, so that should be plenty good enough.

-
Great answer thanks so much! I think I'll give QPSK a try. One question though - it looks like PSK is applied to a wave at a single frequency - is this right? I presume you're suggesting I do an FFT to get the phase for a bunch of frequencies from 17-21Khz, right? AFAICT, spectral leakage is really limiting here: even with a 32768-bin FFT (a 750ms sample), I'd need to space the frequencies 10 bins, or ~13Hz, apart. This gives me ~300 frequencies in my 4Khz-wide band. 300 frequencies * 2 bits / 750ms = 800 bits/s. This sounds pretty god, but far from 4kbit/s you claim - so what am I missing? –  Keith Jan 16 '13 at 16:44
You would not use an FFT to demodulate a QPSK signal. The sort of approach that you're thinking of bears a greater resemblance to OFDM. PSK involves a single carrier frequency that is modulated in phase at some prescribed symbol rate. The resulting modulated signal takes on a $\sin{x}/x$ shape in the frequency domain, where the width of the main lobe is approximately twice the symbol rate. –  Jason R Jan 16 '13 at 17:14
One thing you'll want to investigate before taking this specific approach is to look at the frequency response of the hardware in your system. If you're using cheap speakers/microphones, they might not pass much content in the 17-21 kHz band, which is up near the top of the auditory range. –  Jason R Jan 16 '13 at 17:15
@Keith Jason is correct, modulation and demodulation of QPSK signals is generally done in the time domain- i.e. there usually aren't any FFT's involved other than using them to analyze the signal and make sure it looks right. He is also correct about the bandwidth being about twice the symbol rate. QPSK transmits two bits per symbol, so that is where the 1 bit/s/Hz comes from. –  Jim Clay Jan 16 '13 at 17:44
@Keith: I would recommend doing some investigation into basic signal theory. A phase-modulated sinusoid will have a nonzero bandwidth that is related to the modulation rate, so you aren't "wasting" any of the frequency band if you select the symbol rate appropriately. –  Jason R Jan 16 '13 at 18:07

It seems like you are already using a crude version of OFDM with no cyclic prefix, no coding (FEC), and lots of unused sub-carriers. What you are currently doing is also similar to amateur radio protocols such as MT-63. You could also look into spread spectrum modulation techniques (many) that were designed for very noisy channels with lots of interference.

-

It seems that your are trying to recreate work that has been done for voice band modems. A simple and very reliable, protocol which is used in fax transmission is ITU V.21 300 bps FSK. This modulation scheme is thoroughly documented. This type of modulation is used for control signaling in FAX transmissions because it is very robust.

If you need to go up to higher speeds, you are looking PSK which has been used for up to 9600bps on voice band channels. Beyond that, you are looking at a very complex scheme using QAM, but I don't think you need to go there.

-
While modems do seem relevant, I haven't looked into them much because they don't seem to need to deal with much noise - in the days of dial-up, when someone in the house picked up the phone, the internet connection would pause until they hung up. Are these modem protocols are doable in software, and do they deal with noise? If so I will definitely look into them. –  Keith Jan 16 '13 at 15:04
Modem protocols are mostly implemented in software. The most robust protocol in the presence of noise is likely the 300bps FSK. In general, modem protocols are designed to handle modest levels of white noise. So are you sending data and voice simultaneously? If so, how do you keep the data signaling out of the receiver? In the old days, we used frequency division multiplexing to do this. Voice was confined to the lower part of the channel and FSK was used in the upper part of the channel. –  user2718 Jan 16 '13 at 15:16
Thanks for your thoughtful answers Bruce. I've updated the first paragraph of the question to elaborate on the environment. We're not transmitting voice; rather, this signal needs to be able to be transmitted in the presence of heavy noise and background music, which may actually be coming out of the same speaker as the signal, but may not be. –  Keith Jan 16 '13 at 15:26
These modem protocols were not designed for noise levels higher than the signaling power. –  hotpaw2 Jan 16 '13 at 17:56
@hotpaw2 Understood. If the signaling is moved up to 17K-21K this may not be an issue, but I have concerns about the transducers operating reliably at these frequencies. The other options offered do look more promising. –  user2718 Jan 17 '13 at 0:43