Elements ADC input low pass filtering
  • Hello pichenettes,

    I’ve been looking at some of the schematics for different modules (the Braids and Elements mostly) attempting to borrow from your designs for some of my own module designs. I’ve run into something I haven’t quite wrapped my head around fully that I will describe below. Please let me know if any of my supposed facts and guesses stated below are incorrect.

    From what I can tell looking at source code, the Elements samples CV inputs at 3.5kHz (looking at the CvAdc class). Looking at some frequency response results of a simulation of the CV input op amp stages that precede the ADC, it appears the input signals are low pass filtered but only somewhat gently (i.e., not doing a lot to avoid/reduce aliasing). In the case of the Elements’ FM CV input, the LPF’s cutoff appears is in the vicinity of 1 kHz, achieving very little attenuation by the point it reaches the sampling bandwidth implied by CvAdc.

    Given that, it seems like the Elements relies on these these CV input signals to be band-limited from the start (or at least effectively band-limited by operating below audio rates). I can see that being fine in practice most of the time such as for normal 1v/o CV and PWM, but in particular FM seems like a case where you might want things working at audio rates. Maybe that makes sense for a simple oscillator attempting to provide FM-style synth sounds, but not the more complex models of the Elements. Is that understanding correct? I’m really not sure, just guessing.

    If it is true Elements’ design makes assumptions about CV input signals bandwidth, why then LPF at all? Perhaps because Elements already needs the op amp for scaling and offsetting for the ADC, so may as well do a bit of LPF virtually for free w/ a simple feedback network?

    I appreciate any insights you can provide about these choices!

  • Your simulations / measurements are correct, but the CVs are sampled at 2kHz (they would run at 3.5kHz if the conversion was looping, but it is triggered).

    There is no attempt to band-limit a CV input in the analog domain – so it will alias at audio rate. I never intended the FM input on Elements (or any other module for that matter) for audio rate FM. The synthesis technique at work in Elements is not very suitable for that anyway. Audio rate modulation works much, much, much better with linear FM, and with oscillators capable of some through zero behaviour. Phase modulation is another technique that is good for an audio rate input. It doesn’t mean that the FM input on Elements is useless – vibrato, envelopes, pitch wobbling…

    There’s another thing to take into account. One nice thing with I2S devices like the one used in Elements is that the buffering / timing is managed by the MCU. In practice, you just prepare a buffer of 16 samples or so and they are piped to the device at the right rate. This approach makes for very efficient code, but you can only synchronize external events (such as ADC or trigger input readings) to the block rate, not to the sample rate. If I were to increase the CV rate of Elements, I would have to use smaller blocks, and compromise on synthesis quality to compensate (reducing the number of BPF in the resonator for example).

    If I ever did a module thought from the ground up for this kind of audio rate modulations, I would sample modulation CV inputs with audio ADCs – the ADC side of the codec whose DAC side would be used for audio output. These ADCs would do the band-limiting, and work in a perfectly synchronous manner with the DACs.

    Finally, what about this cap on the op-amp? Its main role is to eliminate HF noise.

  • > I would sample modulation CV inputs with audio ADCs

    Can you do this? I thought that these codecs had built-in HPF that prevented use at anything but audio-rate. And what about the ripples from the AAF?

  • The behaviour of the codecs at DC is “unspecified” – but some of them appear to handle it. That’s something I plan doing at the end of the year – do a bunch of boards with different codecs to review them.

    As for the ripples from the AAF, there’s not much we can do. These will be heard with control signals with hard edges (envelopes are never that hard, the attack often takes a few hundred µs). And will we really be able to hear the wobbling after the edge if it lasts only a couple ms?

  • Hmm it sounds to me like a risky idea to rely on an unspecified behavior… What if they make a revision? What if they differ from batch to batch? (no idea if this is plausible) I’ll test it with my CL board though, just for fun.

  • Thanks, pichenettes. It’s always helpful to hear directly from the designer. I of course did not intend to imply the FM lacked useful purposes without audio rate support :) Just trying to understand your intentions.

    With regard to the use of a codec, this issue of the DC stuff is of course to interest to me. Curious to hear what you learn, mqtthiqs.

    As for how this affects my design, I’m working on an oscillator and would very much like to support audio rate FM. I may still move ahead without investing in the cost of a better AAF. Given that audio rate FM tends to be best with minimally harmonic modulators and people who want “good” FM sounds know that. Perhaps I can regard the aliasing present in the degenerate cases as a feature :)

  • I’ve also wondering if the LP on the CV input OP-amps was related to the nyquist frequency or just a noise cancelling filter but never bothered to ask or do the calculations my self. But now I got the answer anyway.
    Is there any euro rack module (or other synth) out there that have >audio rate sampling of CV?

  • > out there that have >audio rate sampling of CV?

    The mungo stuff supposedly has, but I don’t know the details (external IC? a few external component and some resources from the FPGA implementing a simple SA or SD converter?).

  • Hi Pichenettes,

    Curious if you’ve had a chance to look into using CODECs for DC-coupled inputs yet (as mentioned earlier in this thread). I’m working with a circuit designer who has suggested the same approach. We’re discussing chips such as the AD1938/9 and PCM3168A (I call these ones ones out because I desire having ~4 channels of in and out) seem to explicitly offer the ability to disable the HPF (not necessarily on all ADC channels).

    That particular issue aside, I have also seen some commentary in places that suggest CODEC ADCs are optimized for audio in other ways but were vague about it other than to say they don’t perform as well as standalone ADCs can.

    Curious what your thoughts are and what you may have learned in the past few months.

  • It’s not just a matter of DC coupling. There’s also the matter of the response of the anti-aliasing filters, which can add too much ripple for data acquisition applications (while it’s perfectly fine for audio, since we don’t “hear” the waveshape). One thing to check is the impulse response of the anti-aliasing filter in the datasheet. Some parts have several types of acquisition filters and/or use different filters depending on the sample rate/clock rate.

    > what you may have learned in the past few months

    nothing related to eurorack modules :)

  • > nothing related to eurorack modules :)

    Now, that sounds interesting :-)

  • > Now, that sounds interesting :-)

    Not music gear either. Don’t expect anything.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion