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.

ads5242 glitch at 0

Other Parts Discussed in Thread: ADS5242, THS4522

I am having a strange issue with an ads5242. When my input signal goes through 0 (code 2048 on the ADC output) there is a glitch of a single sample with a value 100 or so counts higher or lower than it should be. The glitch only happens when the signal goes through 0, and the glitch is correlated with the slope of the signal. If the signal has positive slope at 0, the glitch is positive, and if the signal has negative slope the glitch is negative. If I bias my signal so the entire swing is either above or below 0, the glitch does not occur.

I am using an ads5242  with the input driven by a dc-coupled ths4522. The ths4522 is set up for single-ended to differential conversion with a gain of 2V/V using the components values from Table 1 in the ths4522 datasheet, and the circuit in figure 53 of the ths4522 datasheet. The series resistors between the ths4522 and the ads5242 are 100ohm. The VCM output of the ads5242 is connected to the VOCM input of the ths4522 and decoupled with a .22uf cap.

I have checked my digital transmission using the test patterns of the ads5242 and I don't see any bit errors. Has anyone else experienced this or have any idea what could be going on?

Thanks,

Jenn Holt

  • An update on the glitch problem. It turns out that the glitch happens whenever the ADC transitions between codes with a 1 followed by many 0s and codes with mostly 1s (example 2048 -> 2047 or 2047 ->2048) however, the problem codes transmit fine if used as a custom test pattern. I have attached a picture of a linear ramp which covers roughly the whole range of the ADC. the glitches are easy to pick out. I'll keep investigating.

    Jenn

    7651.ramp_test.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Single Trace BINARY dump
    i | dec | CBA987654321
    00000, 00000, 000000000000
    00001, 00208, 000011010000
    00002, 00507, 000111111011
    00003, 00294, 000100100110
    00004, 00336, 000101010000
    00005, 00378, 000101111010
    00006, 00418, 000110100010
    00007, 00450, 000111000010
    00008, 00742, 001011100110
    00009, 00523, 001000001011
    00010, 00556, 001000101100
    00011, 00598, 001001010110
    00012, 00637, 001001111101
    00013, 00674, 001010100010
    00014, 00715, 001011001011
    00015, 01015, 001111110111
    00016, 00798, 001100011110
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi,

    i have not seen such a thing before, so i will pass this information on to the design team to see if they have any insight into this.  But looking at your data, it looks like the when you get the errors it is always a matter of getting a code that is 256 larger than would be expected in that spot.  And not just getting  a '1' in the 9th bit position where there would have been a '0', but sometimes where there is a '1' in that position getting a '1' added to that position which ripples uo into higher bits.  hmm. i don't see what that would be.

    What are you using to catch the sampel data from the ADC and deserialize it?

    Regards,

    Richard P.

  • Richard,


    Thanks for taking a look at this. I have tried most everything I can think of.  The errors are also linked to the slope of the voltage when the error occurs. In the ramp I posted the slope is always positive, however for a downward ramp the errors go the opposite way. I'll post another picture, but unfortunately I don't have the raw data for it right now.

    For catching the data I am using a Digilent Atlys board

    https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS

    it has a Xilinx spartan 6 LX45. I am using a PLL on the xilinx to double the Lclk clock from the ADC to generate my IO clock, then using the SERDES features to do a 1:6 deserialization, followed by a 1:2 gearbox in fabric to reconstruct the 12-bit words. The ADclk signal is treated as a 5th data input, and the framing logic looks at this to adjust the phase of the bits until the data received on the ADclk channel is 12'b000000111111.

    I have not had any trouble with test patterns, they always transmit fine, including custom test patterns of the problem areas. Also if one of the problem codes occurs more than twice, the later ones transmit fine. Here is a snippit of data where I suspect the correct values are 2048,2047,2047,2048,2048

    i            Dec       Bin

    00022, 02048, 100000000000
    00023, 01792, 011100000000
    00024, 02047, 011111111111
    00025, 02303, 100011111111
    00026, 02048, 100000000000

    It is possible that the test patterns exhibit the problem when the output first switches value, however my current code doesn't allow catching this area since the acquisition and the serial port write require different USB transactions and the switchover has passed by the time I get any data.

    Thanks,

    Jenn Holt

    Pic showing slope dependence of errors:

  • So I have found my problem. My deserialization was fine, but the fifo I packed the data into got out of sync by one byte. I put the 12-bit sample into 2 bytes and use a 16-bit in 8-bit out fifo to buffer the data before it is sent to the PC. If I get a byte stream of A,B,C,D,E,F,G,H I was interpreting it as:

    BA, DC, FE, HG

    when I should have interpreted it as:

    XA, BC, DE, FG, HX

    My wrong interpretation and the correct one give the same results for a stream of identical numbers, but not when the numbers are changing. I have attached a spreadsheet which has the original ramp data, and corrects it by rearranging the bytes. If anyone else sees this kind of error, this would be the first place I would look :)


    Jenn Holt7444.ramp_test.xlsx

  • Ah, great!  Thanks for letting me know.

    Regards,

    Richard P.