Let’s Compare SAR & Δ-Σ Converters for a Mux’d DAS, Part 3

In part 2 of this series, we looked at a few variations on the signal chain, starting at the sensor and ending at the ADC. We will continue with a closer look at the multiplexer.

Multiplexed applications challenges
Multiplexed DASs utilized in applications such as the analog input module of an industrial process controller, a digital X-ray detector, and tunable 40G/100G optical modules need high channel density. In these applications, the user wants to measure (sample) the signals from multiple sensors and multiplex (scan) many input channels into a single or several ADCs.

The overall benefit of multiplexing is fewer ADCs per channel are needed. Fewer ADCs means reduced board space, power draw, and cost, while offering the required performance. The simultaneous sampling ADCs are typically used in low channel density applications, such as power-line monitoring and multi-phase motor control. These require continuous sampling at higher throughput rate per channel to preserve the phase information between channels. Also, this produces precise, accurate instantaneous measurements.

In general, most of the applications in which these SAR ADCs are used are based on channel multiplexed architectures. These are ideally suited for systems that require fast response to step input near full scale (worst case) amplitude without any settling time issues. Note that the Δ-Σ ADCs convert at slow data rates, so multiplexing must be similarly slow. The speed limitation is due to the digital filter settling time. In turn, that limits its ability to settle fast, full-scale transitions of multiplexer channels.

The settling time also varies depending on the type of digital filter used. A user must wait the full settling time of the digital filter before a valid conversion result can be achieved. Then the channel can be switched. Some of the systems also rely on and benefit from having uniformity in the digitization process across multiple channels.

Low latency simplifies fast channel-switching (the essence of multiplexing) with the use of SAR ADCs. Despite the latency (also called group delay) of the digital filter associated with the Δ-Σ ADCs, the Δ-Σs are preferable in slow multiplexed applications (e.g., process control) mainly due to their high resolution, accuracy, low noise, and good dynamic range performance. SAR ADCs require low-pass filtering on each channel, which adds complexity in terms of space and cost.

The very high OSR (over-sampling ratio) of many industrial Δ-Σ ADCs allow a single RC filter to roll off unwanted signals before the clock frequency. The higher throughput rate of the ADC allows multiple channels to be multiplexed at fast scan rates for digitizing process and hence the less number of ADCs are required.

In the next part of this series, we'll look at variations in the multiplexer: Should it be a stand-alone device or should it be combined (integrated) with the ADC?

Related posts:

4 comments on “Let’s Compare SAR & Δ-Σ Converters for a Mux’d DAS, Part 3

  1. Vishal Prajapati
    December 16, 2013

    I like the simplicity of SAR ADCs. I am big fan of integrated ADCs with the microcontorller. I used to provide simple RC LPF in front of MCU ADC pin. In some cases I provide unity gain amp along with RC LPF to provide low impedence output.

  2. Victor Lorenzo
    December 16, 2013

    I am big fan of integrated ADCs with the microcontorller “. Me too. It's a feature that in many situations greatly simplifies the external hardware. But I was very disappointed a few years ago with one SoC (based on one ARM7TDMI@50MHz core) when using the internal ADC for measuring ambient temperature.

  3. Vishal Prajapati
    December 16, 2013

    Why? Was there any accuracy problem with internal ADC?

  4. Victor Lorenzo
    December 17, 2013

    Yes, it was randomly producing artifacts (spurius) and the digital filter used by the Δ-Σ ADC had a very long setting time (40+ samples), the ENOB was 9 bits (12 bits ADC) even in the demostration kit. The device was supposed to remain in low power mode 98% of the time and wake-up once every second to make some checks and take some temperature samples but we needed to implement strategies for detecting and correcting those errors. It seems it was caused by something related to internal power and clock control logic, probably correlated with the temperature variations the device was standing. The errors were detected when the device was already deployed and operating in field.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.