ADCs and DACs for audio instrumentation applications

I would like to see how a 20-bit SAR performs with a jitter test signal. Perhaps that is a problem where you can see the "missing bits". Here an example measured with the RTX6001:

Stay tuned, I am working on interfacing a 20bit SAR with my UPD Rohde analyzer, planning to follow this: http://www.ti.com/lit/an/slwa036/slwa036.pdf

Not expecting anything special (the SNR is already what I would expect from a practical 20 bit ADC) and, besides, there's not much to do about, since all these ADCs have an internal clock/PLL for conversion. The external clock is only for shifting out the data over the SDO.
 
Member
Joined 2009
Paid Member
Stay tuned, I am working on interfacing a 20bit SAR with my UPD Rohde analyzer, planning to follow this: http://www.ti.com/lit/an/slwa036/slwa036.pdf

Not expecting anything special (the SNR is already what I would expect from a practical 20 bit ADC) and, besides, there's not much to do about, since all these ADCs have an internal clock/PLL for conversion. The external clock is only for shifting out the data over the SDO.

Actually, all those SAR ADC's have a Sample / CNV clock pin, that the one used for the sample and hold, and that need to be low jitter. Their high speed internal clock is for doing the the actual SAR conversion and can be jittery, it's the sampling clock that matter....
 
Actually, all those SAR ADC's have a Sample / CNV clock pin, that the one used for the sample and hold, and that need to be low jitter. Their high speed internal clock is for doing the the actual SAR conversion and can be jittery, it's the sampling clock that matter....

I don't think the CNV (conversion start) is much of a problem, CNV defines the sampling frequency only (timing between two CNV rising edges), the pulse width is essentially irrelevant (its only a minimum), within limits. A 24.576MHz Crystek with a -170dBc/Hz phase noise (flat) like I'm using, divided by 64 to 392KHz, you do the math of the jitter you can get https://www.analog.com/media/en/training-seminars/tutorials/MT-008.pdf if my calculator is right, thats about 2.2 femtoseconds (of course, there's more than the oscillator, but...). These SAR converters do NOT take a MCLK signal like the usual audio contenders, they only take

BCLK for data transfer
LRCK (from which the CNV is derived)
LDO (serial data out)

For multi channel, conversion is done in parallel (sharing the same CNV, derived from the LRCK edge) and then the data in shifted out on the LDO and shifted in on the LDI during the same MCLK rising/falling edge, so that 48 MCLKs later, the L/R data is out, accompanied with the LRCK high/low. Generating the CNV and syncing the LRCK with the LDO is all that the external logic has to do. Fortunately, these SARs are all allowing left justified data, so missing 4 BCLKs (all 0, LSB) for each conversion is not an issue for compatibility.

Ok, I spilled it out :D.
 
Last edited:
soekris:
> Actually, all those SAR ADC's have a Sample / CNV clock pin, that
> the one used for the sample and hold, and that need to be low jitter.
> Their high speed internal clock is for doing the the actual SAR conversion
> and can be jittery, it's the sampling clock that matter....


That describes perfectly how my LTC2500-32 ADC works. Sample clock at 1 MHz,
2/3 of the period for the conversion. The last 1/3 of the period is exactly long enough
to get the 32 Bit result at the 100 MHz fastest allowed SPI rate. The SPI clock is off
during conversion.
I don't know if they have a real clock for the conversion. It might be just a tapped
delay line fed from the conversion rate.

< https://www.analog.com/media/en/technical-documentation/data-sheets/250032fb.pdf >

Gerhard
 
Last edited:
That describes perfectly how my LTC2500-32 ADC works. Sample clock at 1 MHz,
2/3 of the period for the conversion. The last 1/3 of the period is exactly long enough
to get the 32 Bit result at the 100 MHz fastest allowed SPI rate. The SPI clock is off
during conversion.

Those LTC SAR converters have the (internally set) rule of thumb: conversion rate is SPI clock rate/80 (and work fine pushed up to 120MHz). Not all are built this way, the ADS8900B from TI is different, they allow another degree of freedom in selecting the SPI clock without tying it directly to the internal conversion rate.
 
Last edited:
I don't think the CNV (conversion start) is much of a problem, CNV defines the sampling frequency only (timing between two CNV rising edges), the pulse width is essentially irrelevant (its only a minimum), within limits. A 24.576MHz Crystek with a -170dBc/Hz phase noise (flat) like I'm using, divided by 64 to 392KHz, you do the math of the jitter you can get https://www.analog.com/media/en/training-seminars/tutorials/MT-008.pdf if my calculator is right, thats about 2.2 femtoseconds (of course, there's more than the oscillator, but...). These SAR converters do NOT take a MCLK signal like the usual audio contenders, they only take

BCLK for SPI data transfer
LRCK (from which the CNV is derived)
SDO (serial data out)

For multi channel, conversion is done in parallel (sharing the same CNV, derived from the LRCK edge) and then the data in shifted out on the SDO and shifted in on the SDI during the same BCLK rising/falling edge, so that 48 BCLKs later, the L/R data is out, accompanied with the BCLK high/low. Generating the CNV and syncing the LRCK with the SDO is all that the external logic has to do. Fortunately, these SARs are all allowing left justified data, so missing 4 BCLKs (all 0, LSB) for each conversion is not an issue for compatibility.

Messed up the notations, corrected above
 
Last edited:
Those LTC SAR converters have the (internally set) rule of thumb: conversion rate is SPI clock rate/80 (and work fine pushed up to 120MHz). Not all are built this way, the ADS8900B from TI is different, they allow another degree of freedom in selecting the SPI clock without tying it directly to the internal conversion rate.

I haven't used the slower versions, but LTC2387-18 does require a low jitter CONV clock according to the datasheet. They use some kind of Crystek on the EVB, similar to what people are using for audio, but higher frequency and divide it down to get 15 MHz.

This part outputs LVDS, not SPI though, so it's more difficult to interface. It takes in an LVDS clock to clock out the output data and also provides a version of it aligned with the data output. It's more similar to the pipeline ADCs in that regard.
 
I haven't used the slower versions, but LTC2387-18 does require a low jitter CONV clock according to the datasheet. They use some kind of Crystek on the EVB, similar to what people are using for audio, but higher frequency and divide it down to get 15 MHz.

This part outputs LVDS, not SPI though, so it's more difficult to interface. It takes in an LVDS clock to clock out the output data and also provides a version of it aligned with the data output. It's more similar to the pipeline ADCs in that regard.

15MHz is up there, 80x higher than the conversion rate in audio (192KHz). What I'm trying to say is that the CNV "clock" (you can view it this way) needs indeed to be low jitter, but for 20bit @192KHz that's a non issue even if using a simple quartz oscillator (not necessary crazy low phase noise like the Crystek, -97dBc @1Hz. A 15MHz Crystek in the same series would have a jitter of about 0.3pS, that's two orders of magnitude higher compared to the audio example above.
 
Last edited:
Those LTC SAR converters have the (internally set) rule of thumb: conversion rate is SPI clock rate/80 (and work fine pushed up to 120MHz). Not all are built this way, the ADS8900B from TI is different, they allow another degree of freedom in selecting the SPI clock without tying it directly to the internal conversion rate.

In the LT2500, encode and SPI clock are completely independent.
That can't be proved better than by the fact that during conversion there is no SPI clock at all. And all digital I/O during conversion is avoided. Produces only unwanted noise.

SPI clock is started only when /conversion_busy goes away, for exactly the 32 clocks needed.
 

Attachments

  • Bildschirmfoto vom 2020-01-09 03-54-51.png
    Bildschirmfoto vom 2020-01-09 03-54-51.png
    117.5 KB · Views: 780
Last edited:
In the LT2500, encode and SPI clock are completely independent.
That can't be proved better than by the fact that during conversion there is no SPI clock at all. And all digital I/O during conversion is avoided. Produces only unwanted noise.

SPI clock is started only when /conversion_busy goes away, for exactly the 32 clocks needed.

Interesting, I suppose you provide the max. 100MHz clock to your board (80MHz nominal, which is also the SPI clock, leading to a fixed 1Mbps conversion rate). How do you control the LTC2378 conversion rate given this fixed clock? Not sure if what you call the LT2500 are working the same way.

Edit: I quickly checked and the LTC2500-32 is different. It takes a MCLK (a rising edge on this input powers up the part and initiates a new conversion) and a separate SCKA/B (Serial Data Clock Input A/B). So comparing to the LTC2378-20 SAR is not apple to apple, it's a different digital interface architecture. The SNR of the LTC2500-32 is only 104dB, pretty lame for a 32 bit ADC (only marginally better, and the distortions are even slightly worse, compared to the 20bit LTC2378-20). Costs about the same as the LTC2378-20, strange.
 
Last edited:
The picture of the board is ~3 pages back. I have a 100 MHz crystal osc that goes into the Coolrunner2-CPLD. That divides down to 1 MHz for the sample clock and it also gates
the 100 MHz with a state machine in VHDL for use as a SPI clock.

This is not a LTC2378. The LTC2500-32 can filter and decimate itself for lower effective
sample rates and provides the original 1MSPS data on a different data pin if one thinks one
could do that better. With lower effective sample rates comes higher resolution.

The Coolrunner also reads the SPI data and hands it over to the Beaglebone as 4 Bytes,
which is easier to handle for its PRU coprocessor. I could not make the Beaglebones
SPI interface make work under Linux, it is limited to 48 MBit/sec anyway.
 
Last edited:
Interesting, I suppose you provide the max. 100MHz clock to your board (80MHz nominal, which is also the SPI clock, leading to a fixed 1Mbps conversion rate). How do you control the LTC2378 conversion rate given this fixed clock? Not sure if what you call the LT2500 are working the same way.

So comparing to the LTC2378-20 SAR is not apple to apple, it's a different digital interface architecture. The SNR of the LTC2500-32 is only 104dB, pretty lame for a 32 bit ADC (only marginally better, and the distortions are even slightly worse, compared to the 20bit LTC2378-20). Costs about the same as the LTC2378-20, strange.

The guaranteed values are identical. The "only" -104 db SNR are also -104 dB for the
2378-20, the guaranteed distortion is -114 dB for both.

Only the "maybe if you are lucky" typical values for distortion are slightly better with the
2378, and it could have a reason that they stepped down with the non-guaranteed values
slightly.

So all there stays is that the guaranteed values are identical, and the LTC2500-32 has
added digital filters and downsampling for increased dynamic range at sample rates < 1 MSPS.
That could be done with the 2378 also externally, but it must be done.
 
Last edited:
Hi Popa,
Your project sounds very interesting.

How do you find the UPD to use? I'm curious as some people have them and all my experience is with HP / Agilent and Keysight, plus the RTX 6001 I'm using now.

Let’s settle for Ovidiu :D. The UPD is in the same class and performance as the AP SYS-2322 Dual Domain, with all the possible options. The big plus is you don’t need a PC and crap software, everything including the LCD screen to do screenshots from and save them on the internal hard drive.

It was a lucky shot on EBay few years ago, paid for it less than the RTX6001, replaced the dying hard drive with a PCI interface and flash memory card, begged at the R&S local representative for the latest operating software, and likely this german Panzer will survive me (it doesn’t even need periodic calibration!). Clocks at -130dB THD and -115dB THD+N @1KHz and about 6-10dB worse @20KHz. The only thing I dearly miss is one K1 software option that would enable measuring speakers. Unfortunately it is not free, so I could not get if from R&S (you do not want to know the price they asked).
 
Last edited:
Administrator
Joined 2004
Paid Member
Hi Ovidiu,
Oops! Sorry for getting your name swapped.

I'm glad you were lucky and got it, then was able to fix it up. Good going!

The price everyone charges for added (unlocked) software components is all around extremely high. So how do you find it as far as logical button and menu organization? I've never had one to play with to find out.

Your project is more than a passing interest for me.

-Chris
 
Hi Ovidiu,
Oops! Sorry for getting your name swapped.

I'm glad you were lucky and got it, then was able to fix it up. Good going!

The price everyone charges for added (unlocked) software components is all around extremely high. So how do you find it as far as logical button and menu organization? I've never had one to play with to find out.

Your project is more than a passing interest for me.

The user interface is logical and can be controlled from the front panel or a standard keyboard, I use the mostly the keyboard. There are a few annoyances (the analyzer has three modes, 22KHz, 100KHz, 768KHz, switching requires reconfiguring everything else, I could use a finer FFT, it is limited to 8K due to memory constraints, the I2S interface is implemented in poor 15 pin serial connectors and is 5V logic only, etc...) but they are all a small price to pay for an otherwise amazing instrument.

I’m afraid there’s no project yet, only some exploratory work driven by curiosity, since I never had the opportunity to delve in the SAR ADCs.
 
Administrator
Joined 2004
Paid Member
Hi Ovidiu,
Sounds a little funky, but certainly not difficult to use. I was ignoring them because they looked so different from what I am used to. I should try one out at some point in time.

No project. Hmm, if you actually do something with this, would you be wiling to start a thread? It would be a good learning opportunity for me and probably most other people.

Take care, Chris
 
No project. Hmm, if you actually do something with this, would you be wiling to start a thread? It would be a good learning opportunity for me and probably most other people.

Will do, if it gets there. Exploratory for the time being, that's always how I begin a project (if it gets there). I am now looking for a serial programmable wide range frequency divider (minimum by 512, no PLL) with low additive phase noise. Surprisingly hard to find, the LTC6594 would be ideal, unfortunately is only up to divide by 63. Very nice part, also allows programming a delay between outputs, but...
 
Hi Ovidiu,
Well, maybe you can put a divide by 1 to 3 which might give you the range, unless you need to hit every frequency. Then you would pretty much need to use two of those chips in series. Logic is getting complicated now.

Cascading two chips is not a good solution, it makes the whole final result strongly layout dependent. The easy way is to use hardware programmable HCMOS divider like the 74HC292 and patch a SPI interface to the inputs, but this is a low tech solution that looks ugly to me, plus that the additive phase noise is unknown/not guaranteed.