• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 742 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADC16DV160: DATA capture issue

SARIKA SHRIVASTAVA
Intellectual 570 points
Part Number: ADC16DV160

Hi

I am using ADC16DV160 in my mixed signal card. The captured ADC data is not clean and has several spikes along with the signal. The spikes are visible even when no IF is fed.

Fig 1 : ADC capture with 36MHz output

Fig2: ADC capture without signal

Why are so many spikes coming at the captured data. Noise level also seems high. What can be done to overcome these issues?

  • 0
    TI__Mastermind 44680 points

    Hi Sarika

    In this device the output data interface allows the Even bits to be captured on the rising edge of the DDR OUTCLK, and the Odd bits on the falling edge. It might be possible that you are processing these in the opposite fashion, which would lead to the results you are seeing. Please try swapping the odd/even bits to see if that helps.

    If that doesn't help, can you send time domain data files (.txt or .csv) with at least 64k samples for the 2 cases shown above?

    Can you also provide the schematics showing the input signal path, ADC and clocking circuitry?

    Thanks,

    Jim B

  • 0 in reply to Jim Brinkhurst1
    Intellectual 570 points
    Hello Jim

    Thank you for the reply. We were sending even bits on the rising edge and odd bits on the falling edge and reading in the same manner. But the problem is solved once we read the even bits on falling edge and odd bits on the rising edge. Looks like delay was the problem??
  • 0 in reply to SARIKA SHRIVASTAVA
    TI__Mastermind 44680 points

    Hi Sarika

    I'm glad you were able to get good data by changing the capture edge.

    I expect the problem is due to a difference in delay for the DATA versus the OUTCLK in the capture device. It could also be due to an inversion of the signal somewhere in the path.

    Best regards,

    Jim B