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.

ADS1298 data read corruption

Other Parts Discussed in Thread: ADS1298

Good Evening,

I am having an issue with occasional data corruption when reading out data using the RDATAC mode.

I am using channels 2, 3 and 7, with the remaining channels turned off.  Per the datasheet, unused channels should be read out as all 0's.

But every so often, these channels will read out with random data,  and the data on other channels is also corrupt, I can see this on the output data plots.

I've verified the SPI timings, varied the SPI clock from 200K to 1M.  I've verified the power supply rails.

I've seen this behavior on two different boards.

Does anybody have any thoughts.


Thanks,

TwilightEngineer

  • Hello TwilightEngineer,

    Which data rate are you using? Most of the time data corruption is caused by data not being shifted out quickly enough before DRDY comes low again indicating new data has been loaded into the output shift register.

    Your highest SPI clock frequency is 1 MHz. If you were to read out all 216 bits in the output from the first SCLK to the last with no gaps it would take 216 us. The DRDY period corresponding to 4 kSPS is 250 us which is very close to the mathematical limitation imposed by your SCLK frequency (i.e. any delays in the interface could result in issues). The period for 8 kSPS is 125 us so that data rate and all others higher than that would be unreachable with your SCLK speeds.

    What happens if you lower the data rate? Does the frequency of the corrupted samples decrease? Perhaps try looking at the interface including DRDY with an oscilloscope and see how close you are getting to each new DRDY falling edge.

    Regards,
    Brian Pisani
  • Brian,

    Thanks for the quick reply.

    I am operating the ADS1298 at a data rate of 500 HZ.  I am kicking off the data read via interrupt, so very little delay between DRDY and start of collection. I am finished well before the next DRDY.  I'll verify that other processing isn't causing a delay, but I should have plenty of time.

    Question.  There is a short delay between bytes during the data read, the clock is held low, while the SPI buffers are read/written, during this delay MOSI pin goes high, again with the clock remaining low.  The MOSI pin returns low before the next clock starts. Could that be an issue?

    I hate problems that are intermittent.

  • Hello TwilightEngineer,

    I doubt the MOSI going high is causing the issue since there is no command with that opcode even if those values were being latched. Is your CS going high in between the bytes? That will reset the interface.

    One thing you could try to get better visibility is to set up a GPIO on your microcontroller to transition from low to high whenever the processor takes in a corrupted value. You can use that GPIO to trigger your oscilloscope so you can look at the state of the SPI pins and DRDY when the corruption occurs.

    Brian