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.

ADS5403: Offset issue on odd / even samples

Part Number: ADS5403

We have implemented an FPGA/ ADC design using the 5403. We see an offset occurring on each odd / even sample , the offset is of the magnitude (but not exactly) of 16 to 22 counts. We are able to change the timing of the delays for each output line in the FPGA and we have proven that his works.  However, the only difference when we are changing tap values is that the offset moves from even to odd samples - but is still present.  We have shown that all lines function and are not 'stuck' in one state or another, so there are no shorts on the board. 

Has anyone else come across a similar issue?

Thanks in advance.

  • Hi Richard,

    For the output digital format. Are you using 2's compliment? or Offset binary? If you are able to change the format from one to the other, please give that a try and let us know if you see the same issue.

    Also, if you have a schematic that you can provide, that might help give us some clues as well.

    Regards,

    Rob

  • Dear Rob, thank you very much for responding, most appreciated. 

     We are reading the data in raw format and transferring it into a FIFO on a Zynq MicroZed, the data is not manipulated in the FPGA.   This is a pulsed application so the resulting 100 data bytes are read out in one block read from the FIFO as a 32 bit read of two 16 bit sign-extended, 12 bit data bytes .

    So an ADC sample of (h)AAA and (d) -1  would be read as 0AAAFFFF

    The  Upper 16 bits are "even" and the  lower 16 bits bits are "odd" samples. We have injected test  data and confirmed that we are reading the high and low bytes correctly. It is only when we read the ADC data that we see the issue. 

    My guess ( and that's about all it is) is that the oscillator ( discussed in another thread)  is causing a bias change to VCOM on a positive edge - perhaps due to power supply perturbation? 

    All help appreciated

    Richard

  • Dear Rob,

     I think that I found the source of the problem - page 23 of  your datasheet. The interleaving correction is turned off by default. We are not enabling this function over SPI.  Please advise if you think that this is reasonable. 

  • Hi Richard,

    Yes, I believe that could be the source of the error, the interleaving spur will be unusually high if the correction is not turned on. This maybe what you are seeing in code form. If you can generate and output FFT, it would be easier for us to verify.

    Regards,

    Rob