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: not correct read data

Part Number: ADS1256

Hi,I am recently using ADS1256 to convert data,and I encounter some data incorrect problem witj SPI.

I use a signal generator to make a sine wave with a fixed low frequency,and sometimes my waveform will like this:

There is a spike point in the red circle.(It seems like a 0.05~0.1V voltage spike here ,but sometimes it is large.) That impact my job real bad.
I'm using python code,setting the SPI=1000000 ; GAN =1 ; 2000SPS or 3750SPS , and using the SELFCAL , SELFOCAL , WAKEUP , SYNC in series,and finally , RDATA.

And after reading 3 bytes from buffer through SPI , I use the code below to convert it to the data points like above picture.

read_data = (buf[0]<<16)& 0xff0000
read_dara |= (buf[1]<<8)& 0xff00
read_data |= buf[2]& 0xff
return read_data

I really sure that this problem is not make by signal generator cause I use a DC power supply to test it .

Is there any special setting before using CAL command I should do? Or python is not fast enough ? Or it is a original problem with this chip? Or how can I avoid this issue with some method?


I really need to deal with it eagerly , thank you !

  • Hi,

    Welcome to the TI E2E Forums!

    Sometime noise can cause some small spikes in a sine wave plot; however,  what you're describing appears like it make have more to do with the ADC conversion timing or SPI timing...

    • If your code is stopping and starting ADC conversions, then its possible that you might not have a consistent data rate and get a results that is incorrectly aligned in the time domain.

    • Alternatively, you should check the SPI signals on a logic analyzer or oscilloscope to ensure that your Python code is reliably clocking out the ADC data well before the /DRDY signal goes low (indicating that a new conversion has completed). If you find that your code is clocking out ADC data while /DRDY goes low, you may be getting a corrupted result which is a combination of bits from the previous two results.


    The second issue is a common one that I see when using higher-level languages such as Python. Higher-level languages often have additional over-head or timing delays which can cause problems when hardware requires strict timing.

  • OK, I'll try it out , thanks a lot !