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.
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.
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
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