• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 46 subscribers
  • Views 659 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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

Jennifer Holt
Prodigy 50 points
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

  • 0
    Prodigy 50 points

    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 
    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
00017, 00841, 001101001001
00018, 00883, 001101110011
00019, 00926, 001110011110
00020, 00969, 001111001001
00021, 01268, 010011110100
00022, 01055, 010000011111
00023, 01093, 010001000101
00024, 01126, 010001100110
00025, 01166, 010010001110
00026, 01201, 010010110001
00027, 01493, 010111010101
00028, 01280, 010100000000
00029, 01317, 010100100101
00030, 01354, 010101001010
00031, 01396, 010101110100
00032, 01432, 010110011000
00033, 01470, 010110111110
00034, 01768, 011011101000
00035, 01553, 011000010001
00036, 01595, 011000111011
00037, 01637, 011001100101
00038, 01679, 011010001111
00039, 01722, 011010111010
00040, 02018, 011111100010
00041, 01804, 011100001100
00042, 01844, 011100110100
00043, 01880, 011101011000
00044, 01922, 011110000010
00045, 01964, 011110101100
00046, 02003, 011111010011
00047, 02301, 100011111101
00048, 02088, 100000101000
00049, 02126, 100001001110
00050, 02165, 100001110101
00051, 02208, 100010100000
00052, 02250, 100011001010
00053, 02549, 100111110101
00054, 02335, 100100011111
00055, 02376, 100101001000
00056, 02418, 100101110010
00057, 02462, 100110011110
00058, 02503, 100111000111
00059, 02799, 101011101111
00060, 02579, 101000010011
00061, 02622, 101000111110
00062, 02663, 101001100111
00063, 02701, 101010001101
00064, 02744, 101010111000
00065, 03040, 101111100000
00066, 02822, 101100000110
00067, 02862, 101100101110
00068, 02901, 101101010101
00069, 02938, 101101111010
00070, 02980, 101110100100
00071, 03022, 101111001110
00072, 03317, 110011110101
00073, 03101, 110000011101
00074, 03142, 110001000110
00075, 03185, 110001110001
00076, 03220, 110010010100
00077, 03256, 110010111000
00078, 03552, 110111100000
00079, 03335, 110100000111
00080, 03375, 110100101111
00081, 03419, 110101011011
00082, 03457, 110110000001
00083, 03495, 110110100111
00084, 03537, 110111010001
00085, 03831, 111011110111
00086, 03612, 111000011100
00087, 03653, 111001000101
00088, 03693, 111001101101
00089, 03732, 111010010100
00090, 03771, 111010111011
00091, 04066, 111111100010
00092, 03850, 111100001010
00093, 03886, 111100101110
00094, 03922, 111101010010
00095, 03958, 111101110110
00096, 03982, 111110001110
00097, 03925, 111101010101
00098, 03894, 111100110110
00099, 03598, 111000001110

  • 0 in reply to Jennifer Holt
    TI__Mastermind 29220 points

    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.

  • 0 in reply to Richard Prentice
    Prodigy 50 points

    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:

  • 0 in reply to Jennifer Holt
    Prodigy 50 points

    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

  • 0 in reply to Jennifer Holt
    TI__Mastermind 29220 points

    Ah, great!  Thanks for letting me know.

    Regards,

    Richard P.