Counteracting Sound Card AC Coupling for Reading Digital Data

Question

Disclaimer: I am new to EE. Everything I have learned so far I have taught myself from reading online and posting questions like this while working on this project. I apologize if I do a poor job of explaining my problem as I probably lack to the technical knowledge to do so properly.

I am attempting to read two flow meters through the mic port of a phone/tablet. The flow meters' pulse pins toggle between +0V and +5V as their pinwheels rotate.

I am using the following schematic to mix the signals from the two flow meters and send them through a mic port:

I mix the two pulse pins together using an R-2R. This allows me to watch for voltage changes and know which one of the two flow meters changed state based on the magnitude of the voltage change. For example, if I see a voltage change 2.5V, I know that flow meter 1 has turned on. If I see a voltage change of -1.25V, I know that flow meter 2 has turned off. I then use a voltage divider to drop the voltage within the sound card's voltage range.

The sound card is AC coupled and converts the voltage changes into an amplitude change with a formula something like amplitude change = (voltage change)/(voltage range). The AC coupling slowly pulls the amplitude back down to 0 as well. So if my PC sound card has a voltage range of 2V, and the flow meters cause a voltage change of -1.5V, I read through the mic port an amplitude change of -1.5V/2V = -0.75. My algorithm sees this amplitude change and, based on some thresholds, determines if it was caused by flow meter 1 or 2. This can be seen in these screenshots of my Java program running on my PC:

Raw signal read from PC mic port:
_{(source: awesomebox.net)}

Program highlighting detected flow meter state changes:

As you can see, the program is successfully identifying flow meter state changes; smaller amplitude changes are caused by flow meter 1 and larger amplitude changes are caused by flow meter 2.

---

The problems start when sending the same signal to my Galaxy Note 8 Android tablet. Here is what the signal looks like when read through the tablet's mic port:
_{(source: awesomebox.net)}

Note that all amplitude changes seen above are caused by the same voltage change (all state changes are from the same flow meter). Solo or infrequent voltage changes appear as very small amplitude changes while closely grouped voltage changes (of the same magnitude) appear as larger amplitude changes and closer to what I would expect. It seems the closer a voltage change is to other voltage changes, the larger the amplitude change it creates.

Here is what I read from my PC's mic port and what I expect. Notice that all the amplitude changes are about the same magnitude:
_{(source: awesomebox.net)}

Expected: A voltage change of 1.5V or -1.5V should always cause an amplitude change of 0.75 or -0.75.
Actual: A single voltage change of 1.5V or -1.5V causes an amplitude change of 0.1 or -0.1. A series of 10 voltage changes of 1.5V and -1.5V in short secession causes amplitude changes of 0.75 and -0.75.

This inconsistency makes it impossible for my algorithm to identify which flow meter an amplitude change was caused by. Why do these single voltage changes cause such small amplitude changes? Is there any way to make the amplitude changes always consistent with the voltage changes?

Also, instead of the signal slowly falling back to 0 like I would expect from AC coupling (and seen in the signal read through my PC's audio port), it seems to drop back towards 0 immediately and oscillates a few times before finally settling back to 0. The oscillation adds a lot of noise to the signal and makes it difficult to determine if an amplitude change was caused by a voltage change or is simply an oscillation from settling back to 0. Is there a way to eliminate these oscillations?

---

Sorry for the short novel and thanks for any advice,
- Mike

Answer 1

The easiest way to overcome the AC coupling is to convert your DC signals to AC. Seems logical, doesn't it?

One simple method is simply chop your input signal at some nominal frequency. Somewhere between 500 Hz to 1 KHz seems reasonable.

What you wind up is an AC signal (square wave) of whatever amplitude your original DC signal was.

There are several simple ways to do this.

1) The simplest method is to use a CMOS 555 timer such TLC555. I'm not at my computer right now but I'll enter in a schematic when I get home. But a verbal description follows:

Connect pins 2 & 6 together and to your timing capacitor. Timing resistor connects between pins 2/6 and pin 3. Pins 4&8 go to your power supply (5-15 Vdc). Pin 1 goes to ground.

Connect your input DC signal through a 4.7k resistor to 555 pin 7. This pin also feeds the analog input on your computer.

Pick the timing RC network for your desired frequency.

Done. . .

There are other chopper methods but this one is really simple and inexpensive.

[Edit]

Upon re-reading the original question and the subsequent comments and answers - I'm going change my answer slightly.

Because you are sending pulses (not DC levels) of varying amplitude to the smartphone / PC, I'm going to suggest that you want to treat the chopping signal as a carrier. You would therefore set that chopping frequency to be quite high - above 10 KHz but below 20 KHz. I don't know how sharp the anti-aliasing filters are in modern computer / smartphone analog inputs but I think that you want to be well clear of them. Maybe you can get the chop frequency up to 16 or 18 KHz - I honestly don't know.

Then simply do an envelope detection scheme in software to recover the original DC signal amplitudes.

Here is the schematic that I promised earlier. Note that this works well with a CMOS 555 timer - not one of the original bipolar parts. TLC555 is my standard 555 timer.

Pin 7 works for chopping the input signal because it is an open-drain output. We take our timing feedback from the output pin (Pin 3) - this works well because Pin 3 is a symmetrical CMOS output with Vout-HI level about equal to Vdd and Vout-LO level about equal to Vss.

Neither of these features is possible if using an original bipolar 555.

^{simulate this circuit – Schematic created using CircuitLab}

Answer 2

The quick answer is no. You're seeing two different effects.

The Android mic input is indeed AC coupled, but the cutoff frequency is a good deal higher than your sensor frequency. Since you don't provide any information about the time bases for the different traces, it's impossible to give you hard numbers as to what the frequency response of the Android input is like.

The PC also has a low frequency cutoff which is too high, but it's a bit closer to your sensor data than the Android. In addition, it has an input impedance of roughly 1 kilohm, which is loading your resistor network and causing the low amplitude.

There is no practical way to work around the effects of AC coupling (note that I said practical - you could build a preemphasis filter but I don't think you want to go there.) The PC input impedance can be compensated for by building a buffer amplifier with an op amp.

Answer 3

An excellent question, in presentation & content. And your analysis of how to get what you want from a single (mono) input channel is admirable.

I suspect the problem is that the filtering time-constant of the phone is shorter than that of the PC (ie. the phone's low-freq cut-off is higher than the PCs), and that's probably because AC-coupling caps for full spectrum 20-20kHz audio tend to be relatively large, larger than would probably comfortably fit in a phone. I'll bet money the phone will either have a lower sensitivity to low-freq (a spec you'll probably never see published for a phone), & they might be doing some low-end boost to try to compensate for this reality.

I think you'd be back on track to first process your sensor data into an AC-compatible modulation scheme, as Dwayne suggested.

Answer 4

If all that is done to the signal is a DC blocking filter (ie a high pass filter) you can in principle recover the original signal by integration. This method is susceptible to amplifying noise and can diverge easily if your constants are not carefully selected, but it's theoretically possible.

The good news is that you don't have to reconstruct the original signal. While the pulses may happen very infrequently, you are in principle only interested in the rising or falling edge, which is in itself a high frequency component, and is recorded just fine, even if the voltage falls back to zero.

The bad news is that it seems that other effects than a simple DC blocking filter are at play here. There may be AGC (automatic gain control) or attempts at noise cancellation present, especially in the Android signal, which could explain the slow ramping of the amplitude. One StackOverflow answer suggests that these things cannot be turned off, while a comment to that answer suggests that the VOICE_RECOGNITION constant is supposed to give you the raw audio stream, but it may not always do that. Perhaps there is analogue circuitry in the tablet that simply cannot be turned off.

You may want to rethink the modulation scheme entirely. Similar to Dwayne's answer, you might consider setting up a 555 or other circuit to produce a brief chirp, or pulse train, at every pulse, at varying frequencies for the two sensors. The pulses can then be detected by analyzing the signal in software using bandpass filters at the two selected frequencies. The detector then looks for a pulse at the specified frequency longer than a certain threshold, and counts that as a pulse from the respective sensor. This should be a very robust scheme, that isn't dependent on the absolute amplitudes of the signal.

The frequencies should ideally be chosen such that the upper frequency is not an overtone of the lower so it may produce false readings. A 555 timer will by default create pulse outputs, but the outputs could be individually low passed to remove some of their overtones if needed. DTMF for example uses frequencies spaced by a factor of 1.1.

The frequency and duration must additionally be chosen to be perhaps an order of magnitude higher, and shorter, respectively, than the fastest output from the sensor, to avoid that a new pulse train starts before, or too close to when the previous one was finished.

Alternatively, you could use a frequency modulation scheme, again similar to DTMF, where the sensor state modulates the frequency of an oscillator, which can be detected using a bandpass filter like suggested above. This has the added benefit of giving a carrier wave that is always on, which allows you to detect whether a sensor is connected at all.

If you're going for an edge triggered scheme, you could get away with only triggering a chirp on positive pulses, which should get you both a slightly simpler trigger circuit, and a more leniency in the frequency choice, since the pulses are now farther apart.