Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

ADS1220: ADS1220 configuration delay for high-speed cold-junction compensation

Part Number: ADS1220

I am using the ADS1220 as a high-speed type-E thermocouple amplifier to collect a temperature reading >=10 samples per second (SPS) over the range -20-40 C operating in continuous conversion mode.  I have implemented the reference design presented in Figure 74 of the datasheet. While, there are multiple options to read the cold junction, I prefer to use the ADS1220's built in Temperature Sensor (TS), to simplify the design. The center of the IC is within 0.5" of the cold junction, and distant from other sources of heating so the accuracy of this method of cold junction compensation (CJC) may be sufficient. As I am looking for relative changes in the high speed temperature signal, I would like to make a CJC measurement for each thermocouple measurement. WHen I subtract intermittent CJ readings, I get unavoidable steps in the time series, that may negatively affect analysis . When reading the thermocouple and CJ readings at high-speed, I notice roughly a 50 msec delay period is required between changing TS modes and when a new reading value is available. A delay period of 50 msec does not allow a sample rate of 10 cold junction AND thermocouple SPS, with sufficient communication overhead.

QUESTIONS:

Is the delay period following a change to Configuration Register 1 of 50 msec expected?

Is a minimum delay after changing the TS modes specified in the datasheet?

Is this delay period similar and applicable to any changes to Configuration Register 1 or other configuration registers?

Design details and schematic are listed below.

Design details

 ADS1220 is interfaced using a dedicated hardware SPI port on an ESP32. SPI speed is default at 1MHz. I am using a hardware interrupt (FALLING) on the DRDY pin to monitor data conversion.

When reading the thermocouple, the chip is configured as follows:
  • 45 SPS
  • 32x gain
  • Thermocouple type: E
  • Temperature measurement range: -20 to 40C
  • Update rate: >=10 readings per second
  • Supply voltage: 3.3V
  • Reference voltage: internal 2.048V reference
  • AINp = AIN2, AINn = AIN3
  • IDAC2 is disabled
  • IDAC1 is enabled and set to 50uA and connected to AIN2
  • No 50 or 60Hz rejection filters are applied
  • Temperature sensor is disabled
  • Burn our current source is off
When reading the ADS1220 Temperature Sensor, the TS mode is enabled by setting the TS bit to 1.




Schematic:

Pseudo code:
setup{
initialize SPI bus 
Reset ADS1220 sensor
perform offset null reading
set sensor into continuous conversion mode
}
loop{
Configure chip for TS mode
Collect CJ reading
Configure chip for thermocouple mode (differential between AN2 and AN3)
measure thermocouple voltage
convert cold-junction temperature to voltage
add the cold-junction voltage to the measured thermocouple voltage
convert thermocouple voltage to temperature using NIST lookup table
store thermocouple temperature
}
  • Hi John,

    Welcome to the E2E forum! How are you determining when the conversion has completed?  And how quickly can you read from the device and set up the next measurement?

    The ADS1220 is a single-cycle setting device, however any time that it takes from the end of one conversion to read the data and then change the register settings to the next measurement will extend the time.  If you are using 45sps, the conversion period is about 22.2ms.  New conversion results are ready to be read from the ADS1220 when DRDY makes a transition from high to low.  You should attempt to read the conversion result as soon as possible after DRDY transitions from high to low.  Any delay will be added into the next measurement.  If it takes you 320us to read the result, and then another 320us to write the new configuration, then once the register has been written the conversion will restart at that point.  So you could have significant delay if you are unable to read the result immediately after conversion completes.

    Based on the length of time you are stating I think you may be missing a conversion result.  This can easily happen if you are polling the DRDY pin.  The best method of capturing every conversion result is by using an interrupt driven system that is looking for a high to low transition on the DRDY pin.

    As the SPI communication can be used in full-duplex, I would suggest that you make the configuration write at the same time you read the data.  An example of this process is shown in Figure 66 on page 38 of the ADS1220 datasheet.

    For troubleshooting I would suggest you connect an oscilloscope or logic analyzer and monitor DRDY and the communication to make sure that you are capturing all of the conversion data and to monitor the timing of the event loop.

    Best regards,

    Bob B

  • Hi Bob,,

    Thank you for the warm welcome and a thoughtful, detailed response.
    I am using a hardware interrupt set to monitor FALLING on the !DRDY pin and I plan to read results as soon as this occurs. To test the interrupt monitoring method, I ran the device in continuous mode with no configuration writes separately at varying sample rates and measured times between interrupt triggering. The measured time between interrupts was on par with the sample rate (for example I measured a delay of ~22 msec for 45 SPS, ~6 msec for 175 SPS, ~1 ms for 1000 SPS, etc). However, as soon as I update configuration registers to flip back and forth between temperature sensing mode and A/D mode, I am confronted with the 50 msec delay before I observe sensible readings from the device (other than "-1"). If the delay is not in the chip, then I will have to take another look at the routine to see how it is possible that I am missing cycles...I'll observe the DRDY pin on a scope to look for missing conversion results, as you have suggested. I'll also look into writing the configuration at the same time as the read as that seems most straight forward to implement for this application. Thanks again, more to follow....

  • Hi Bob,

    After further investigation, I determined that I wasn't missing scans but instead made a mistake in software- doh! Briefly, when cycling temperature sensing mode on and off,  I mistakenly set the sampling mode back to 20 SPS, resulting in a delay of 50ms between scans. Once I corrected the error, the device is operating as desired.

    Thanks, John