• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 475 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1112: Single Conversion Mode taking longer than 3x sample period

John Fedak
Expert 6715 points
Part Number: ADS1112

Hi Team,

My customer is running into an issue with the single conversion mode on the ADS1112 taking longer than 3x the sampling period:

Our firmware team is using the device in single-conversion mode, setting the ST/DRDY bit to 1, and then waiting 3x as long as the sample period before reading the conversion result. As a check to ensure that the sample occurred, they are reading the ST/DRDY bit to ensure it’s been reset to 0. This works well most of the time, but occasionally and inconsistently that bit does not change back to zero. Two questions:

 

1.       Are we using this bit as intended?

 

2.       Are you aware of this or any similar issues with this part? Solutions?

Appreciate your thoughts and feedback.

Regards,

~John

  • 0
    TI__Guru* 97555 points
    John,


    Yes the customer is using the bit as intended, but no, I'm not aware of any problems or similar issues with this part.

    Offhand, I'm not sure what the problem is. I'll need to know more about how they use the device. Are they using the single conversion mode or continuous conversion mode? Do they go back and forth between the two modes? What data rate are they using and how often are they polling to see if the bit to check the data? If they have some logic analyzer plots, I'd be interested in seeing those as well.

    In most SPI devices it's easy to see when the conversion completes with a DRDY transition. For this device, you can only read the indication through an I2C transaction, making the timing difficult.

    Regardless, send as much information as possible about how they use the device and how they read it back, and we can try to debug it.


    Joseph Wu
  • 0 in reply to Joseph Wu
    TI__Expert 6715 points

    Hi Joseph,

    The customer has let me know:

    Yes, we are using the I2C version which makes it hard to know when the bit clears. We are using the device only in Single Conversion mode, sampling at 60 Hz. The ST/DRDY bit is set to 1, we receive an I2C ACK, and we wait and then waiting 3x as long as the sample period (50ms) before reading the conversion result.

    I suppose we could setup a test to continuously read the Configuration register to see when it changes, but the error occurs so inconsistently it would be hard to duplicate.

    It almost seems that the device occasionally gives us an I2C ACK but doesn’t actually update the register to start the conversion.

    Regards,

    ~John

  • 0 in reply to John Fedak
    TI__Guru* 97555 points
    John,


    Normally, if the customer is running in single conversion mode, I would just wait the max data period to read back the device. If the device is running with a data rate of 60SPS, the nominal period would be 16.7ms. However, with variation of the internal oscillator frequency you should wait about 22.2ms for the conversion to complete. There might be an added 20us to start up the device, but that's a small amount of time in comparison.

    However, I think it's strange that the conversion either doesn't get started or takes longer than expected. I think that the test to continuously read the device from the start of the conversion is a good idea. I would have started with that. This way you can tell if the device is not understanding the start of the conversion or if the device is just taking longer to complete the conversion. You can also check to see if the conversion has started with the current draw in the device. If the conversion has started, it will draw current, if it has not, the current draw will be minimal.

    Does your customer have some sort of logic analyzer to plot out the I2C communications? It would certainly help to have all the communication, along with time information with the result. What I2C mode or data rate are they using?

    One thing to note, I think that if the device is busy with a conversion, and it is commanded to start a new conversion, I don't think it restarts the conversion for a new one. It may wait for the current conversion to complete and then execute the next command after the completion of the current conversion.


    Joseph Wu
  • 0 in reply to Joseph Wu
    TI__Guru* 97555 points
    John,


    Was your customer able to resolve this problem? I'll go ahead and close this post, but if there are continuing issues, you'll be able to post back with more comments.


    Joseph Wu