ADS1256

Hi Ignacio,

Could you elaborate on what you mean by wildly inconsistent? Do you mean that you are reading back random erratic values or that you continuously read back the result for a near ground input making you wonder if the internal mux is cycling? Depending on how your program is written to read back the data, it may be that you are reading back the data while the output register is being updated resulting in what would look like as an erratic reading. We recommend monitoring the /DRDY line to monitor when a new conversion is ready. When the line drops, the output register has been updated with a new conversion result and is ready to be read back. If you are not monitoring the /DRDY line and it happens to poll during a read back sequence (indicating an output register update), the result becomes invalid and it would read back as an erratic reading.

Now if the problem is that the converter just seems to read back the ground floor, I have to wonder if the mux is cycling at all. I would consider putting different voltages on the individual ADC inputs to check to see if the input mux is cycling at all. If it is, then it may just be that your calculated time delay is different than what the converter time delay is. Using the /DRDY pin as an interrupt would be the safest way to know when the mux has successfully cycled through the channels and a new conversion result is available.

Once you can verify if the mux is cycling we can dig deeper.

Regards,

Tony Calabria

Here is what came back from the customer in response to your questions:

We know the Mux is changing because it works correctly at higher sample rates.  The state machine monitors the DRDY line to wait for it to deassert before reading values.  The only question I have is – how many clock pulses should be sent for the SYNC, WAIT commands (which are 8-bit values).  I only send 8 clocks, since it’s an 8-bit command.  Do those need 32-clocks?  I don’t think so, since we read correctly at the higher sample rates, but I’d like to confirm that that’s not an issue.

Hi Ignacio,

You only need to send 8 bit transfer words to send the command. One thing to note is that there are SCLK speed restrictions based on the master clock frequency. I would take a look at the t1 timing spec in relation to your customer's timing to make sure that they are within the limits. In fact, a lot of the timing specs are going to vary with changing the master clock frequency so make sure you look at that. t11 may be a spec they are violating as well.

Regards,

Tony Calabria

Look at the attached picture.  This is the ADC’s selected input pin and notice how much noise is on it.  A voltmeter measures 8 mV average.  Ignore in the picture what looks to be a -50 mV offset as there is something wrong with my oscilloscope.  The noise repeats every 13.6 ms.  The unselected input pins measure less than 500 µV with a voltmeter and are a flat line using the oscilloscope.

There is an op-amp driving the pin with it amplifying 0 V on its input and an output impedance of 100 to 500 ohms (I give a range because each selected ADC input pin looks the same but the amplifier is a little different, but in all cases the input to the amplifier is 0 V).

The ADC is set for auto-cal off,  buffer off, clock out off, PGA = 2, data rate is 814 S/s (6.25 MHz clock).

Any idea what is causing so much noise?

P.S.  I have the buffer disabled because the op-amps could go to their rails of 4.5 V and -0.5 V and these violate the common-mode input range of the buffer.  The data sheet states that inputs outside of this range could affect the conversion accuracy of the other inputs that are in the range.

Also, 8 mV is what I read as the converted voltage.

I should also mention there is a capacitance of 100 nF to 1 µF on the ADC input signals.

I am just going to contact Ignacio directly to get to the root of this.

-Tony