Reading data from 3.5mm audio jack

[pokmo 0]

Hi all,

 

I wonder if it'd be a relatively straightforward exercise to read data from a 3.5mm audio jack using a MSP430 and a raspberry pi. The communication will be unidirectional: raspberry pi transmits data as audio output to MSP, so the MSP will do the reading. Does anyone know how this could be accomplished? Note that I'm trying to communicate over the audio jack and not serial.

 

Any thought appreciated.

[energia 485]

This could be possible but totally depends on the characteristics of the audio. Is this something like to modem technology or the audio data tapes that we used to load in our C64's cassette player? It all boils down to the frequency of the audio signal and what sample rate it would take to capture that data.

 

Can you post some more info about the specifics of the audio data signal? 

 

Out of curiosity, why audio data and not something like SPI/UART/parallel, etc.

 

Robert

[energia 485]

This did remind me of these days:

[pokmo 0]

This could be possible but totally depends on the characteristics of the audio. Is this something like to modem technology or the audio data tapes that we used to load in our C64's cassette player? It all boils down to the frequency of the audio signal and what sample rate it would take to capture that data.

 

Can you post some more info about the specifics of the audio data signal? 

 

Out of curiosity, why audio data and not something like SPI/UART/parallel, etc.

 

Robert

There's actually no specific preference over the audio characteristics. So long messages can be transmitted as audio output and be read on the MSP. I'm working with a raspberry pi right now, but ultimately I'll want to use it with an old laptop without working USB ports.

[abecedarian 330]

One thing to consider is which MSP430 and its available RAM for buffering and processing.

[pokmo 0]

One thing to consider is which MSP430 and its available RAM for buffering and processing.

 

 

I was reading http://www.ti.com/lit/an/slaa204/slaa204.pdf so I was thinking about using  MSP430F1121:

 

The MSP430 Soft-Modem application consists of two hardware boards. One board contains the MSP430F149 microcontroller. This device could be substituted by lower-end MSP430 family members such as the MSP430F1121. 

 

Do you think there'll be enough RAM?

 

This is the circuit provided - Is it right that TX and RX are audio signals?

 

Thanks

[abecedarian 330]

I was reading http://www.ti.com/lit/an/slaa204/slaa204.pdf so I was thinking about using  MSP430F1121:[/size]

 

 

Do you think there'll be enough RAM?[/size]

 

This is the circuit provided - Is it right that TX and RX are audio signals?

 

...> snipped image <...

Thanks

That circuit is an emulation of a V.21 modem and its RX and TX would connect to a telephone line and UART on a PC or similar.

 

The MSP430 has no intrinsic ability to "hear" audio. What it does have are analog to digital converters. So what you'd need to do is connect the output from the PI to an ADC on the MSP, sample the ADC and apply some filtering such as a Fast Fourier Transform, so you can convert the audio signal to a digital one based on the frequencies of the audio. That is essentially what a modem does, on the demodulation side, which is what you're trying to accomplish since you said "unidirectional".

 

You didn't mention what the MSP430 is going to do with the data, but if it's to offload data to a computer, that would need worked out separately.

[pokmo 0]

That circuit is an emulation of a V.21 modem and its RX and TX would connect to a telephone line and UART on a PC or similar.

 

The MSP430 has no intrinsic ability to "hear" audio. What it does have are analog to digital converters. So what you'd need to do is connect the output from the PI to an ADC on the MSP, sample the ADC and apply some filtering such as a Fast Fourier Transform, so you can convert the audio signal to a digital one based on the frequencies of the audio. That is essentially what a modem does, on the demodulation side, which is what you're trying to accomplish since you said "unidirectional".

 

You didn't mention what the MSP430 is going to do with the data, but if it's to offload data to a computer, that would need worked out separately.

 

 

I see. I'm just hoping to take (audio) commands from the PI and control a DC motor with a MSP430. So the data won't need to be transmitted. Does that mean the Soft Modem demo is irrelevant since it expects a phone line and UART on RX and TX, respectively? Sorry, I'm very new. I know I could use USB instead, but I wanted to control the MSP430 with javascript.

 

Rather than an ADC and FFT filtering, could I just use RC filters?

 

Thanks

[enl 227]

I see. I'm just hoping to take (audio) commands from the PI and control a DC motor with a MSP430. So the data won't need to be transmitted. Does that mean the Soft Modem demo is irrelevant since it expects a phone line and UART on RX and TX, respectively? Sorry, I'm very new. I know I could use USB instead, but I wanted to control the MSP430 with javascript.

 

Rather than an ADC and FFT filtering, could I just use RC filters?

 

Thanks

You haven't make clear what you mean by audio commands. Do you mean something like tones as used in touch tone telephones? Or are you just interested in getting useable information from the pi to the MSP430 via the audio output in any format at all? or are you just interested in getting data from one to the other and selected the audio output by default?

 

If the first or second, single tone detection isn't that hard. I would use capacitive isolation and protection diodes to limit the signal. Bias with a voltage divider to the middle of the power supply range, and then, using a digital input and timer, time the period. Different frequencies to differentiate commands/states.

 

If you aren't tied to the audio line, using straight digital lines would be preferable. You could use a standard serial, or use SPI, or I2C, or... Straight serial is likely easiest, as that is the least setup from the PI end, and easy to handle from the MSP430 end, since there are a minimum of protocol issues.

 

As you move to an old laptop, it will almost certainly have a serial port available (though it will need level conversion for interface with the MSP430). Audio may be unreliable, especially on older hardware, due to timing issues, etc. Many older devices (post soundblaster) didn't have any audio hardware to speak of. All software driven, like the modems. This led to some, um, interesting, issues during sound production, including poor timing, unpredictable skips from the buffer, and dropped intervals.  Serial was was hardware all the way, other than a few cases with 8-bit systems, since so little hardware is involved. By the mid-1980's (80286 era), it was generally included as an integrated part of the system chipset.

[pokmo 0]

You haven't make clear what you mean by audio commands. Do you mean something like tones as used in touch tone telephones? Or are you just interested in getting useable information from the pi to the MSP430 via the audio output in any format at all? or are you just interested in getting data from one to the other and selected the audio output by default?

 

 

Indeed, I'm trying to communicate commands from the PI to the MSP430 via the PI's audio output. The laptop I have isn't actually all that old and doesn't have serial ports. Plus, I'm hoping to generate the commands from javascript, so I think audio output might be easier.

 

Beside the voltage divider and diodes, would I need an opamp? I've seen some circuits with an opamp for "signal conditioning".

[enl 227]

Probably not, but the key thing are that a) the signal should center around Vcc/2 (1.5V in a 3V system), teh level should not go outside power supply bounds, and c) the swing should be more that 2/3 Vcc p-p. Additionally, fast transitions are nice, but may not be achievable with audio output device. Using a Schmidt trigger input (available for the timer inputs) makes this less critical.

 

The need for an op-amp would be due to insufficient level from the audio output. A line level output will be about 2.2Vp-p into 50Kohm, but headphone outputs may or may not meet this, and a line level output may drive much higher voltage open circuit. My design would be 5K in series with a 100nF cap (or larger), feeding the center of a voltage divider made with a pair of 100K resistors for biasing. If the input is Schmidt trigger, no issues with biasing to mid range. (For an input htat is NOT Schmidt trigger, do not do this, as the input may enter a state that leads to internal high current and damage.)

 

If the output level into 50K is much less than this (I would be surprised), then a gain stage (op-amp) would be needed.

 

This is not the greatest scheme in the world, but is pretty much what the most reliable cassette tape storage schemes in the late 1970s used. Again, I would tend to stay away from the audio hardware, but if you gotta, you gotta.

[roadrunner84 466]

Easiest way is to use an opamp (there are msp430 with built in comparator/opamp) and use/abuse the opamp as a filter. Then "encode" serial commands (you have to go serial at some point!) by transmitting high bits as one frequency and low bits as another frequency (or no signal at all).

Then you can use the output from the filter to acquire an analog voltage that is close to the desired levels.

Essentially you're using discrete amplitude modulation (AM) with a modulation depth of 100%, this is the same as OOK (on-off keying).

Note that such a system will have a low bandwidth, don't expect any rate in the order of kilobits.

Also, you can see that this is roughly what the softmodem solution is doing; taking a signal, filtering it and shoving it down the msp's throat.

[pokmo 0]

How about a circuit like this?

 

 

I found it here: https://github.com/arms22/SoftModem

[enl 227]

How about a circuit like this?

That is what I was describing. The upper section is your minimum (FSKIN side). This is, again, presuming that the MSP430 will do timing of state changes to get frequency. This is presented essentially as an analog connection, but, with a Schmidt trigger input pin, you get zero crossing detection.

[roadrunner84 466]

I was talking about OOK (on-off keying), while your latest schematic is talking about FSK (frequency shift keying).

 

The difference is that FSK will send one frequency for high bits and another for low bits, while OOK will send one frequency for high bits and no frequency (DC, 0Hz) for low bits (or the other way around).

 

So FSK has the added value of distinguishing high/low bits from an idle line. In the case of UART serial, you don't need this detection per se, because a high bit and an idle line are not distinguishable anyway.

 

Then again, if you have the software to do FSK, just use it. If you make things from scratch, OOK might prove simpler to implement.