This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADC12QJ1600: Feasibility of 128-ch differential analog input using MUX + GSPS ADC

Guru 14850 points

Part Number: ADC12QJ1600

Hi,

I’m considering an architecture to digitize 128 differential analog channels using an analog MUX front-end (time-division multiplexing) followed by a GSPS ADC, for example:

  • MUX: TMUX130x family (conceptually 8:1 per line; differential would require two matched paths or a 2-ch MUX device)

  • ADC: ADC12QJ1600 (~1.5 GSPS)

The goal is to reduce ADC count by switching channels and sampling sequentially.
However, I’m concerned about feasibility due to ADC input kickback, MUX Ron/Con, settling time, distortion, and channel-to-channel memory/crosstalk right after switching.

Could you please advise:

  1. Is MUX → ADC12QJ1600 a reasonable approach for multi-channel (e.g., 128-ch) differential inputs in practice?

  2. What are the key limits that typically break this approach (e.g., required settling time vs. per-channel bandwidth, SFDR/ENOB degradation, kickback interaction)?

  3. Do you recommend a specific differential MUX / RF switch / crosspoint solution for this kind of use case (TI parts or reference architectures)?

Thanks,

Conori

  • Hi Conori,

    I haven't seen anyone successfully do this, but it might be possible. 

    First you will need to string multiple muxes together in order to reach 128 channels, then deal with all the dynamic effects when they open and close, this will be a lot of loss, as typically you need to pad each mux stage in some fashion in order to reduce the dynamic switching.

    Most likely you would see AC performance degradation in SFDR and ENOB/SNR. Difficult to say by how much.

    TI does not have high enough BW muxes or switches to recommend. I would look at Minicircuit, Qorvo, Marki, Psemi for that.

    Regards,

    Rob

  • Hi Rob,

    Thank you for your feedback. I’d like to restate the customer’s intended architecture more clearly, since I think it may be slightly different from a “multi-stage cascaded MUX to reach 128ch” assumption.

    Customer requirement / intent (idea-level):

    • They have 128 differential analog channels to digitize.

    • They want to use time-division multiplexing (TDM) so that each channel can be treated as a lower-rate stream (roughly ~100 Mbps per channel equivalent), while using a GSPS-class ADC.

    • Key concern is MUX switching speed and settling time (including kickback interaction, memory effects, crosstalk) after each channel switch.

    Proposed conceptual architecture (not fully fixed yet):

    • Use 8:1 MUX × 16 = 128ch in total.

    • The intention is closer to “16 parallel lanes, each lane is 8ch → 1 stream via TDM” rather than building many MUX stages in series:

      • Each lane: one 8:1 differential MUX (or two matched single-ended paths) in front of an ADC input.

      • The overall system then handles 16 parallel digitizer paths.

    • They are exploring configurations like TMUX130x-family concept + ADC12QJ1600-class (~1.5 GSPS) (device selection is flexible at this point).

    Questions:

    1. With the above “16-parallel lanes / single MUX stage per lane” interpretation, does this become any more feasible in practice compared to a deeply cascaded MUX tree?

      • What are the dominant limiting factors (settling time budget vs. target ENOB/SFDR, kickback, input buffer requirement, etc.)?

    2. If it is still not practical, could you suggest TI-recommended alternative approaches to achieve “many channels at moderate per-channel bandwidth”?

    Best regards,

    Conor

  • HI Conor,

    Maybe to better fully understand what you would like to do here, would be to send over some slides, and/or block diagram so we can fully digest the system architecture.

    Yes, these would be the dominating factors when using a mux on the analog inputs: settling time budget vs. target ENOB/SFDR, kickback, input buffer requirement, etc. To what degree, I cannot say until the architecture is fully understood.

    Regards,

    Rob