• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 46 subscribers
  • Views 5569 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.

ADS1115 Conversion Delay Times

David Escandon
Expert 2175 points
Other Parts Discussed in Thread: ADS1115

Let me try to explain my problem by describing what I am doing.

I have configured the ADS1115 to 860SPS (~1.2ms samples) and single shot mode.

Then I have done the following sequence:

- Write config to select AIN0
- wait 2ms
- Read AIN 0 data
- Write config to select AIN1
- Read AIN1 data
- Write config to select AIN0
- wait 2 ms
- Read AIN0 data
etc

So I am expecting that when I read AIN0, the data for AIN 0 should appear. However, I notice that sometimes the data for AIN 0 shows the data for AIN 1 but sometimes it is correct (shows AIN0). (randomly)

I found that if I extended the delay (wait 2 ms) to more than 8ms the device starts behaving normally.

My concern is what is causing this delay when switching mux inputs. If I don't switch mux inputs the data can be read at ~1.2ms with no problem.
What is the delay time after writing to the config register before a conversion begins?

Note: by examining the rdy pin, the rdy is active sporadically when the wait is set to 2ms, I would expect the rdy pin to be consistent.

-David

  • 0
    TI__Guru** 112725 points

    David,

    Maybe it was a typo, but you need to wait between writing config to select AIN1 data and reading of the data.  If you read directly after the config write you may have read the results from the previous conversion.  So you have to wait the total length of the communication plus the conversion period.  So you need to be careful that you do not read the last conversion, but the next completed conversion after the mux change.

    I have kept better track of timing using the one shot mode where I change the mux channel and then start the conversion.  I always will have the correct data in this case.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 160 points
    Dear Bob,
    I am taking individual analog samples using the ADS1115. The configuration settings are:I single ended AIN0, 860 samples/sec, and single-shot mode. To perform sampling and conversion, I write the configuration register (for starting conversion) and then I read it until its MSbit is 1 (conversion is finished). According to some measurements I made, the conversion delay is 8 to 9 ms. Is there any way to reduce such delay, please? Otherwise, which other ADC do you recommend me?
    Thank you very much in advance.
    Best regards,
    Fernando
  • 0 in reply to Fernando Marengo Rodriguez
    TI__Guru** 112725 points

    Hi Fernando,

    Welcome to the forum!  The ADS1115 will complete the conversion based on the conversion time selected in the ADS1115 configuration register.  If you have selected 860sps, the conversion should complete in about 1.2ms following the completion of the configuration write to start conversion in single-shot mode.  If you continually poll the configuration for completion, you communication clock time may be affecting when you seeing that the conversion has completed.  In other words it is taking you longer to read the status of the device than it takes to complete the conversion.

    You could try a couple of different approaches.  One is to use a timer that you start after starting the conversion.  Let's say you set the timer for 1.5ms. After the timer has completed the count, you read the conversion result from the ADS1115.  This does assume that your timer is accurate and you have included the proper additional time for the ADS1115 oscillator startup and any oscillator variation as specified in the datasheet as +/-10%.  I believe 1.5ms should be an appropriate delay for 860sps.

    Another approach is to use the ALERT function as an end of conversion monitor.  The ALERT pin can be configured in such a way as to change state when the conversion has completed.  You can monitor this pin with your micro GPIO set up as an input interrupt pin.  When this pin changes state, you can have the micro generate an interrupt to read the conversion data.  This is discussed in section 9.6.4 of the datasheet.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 160 points

    Dear Bob,

    Thank you very much for your suggestion. The previous delay I told you (conversion ready, about 8 ms) corresponds to 128 sps. I've recently tested with 860 sps, and that delay is between 1 and 5 ms. This delay was measured via millis(); and the state of the ADS1115 was continually polled. According to your suggestion, I've used 1.5 ms and my system works. Thank you!

    One important thing I'd like to consider is the following. Since the A/D conversion is performed periodically, it is inside an ISR. Since such ISR must transfer data to and from the ADS1115, I2C communications must me enabled, and such communications also produces an interrupt. My code worked by enabling interrupts INSIDE the above mentioned ISR. Care should be taken, since the main ISR should be called each T1=10 ms, and I2C communications inside such ISR should be sufficiently fast in order to avoid any problems. Do you suggest any alternative in order to avoid nested interrupts?

    Thank you, best regards,

    Fernando

  • 0 in reply to Fernando Marengo Rodriguez
    TI__Guru** 112725 points

    Hi Fernando,

    When it comes to interrupts it is best to keep the routine as small as possible.  For example, I may have a main processing loop with sequential operations.  If an interrupt comes  for reading data I do not run the communication to the ADC inside that interrupt.  What I do is set a flag to true and that is the only operation within that interrupt routine.  In my main processing loop I check the status of the flag, and if it is true I read the data from the ADC and then switch the flag to false when the read is complete.  The same thing can be done with timer interrupts.  In this way I avoid nesting interrupts.

    Another thing you can do to avoid interrupt conflicts is to disable an interrupt so that it is only called once until the process completes.  After the routine completes you can enable the interrupt again.  Hope that makes sense.

    Best regards,

    Bob B