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.

ADS5500: Repetitive start/stop for interleaving

Part Number: ADS5500

Hi,

I'm using an ADS5500 ADC with an FPGA to capture a signal with high temporal resolution.

The idea is to wait for a trigger, and when it is detected start capturing the signal, with an 8ns sampling interval (at 125 MHz, the limit for the ADC).

Then, we wait for the trigger again, and when it arrives we wait 1ns and start the ADC clock, and capture another set of samples at the same 8ns, but offset by 1ns after the trigger.

Then we repeat, for a third acquisition offset 2ns from the trigger, and so on until we capture the last set of samples offset by 7ns from the trigger, starting the clock a specific time after the trigger, and stopping when the sample set is captured.

This is not very different from what we would do with 8 interleaved ADCs, running them with clocks offset from 0ns to 7ns, but given the repetitive nature of the signal we want to do this with only 1 ADC.

For this we have to wait for the trigger first, and then start the ADC clock with the correct offset (or have them running but insert the correct offset after the trigger is detected). We don't mind losing invalid samples in the ADC's pipeline, because the trigger is external and provided in real time, so the correct samples will eventually arrive after the ADC's pipeline is flushed.

The problem is that when we use only one ADC in this way the datasheet is not clear about how the ADC will behave. Specifically, can we expect that the captured samples will be correctly captured right after the ADC clocks are started (bearing in mind that they will appear in the data interface only later, of course)? If not, how many clocks will it take for the ADC to start capturing correctly? Does turning off the DLL help?

Thanks!

  • Rogerio,

    The one parameter in the data sheet that might cause you problems is the "Time to valid data after stopping and restarting the clock" which only has a maximum value, and it is 1000 clock cycles.

    Did you notice this? Will this be an issue with your setup?

    Regards,

    Jim

  • Hi,

    I hadn't noticed that, thank you for pointing it out. That is a definitive show stopper (the whole signal lasts only 100 clocks).

    The alternative I can think of is to keep the clocks running, and when the trigger is detected apply the delay to the clock without stopping it (by extending the low time or high time). Would this work with DLL turned on? And with the DLL turned off?

    I tried a quick search for "dll", but didn't find any explanation of how it works, or how long it might take to lock. It does include a lot of timing information for the DLL, but it doesn't say how long it takes to recover from any violation of the timings.

    Thanks again!