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: Read value has huge spikes

Part Number: ADS1256

Hi,

I am using ADS1256 for a project where I read 3 differential channels in an infinite loop. Most of the features of the IC works pretty well. However sometimes I see some huge spikes in value that I read. This only happens to the differantial channels except first one(AD0-AD1 configured as AINP-AINN). In the image at the bottom, I gave 10mVP-P sinusoidal wave with a DC offset of 50mV to the second differential channel which shown as blue line in the image. As you can see, there is huge spikes. This is not related to the signal source because I tried so many alternatives. I thought it might be noise but when I switched channels, spikes were on the same channel.  

  

  • Hi,

    Would it be possible for you to share a text file with the ADC's raw data (output codes)?

    Also, how are you reading the ADC data?
    - Are you using an interrupt to detect the /DRDY falling edge or do you poll the ADC to determine when data is ready?
    - When reading data, are you clocking out the data directly in RDATAC mode, or do you use the SDATAC mode and send the "RDATA" command each time before you clock out the data?

    It might be a good idea to look at the SPI communication on a logic analyzer or oscilloscope to see if there are any timing issues. There is a similar issue in the following E2E thread that you might find helpful:
    e2e.ti.com/.../1603346

    Best regards,
    Chris
  • I've attached a file that contains ADC's raw data. On the first column, there are values from a RF signal where those spikes doesn't occur. On the second column, there are values of 30mVP-P sinusoidal signal with 15mV DC offset so it doesn't go negative. I'm reading values with an interval of 5000us to establish sampling frequency of 200Hz. 

    I'm using a Raspberry Pi and programming with C language. This is the way I am capturing DRDY state.

     

    static void ADS1256_WaitDRDY(void)
    {
        while (bcm2835_gpio_lev(RPI_GPIO_P1_11) != 0);
    }

    About the last question, I am sending RDATA command each time clocking data out instead of using RDATAC command.

    file.txt

  • Hi,

    Thanks for the raw data!

    I couldn't make out if there were any bit shifting errors when reading the data since the input signal is sinusoidal. Do you see this issue when inputting a DC voltage and if so, would you be able to share that data?

    Also, before reading data (or writing to the device registers) are you sending the SDATAC command?

    Best regards,
    Chris

  • Hi Christopher,

    I've attached a file that contains raw data of a 200mV DC signal. 

    Since I'm not using continuous data reading mode, I'm not calling for SDATAC command anywhere in my code. Should I use SDATAC command even though I'm not using continuous mode?

    And lastly, I think my problem is somehow related to t6 timing specified in datasheet. I'm using a 7.68MHz oscillator for my clock frequency. Therefore, minimum t6 wait time should be around 6.5 microseconds. Whenever I use a wait time around 15-20 microseconds, these spikes occur more often. I tried many values and found out 10 microseconds would be proper choice. Spikes are occuring less however they still exists.

    5340.file.txt

  • Hi,

    Thanks for the additional data!

    As a best practice after powering the device, I would recommend sending the RESET command, delaying a few mircoseconds, and then sending the SDATAC command to ensure that the ADS1256 is not in RDATAC mode after start-up. So try adding the SDATAC command as one of the first commands you send to the ADC...

    Interesting observation about the t6 timing! As long as you waiting at least 6.5 microseconds between the RDATA command and when you start clocking out data, you shouldn't have any issues. However, you might be running into the case where you are reading data during the next conversion completion (i.e /DRDY is transitioning low, while you are sending the RDATA command). When this happens it is possible to read out a combination of old and new data, which gives a result that doesn't make much sense...

    Using a polling routine for /DRDY might be problematic if your software is often busy running other processes (or slow to return to the polling function). You might be catching the /DRDY low late in the conversion cycle and only beginning to read data as the next conversion is completing.

    What is your SCLK frequency? if it is significantly slower than the maximum 1.92 MHz limit, is it possible for you to speed it up to read in the SPI data faster?

    Also for troubleshooting, you might try decreasing the ADC's data rate to see if the data spike go away when running at the slower data rate (i.e. you are giving the MCU more time to read the ADC data before the next conversion completes). If this tends to resolve the problem, then most likely you'll need to find a way to respond to the /DRDY falling edge and read the ADC data faster.

    Best regards,
    Chris