• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 47 subscribers
  • Views 257 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ADS131M06: Signal bleed with OSR below 4096

Brett Goldbach
Prodigy 10 points
Part Number: ADS131M06

Hi, I've been running into an issue with the ADS131M06 where if I try to decrease Oversampling Rate to anything below 4096, I get data from the previous sample bleeding into the next sample for each channel. This has effectively limited the overall sampling rate and can only be improved by increasing fCLKIN. I have tried with clock-rates of 2MHz and 4MHz but the same 4096 OSR limit has remained, and would assume it to stay if we went up to 8MHz.

Hardware wise, we believe we have stuck to the layout example in the datasheet, and have probed the input to each channel without observing any such bleed in the input signal.

For our application each sample is from a completely different source, and there cant be any bleed from previous samples. Is this expected behavior? is there a setting I'm missing to prevent this from happening, or a hardware configuration change? 

Thanks,

- Brett

  • 0
    TI__Guru 61826 points

    Hi Brett,

    Thank you for your post.

    This sounds like an interesting application, would you mind providing the ADS131M06 portion of your schematic?

    Brett Goldbach said:
    For our application each sample is from a completely different source, and there cant be any bleed from previous samples. Is this expected behavior? is there a setting I'm missing to prevent this from happening, or a hardware configuration change? 

    Does this mean that you are mulitplexing different input sources to the ADC channels after each conversion result? This would not be the intended use of this device due to the integrated sinc filter latency. Delta-sigma ADCs require some history to convert the analog input signal, unlike a SAR ADC.

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 10 points

    Hi Ryan, Thanks for your response.

    We aren't directly multiplexing the input sources, each channel is always looking at the same sensor. However, after each sample we do shine a different wavelength LED to be picked up by the sensors. It sounds like that 'history' requirement inherent to Delta-Sigma ADCs could be the issue causing effective bleed through at lower OSRs.

    Here is the schematic just in case that is still of use.

    Thanks,

    - Brett

  • 0 in reply to Brett Goldbach
    TI__Guru 61826 points

    Hi Brett,

    Thanks for clarifying the application and for providing part of the schematic. I did a quick review and the connections look correct to me.

    Changing the wavelength of light applied to your optical sensor is likely producing a step-change to the voltage seen at the ADC input pins (you might be able to verify this with a scope, though I'm not sure to what scale you're seeing the effects at the output). Any transient voltage will take some time to settle in the analog domain as well as additional time required to propagate through the digital filter (3 data rate periods for the sinc3 filter output). 

    My only guess as to why you don't see this at OSR = 4096 or greater is that the internal averaging is so high that the input transient is not enough to significantly disturb the digital output.

    Note that the output data rate scales directly with OSR. So ideally, one would choose the highest CLKIN and OSR combination possible to achieve a specific data rate with the best noise performance. Is there a reason you need to reduce the CLKIN frequency from the default 8.192 MHz?

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 10 points

    Hi Ryan,

    The main reason for not choosing an 8.192 MHz clock source has been for power savings. As if we could leverage OSR to get up to our target sampling rate it would be preferable compared to running the ADC at the higher power mode required with the 8.192 MHz clock.

    We are planning on testing out the 8.192 MHz configuration soon, as the increased sampling rate will likely allow us to leverage other power savings, offsetting the high power mode.

    Also I have checked the voltage input to the ADC channels and they do change dramatically as the LED source switches, that is expected for our application, so it sounds like we are just not using the correct type of ADC for the job. The internal averaging is likely something that we will just have to work around as long as we're working with this ADC, but luckily the 8MHz 4096 OSR configuration should get us to where we want to be.

    Thanks for your insight,

    - Brett

  • 0 in reply to Brett Goldbach
    TI__Guru 61826 points

    Understood, Brett. Let us know if you need further helping optimizing this device for the time being. And if you should decide to look into other devices, feel free to start a new thread and we can work though finding the right device. We support both delta-sigma and SAR ADCs, so perhaps the latter is a better fit for your application.

    Best regards,

    Ryan