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.

TLV2556: Preferred method for reducing throughput to increase accuracy (reduce sampling error)

Part Number: TLV2556
Other Parts Discussed in Thread: TLC2543

We are having some issues getting reliable readings from the TLV2556. It seems we are seeing sampling error due to large step changes in DC values between successive input channel. In the "application information" section note 2. the datasheet mentions increasing accuracy by reducing the throughput. What is the preferred method for reducing the throughput to increase accuracy (extend time between reading channels, reduce I/O clock speed,...)?  

  • Hi Kevin,

    Using Figure 2 on page 10 as an example, the sampling time is based on the last eight I/O clock cycles.  This is when your input signal is applied to the internal sample/hold capacitor.  The slower you run the I/O clock, the longer the time you have to sample the input channel.  This is at the cost of overall throughput, but should provide a better result.  The other option would be to take a look at the circuits you have driving the analog input channels.  Take a look at our SAR ADC Driving series of videos for more detail.

  • Thanks for the information. This is actually going to be an alternate to TLC2543 (which doesn't seem to have the channel switching carry over issue). Since the hardware is released were are trying not to change it. We are looking at changing the software to read the same channel 2x in a row to resolve the issue. Just curious if you had any other recommendations. 

  • Hi Kevin,

    Reading the data twice and throwing out the first result is also an option, that might come at a higher throughput hit though than simply slowing down the SCLK.  The TLC2543 would also be subject to the same issue that you noticed with the TLV2556 since the sampling caps and mechanism are very similar.

  • Thanks for the information, we will look into which option works best with our firmware. Currently we use the same clock for other devices so we need to assess the impact to our code. Oddly we have been using the TLC2543 for years without issue. The TLV must be slightly more sensitive. Thanks for the feedback.