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.

ADS1256 data corruption problems

Other Parts Discussed in Thread: ADS1256

I'm trying to solve a problem on a board which uses four ADS1256's driven over a shared SPI link from a Freescale HCS12X CPU.

We read all 32 channels every 2mS, under control of a timer, then spool off the data to a PC.

We service the same channel on each chip, then step the multiplexers and read the following channel, till they're all done.

The 1256's are being run at 8MHz and the SPI link runs at 1.8432MHz.

The 1256's are running on 3.3V and have a 5V analogue supply and a 2.5V reference.

The CPU is all 5V on the external pins, so we have a level shifter for the read data line.

All 32 inputs have a low-pass filter set to 100Hz and a level-shifter stage to allow a +/-10V input range.

The 1256's are set up with the PGA gain = 2 and the buffer off to allow full-scale input voltages.

This is the second iteration of the design, which has been in production now for three years.

We've never been able to achieve the noise performance claimed for these devices and we've re-coded the firmware many times while trying to make things better.

We're currently using the code sequence given in the data sheet for fast multiplexing  apart from one small change - we use the first clock edge of the RDTA command to trigger the WAKEUP, rather than wasting time sending a NULL. This has had no effect on the problem - either good or bad...

Because of the combined time it takes to service all four chips sequentially on the SPI port, we lose a couple of conversions after the initial settling time, so the data should have settled really well by the time we read it.

The 32 results from each service loop are built into a packet and sent to a host PC for storage.

We use a programmable timer to space the bytes apart to follow the timing specifications.

No matter what we change, we can't get rid of errors in the middle byte of the data.

We also see a 'hangover' effect where a large signal in any channel appears at a lower level in the next one in the sequence on each chip.

Is this likely to be anything to do with not running the 1256's on 1.8V?

All comments appreciated.

Graham.

  • Hi Graham,

    Its unlikely that your problems are related to the lack of a 1.8V interface.  The issue may be reference and/or layout related.  Lets take this off line for the time being and get some additional detail exchanged.  From there, we can post 'lessons learned' which may be useful to other customers.