6
\$\begingroup\$

I'm looking for a way to send binary data over an audio channel on a video/audio transmitter. This will be an add-on feature to my product because it already has an audio interface. I'm hoping to be able to reach about 1 kbit/s data rate at a minimum, but higher would be nice. The requirements for any such protocol would be:

  • High noise immunity - so a signal with some noise and interference on it doesn't cause problems. Ideally, data would be either error free or flagged as having errors, as corrupt data could cause lots of problems. Weaker signals may introduce jitter and other nasties into the signal, so it should be capable of withstanding these.
  • Be able to work on a bandwidth limited (approx 8 kHz) audio channel. This includes slew rate limitations and variable jitter, including between clocks or bytes.
  • Be easy to implement, both transmitting and receiving, on a small microcontroller.

The protocol only needs to be one way as data will only be sent. The reason I ask this is because I've gone through lots of possible options (FSK, PSK, duty cycle modulation, Manchester, etc.) but have no idea which would be the best.

\$\endgroup\$
  • 4
    \$\begingroup\$ The things that immediately come to mind is do the same thing an old modem running at 300 baud (or some other slow speed). Some other thoughts include using the same type circuit / audio format as the old tape based storage retrieval systems (think CLOAD / CSAVE). \$\endgroup\$ – RQDQ Dec 10 '10 at 19:12
  • \$\begingroup\$ If your jitter is so bad that transmitting at a few hundred baud is going to be problematic, I'd hate to know what your audio is going to sound like. \$\endgroup\$ – Nick T Dec 10 '10 at 21:08
  • \$\begingroup\$ Ignoring the hardware side of noise immunity (blasphemy), high noise immunity means error correction. On top of hardware parity checks and DC-balancing, such as with Manchester, you can include checksums/CRC: goo.gl/RwDlt . Choosing one may need another topic! \$\endgroup\$ – tyblu Dec 10 '10 at 21:11
  • \$\begingroup\$ @Nick T, Think about a telephone line. It's pretty poor quality. It's about what the quality you get from cheap RC transmitters, but it's enough to hear that your propeller is working or to hear voice messages from your OSD system. \$\endgroup\$ – Thomas O Dec 10 '10 at 21:13
  • \$\begingroup\$ @tyblu, I was considering using Hamming(7,4) plus parity for error correction, on top of a CRC16 checksum for the entire message; the CRC16 can be generated in about 16 cycles on my processor using the onboard CRC generator. \$\endgroup\$ – Thomas O Dec 10 '10 at 21:15
8
\$\begingroup\$

I think RQDQ has the right idea. The best method of sending digital data over restricted bandwidth audio lines is a problem that has already been solved for modems.

The 300 bit/s modems used audio frequency-shift keying to send data. In this system the stream of 1s and 0s in computer data is translated into sounds which can be easily sent on the phone lines. In the Bell 103 system the originating modem sends 0s by playing a 1,070 Hz tone, and 1s at 1,270 Hz, with the answering modem putting its 0s on 2,025 Hz and 1s on 2,225 Hz. These frequencies were chosen carefully, they are in the range that suffer minimum distortion on the phone system, and also are not harmonics of each other.

In the 1,200 bit/s and faster systems, phase-shift keying was used. In this system the two tones for any one side of the connection are sent at the similar frequencies as in the 300 bit/s systems, but slightly out of phase. ...

\$\endgroup\$
4
\$\begingroup\$

With an 8KHz channel I would consider the very simple 1200 baud BELL 202 AFSK widely used for packet radio. Note that this is different than the 1200 baud PSK used on the very narrow bandwidth of voice telephone circuits.

You would then put a software-based verification scheme on top of this. That's going to be a bit trickier in a one-way link than in a two-way one where you can use acks and resend corrupted data. If you can just discard bad packets and wait for good ones, that's better.

\$\endgroup\$
  • \$\begingroup\$ I can discard bad packets or messages. They are monolithic containing a GPS position, voltages, currents etc. \$\endgroup\$ – Thomas O Dec 11 '10 at 0:47
  • \$\begingroup\$ Since this is simple data, could you use a variation on a Kalman filter to throw out bad data, either on top of or instead of some of the error detection? This would prevent corrupt packets from causing issues and would also cover hardware hiccups: goo.gl/MlK5q . \$\endgroup\$ – tyblu Dec 11 '10 at 2:34
  • \$\begingroup\$ Rejecting packets with a bad checksum is going to be less and faster math than a kalman filter, question is what you want to do with an outage - hold the last telemetry values and grey them out, or let it keep estimating based on heading and velocity and gradually gray it out, or? \$\endgroup\$ – Chris Stratton Dec 13 '10 at 6:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.