ADS1246 RDATAC consistent reading issue, spike every couple of minutes.

Dian,


First, can you let me know which each trace is for the scope shots? I'm guessing that yellow is /CS, and blue is SCLK, I assume that DOUT is either purple or blue. It would be nice to capture /DRDY as well (if you have to remove one of the lines, I'd say that DIN is the least useful).

Are you using /DRDY or DOUT/DRDY as an interrupt to read the data? This is important because new data comes out on DOUT for each read of the ADC. As an example you get the DRDY pulse, and then start the read. If you don't complete the read by the time the next ADC data is ready, the DOUT simply updates the data with new data. What you read as data is a combination of the first few bits of the first data and concludes with the first few bits of the new data. This of course would be wrong.

My guess would that you have an error where the read is delayed so you have this type of an error.

Regardless, can you take a long stream of data (with a couple of and put it in an excel file? I'd like the raw data from the ADC (not converted to voltage or other value). I'd be ok with the hex data output. Just make sure you mention what the input voltage is at the time (assuming the 2.5V reference).

Looking at the schematic, I don't see too much that's problematic. Generally I won't use any inductors near the ADC. Since there's a large amount of digital currents, even in the analog section, there might be voltage spikes from the Ldi/dt.

I would also use a lower noise reference than the REF3125. The REF5025 would be a good choice. Since the ADC measurement is a comparison between the input and the reference, the reference noise is a contributor of the noise you see in the ADC.


Joseph Wu

Dian,


One other thing that might be an issue is that it looks like there might be enough noise to cause some communication errors. Specifically if there's enough noise on SCLK, it advances the count on DOUT. Regardless, it's one more thing that might help.


Joseph Wu

Dian,

I've had a quick look through your results and you have some sort of bit-wise error in your readout. I suspect this an error in how you read out the device, but without more information about how you read the data and what your system is like, I can't be sure.

In the data file that you sent me, it looks like there are four columns of data. Columns 1-4 are labeled PDFilter, PDO, POI, and FFMain respectively. I've taken them an put them into an excel file.

For each data, I convert this data back into hex to see what it comes from and look at the original data. Using column 1, I get data that starts at 16075 and stays there with two excursions. In the first, the device is reading 16071 for a while and for two readings, it reads 16327. For the second, it reads 16070 for a while and then goes to 15558.

Let look at this from the hex data:

16075 -> 16327 = 3EC7h -> 3FC7h

16070 -> 15558 = 3EC6h -> 3CC6h

In both cases there is a single bit error. In the first, the 8th bit read a 1 when it should have been an 0, and in the second, the 7th bit read a 0 when it should have been a 1.

In the other columns you see similar single bit errors

Column 2

18185 -> 1803 = 4709h -> 070Bh

18199 -> 1814 = 4717h -> 0716h

Column 3

18522 -> 2138 = 485Ah -> 085Ah

18514 -> 16466 = 4852h -> 4052h

Column 4

17670 -> 16646 = 4506h -> 4106h

17665 -> 50433 = 4501h -> C501h

Each time it is a single bit error either changing a 1 to a 0 or a 0 to a 1. I don't know what can do this in terms of noise. I would imagine that if it were a noise issue, this has to be on the DOUT line. It can't be an SCLK issue or the remainder of the bits would be shifted.

More likely this is some sort of readout issue where you have some sort of intermittent error. I don't know what else could cause this. My recommendation would be to try to catch this problem in the act. I'd set the input to a known value that has and then see if you can catch this with a logic analyzer.

After that, I'd try to figure out if there's something in the code that could be flipping these bits. I really don't think this is the device that is in error. If it were the device, there would be more of a pattern (say the same bit is stuck at a 1 or 0 as an example). This has changes to high or low over any bit within DOUT.

Joseph Wu

Data_20151030_134943.xlsx

Dian,


One other thing to check is the duty cycle of your SCLK lines. I just noticed that the high time seems longer than the low time in the scope plots that you originally provided. It is possible that the SCLK duty cycle is greater than 75% (even in a very rare case)? This limit is outlined in the timing requirements on page 10 of the datasheet.

Again, I think using a logic analyzer would really help debug this problem. It might show the error with the timing information, depending on the analyzer that you use.


Joseph Wu