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.

ADS1263: Random offsets of readings

Part Number: ADS1263

Hi,

 

We have a product using the ADS1263.

 

This system measures temperature to 0.005c accuracy. We have had units in the field for a while but in the last month all the new units are having spikes / offsets.

 

We have spent a couple weeks on this both in hardware and firmware and we are now looking for some new ideas as to what could cause this. Can a TI expert on the ADS1263 take a look at the plot and schematic and give us some new ideas what could cause our A/D reading to be offset randomly?

 

It always happened on the sensor connected to P301, but every now and then has also shown up on P300.

 

Thanks,

 

Aaron

5857.Schematic Prints.pdf

  •  Not sure the plot made it, trying again..

  • Hi Aaron,

    From your schematic I noticed that the /DRDY pin is not connected... The most common issue I see with erroneous ADC results is typically due to reading the ADC data while the /DRDY signal goes low. If you are directly clocking out the data without first sending the RDATA command, it can be very easy to get corrupted data. Do you know if you are using the RDATA command when reading data?

    What happens when clocking out data without the RDATA command, is the output shift-register will get loaded with the new conversion results while you are in the middle of trying to clock out the old conversion result. One of the easiest ways to avoid this issue is to prepend the "RDATA" SPI command to the beginning of your read data process. When the ADS1263 sees the "RDATA" command it will store the conversion result into a buffered output-shift register so that you are able to clock out all of the conversion data without worrying if a /DRDY falling edge will corrupt the data mid-read.

    If adding the "RDATA", doesn't resolve this issue then we might need to look at a few other possible causes and even try to capture a logic analyzer screenshot of the SPI communication to get a better idea of what might be going on.

    Best regards,
    Chris

  • Hi Chris,

    That might be the issue. We changed firmware designers half way through the project. The new guy made some changes and are now testing. It does sometimes take a while to happen.
  • Hi Aaron,

    If the problem is related to reading data while a new conversion is completing, increasing the data rate would likely cause the issue to happen more frequently. At slower data rates there is more time between conversions and your software is more likely to clock out all of the data before the next conversion result completes and is loading into the output shift register.

    Try increasing the data rate to see if you see the issue more frequently. Also, keep in mind that if you have other processes running on your microcontoller that might delay the reading of ADC data that there could be a correlation between the frequency of the higher priority interrupts/processes and invalid ADC readings.

    Best regards,
    Chris