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

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.

Thanks,

Krunal

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!

-Clancy

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.

Thanks,
Krunal

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