0
\$\begingroup\$

I have a system where I need to pieces of information from a single analog signal. The first is a time-average of the signal, over the course of around 0.25 seconds. The second is a detailed breakdown of the signal at approximately 135 kHz.

A little more detail: the input signal is correlated with a 1500 Hz square wave and broken down in to "in phase" and "out of phase", where everything in phase arrives when the square wave is high, and everything out of phase correlates to when the square wave is low. I've achieved this already with the 135 kHz sampling, and I can easily distinguish between in and out of phase. However, the averaging uses a lot of computing overhead and it's not strictly necessary to be sampling this fast all the time. I can't pause frequently enough to make the averaging efficient, and holding all that data in an array overwhelms my memory.

The reason I need the high-resolution measurement is because I need to know how well-correlated the signals actually are, since it's possible that my input signal could lag behind the reference wave slightly. This piece of information is actually critical to my setup, since it tells me important things about the stuff I'm measuring. Ideally, I'd construct a system where the slow measurement is essentially uninterrupted and the fast measurement happens a few times per second.

If I were to use two separate ADCs, I figure I could use one to do the "slow" measurements, use on-chip oversampling, and get a high-SNR signal that I can then casually average and report normally. Another ADC could do the high speed measurements and retrieve the phase separation between my signal and my 1500 Hz reference.

My question is about best practices. How do I make sure that when one ADC is measuring, it doesn't interfere with the other ADC? I've read a little about using buffer op-amps to isolate the signals, would that be the way to move forward? If I can reliably segregate the input into two ADCs, I can work out the details of the math later.

\$\endgroup\$
8
  • \$\begingroup\$ To know how much the ADCs will interfere, you need to know the output impedance of your sensor and the input impedance of both ADCs. \$\endgroup\$
    – Reinderien
    May 27, 2018 at 21:26
  • \$\begingroup\$ @Reinderien and then what? I'm a ChemE, not an EE. I have basic knowledge of what I'm working with, but not too much depth. \$\endgroup\$
    – Ben S.
    May 27, 2018 at 22:33
  • \$\begingroup\$ Ok, well can you provide a little more detail? Do you have a circuit diagram? Part numbers or specsheet links for your sensors or ADC? Once you know your input impedance you'll know whether a second ADC will present too much load. There are also noise considerations. \$\endgroup\$
    – Reinderien
    May 27, 2018 at 22:37
  • \$\begingroup\$ @Reinderien I can provide a diagram when I'm not on mobile, but the sensor in question is a Knowles EK-23028-000 microphone that I'm amplifying with an AD797 in an active bandpass configuration. The ADC I'm currently using for measurements is the AD7606-6, and the one I'm considering adding is the AD7366. \$\endgroup\$
    – Ben S.
    May 27, 2018 at 22:44
  • 1
    \$\begingroup\$ Let us continue this discussion in chat. \$\endgroup\$
    – Reinderien
    May 28, 2018 at 11:20

3 Answers 3

1
\$\begingroup\$

If you are really using two separate ADCs (rather than one ADC with an analog mux) then you should make sure that one ADC has finished its conversion before starting the conversion on the other ADC. Make sure that both ADC inputs are driven from a low impedance source, such as an op amp connected as a voltage follower. If you are really paranoid, use a separate voltage follower for each ADC. Use good bypass capacitors for both ADCs and follow any datasheet advice about routing the analog ground vs. the digital ground. You haven't given any indication of your resolution requirements so it's hard to be more specific.

But it's not clear to me why you need two ADCs for the application you've described. Why not just average the samples from the high-speed ADC to compute your low-frequency average?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Why not just average: because the OP claims that "However, the averaging uses a lot of computing overhead and it's not strictly necessary to be sampling this fast all the time" \$\endgroup\$
    – Reinderien
    May 28, 2018 at 8:34
  • 1
    \$\begingroup\$ @Reinderien Yes, I guess I missed that statement because it made no sense to me. There's no need to save all of the samples and the overhead is basically one addition per sample. \$\endgroup\$ May 29, 2018 at 12:03
0
\$\begingroup\$

Definitely use individual drivers for each ADC, and consider using individual references or at least individual reference buffers.

If it fits your resolution requirements you could consider using a single ADC and digitally decimate the signal with an FPGA, but I suspect the learning curve would be a bit much.

It depends a bit on your actual resolution- at 12 bits there is not likely to be a major problem, at 24 bits you can see everything.

Don't forget to provide appropriate anti-aliasing filters.

\$\endgroup\$
2
  • \$\begingroup\$ 135 kHz is pretty slow, maybe OP just needs a faster microcontroller \$\endgroup\$ May 28, 2018 at 0:13
  • \$\begingroup\$ @alex.forencich True. A Cortex M7 could probably do it. \$\endgroup\$ May 28, 2018 at 1:04
0
\$\begingroup\$

You're going to want to buffer both ADCs separately, and low pass filter each one to Fs/2 or lower (Nyquist) especially if your filters aren't very sharp otherwise you're going to get a lot of aliasing, especially on your slower ADC.

It might be a good idea to use a more powerful microcontroller instead, and perhaps look at an exponential moving average or other averaging technique with a significantly reduced memory footprint.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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