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.

ADS1015-Q1 total required time of conversion and data reading in multi channel input mode

Dear support team,

Our customer is studying ADC1015-Q1 now.
I have gotten some questions regarding ADC1015-Q1 from the customer.
So please advise me about it.

Regarding the procedure that is continuous AD conversion for 4 channels of single-ended input signal continuously.

1. I suppose it is in the following manner. Is it correct?
  I. Setting input channel (for example AIN0) by write command
  II. Waiting during the AD conversion
  III. Reading the data (of AIN0) by read command
  IV. Setting the next input channel (for example AIN1) by write command
  Later, repeating the procedure II ~ IV

2. How long (What milliseconds) will be the 'waiting time' (II) needed during AD conversion?
  (in the condition of 330kSPS)

3. How long (What milliseconds) will it take, if the 4 channels of input signal will be measured continuously?

4. Is there any way to more reduce the measurement time, if the 4 channels of input signal will be measured continuously?

Best regards,
M. Tachibana

  • Tachibana-san,

    Thank you for your query. In your question 2, I believe you meant 3.3 kSPS and not 330 kSPS.

    The mode of operation that we choose is critical to minimize the throughput and conversion time. I would highly recommend to run the device in single-shot mode for measuring the single-ended inputs from 4 channels.

    The device also offers a DRDY (data-ready) feature that provides a conversion ready interrupt when a conversion is complete. In single-shot mode, you can use either the polling of the OS bit or the ALERT/RDY pin.  The process for using this method would be to:

    1. Write the Configuration to start a conversion (using the desired mux, data rate, etc. in single-shot mode)
    2. Poll the OS bit, or wait for ALERT/RDY (ALERT/RDY connected to a processor interrupt will be the fastest method)
    3. Write the new mux configuration and start the conversion, then immediately read the results
    4. Repeat the processes above for 2 and 3.

    In single-shot mode, once you switch from one channel to another and start the conversion, the ideal conversion time should be 1/ DR (data-rate). We need to add additional 10% for internal oscillator variation. In addition, we need to add 30 us worst-case start-up time.

    Giving you an example, for data rate of 3.3 kSPS, the worst case conversion time = 1/(0.9 x 3.3 kSPS) + 30 us
                                                                                                                                       = 337 us + 30 us
                                                                                                                                       = 367 us

    Answering your question, the worst-case time to read from 4-channels one-by-one at the fastest data rate without polling, in single-shot mode should be

    = 367 x 4 + time to send I2C commands + additional delay from micro/FPGA

    The worst-case conversion time is even more important to understand if the customer wants to avoid using any interrupt and blindly read the data after starting the conversion.

    Please let me know if you have more questions.



  • Hi Tachibana-san,

    That procedure is correct. When switching between channels, it is easier to use single-shot conversion mode.

    In single-shot mode, the waiting time is:
    1. Write command to set input channel and start conversion: (36 bits)/(I2C clock rate)
    2. Wait for the conversion to begin: 20us
    3. Wait for conversion to complete: = 1.1/DataRate
    4. Read out the data: (45 bits)/(I2C clock rate)

    If using continuous conversion mode, you can read back the data from the previous conversion cycle while the next conversion is being completed, and then write to change the channel for the next conversion. The alert/ready feature will add about 8us to the timing. How this works will depend on your conversion speed and the I2C speed. If it is not possible to read the data back and write to change the channel before the conversion completes, then it could take two conversion cycles before the channel is changed.

    I hope that this helps!

  • Dear Krunal-san and Clancy-san,

    Thank you so much for your help.
    Yes, 3.3kSPS is correct.
    And I understood the procedure and advised it to the customer.

    I have one more question.
    How long must we wait for the conversion to begin?
    Is it 25μs, or 20μs?
    I suppose it is 25μs in the worst case.

    Best regards,
    M. Tachibana

  • Hello Tachibana-san,

    I checked with the design engineer here. It is safe to have 30 μs delay worst case. Just keep in mind that this delay to start the converesion is internal to the device and hence the customer wouldn't know on exactly when the conversion starts.

  • Dear Krunal-san,

    Thank you so much for your help.
    Our customer wants to know the procedure and timing chart for his software design.
    So I advise that 30 μs is enough to wait for starting conversion.

    Thanks and best regards,
    M. Tachibana