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.

ADS1018-Q1: Is it possible to get conversion results for all channels within 3ms?

Part Number: ADS1018-Q1
Other Parts Discussed in Thread: ADS1018

Tool/software:

Hi team,

I am receiving the ADC value of the sensor via SPI communication.
In the case of ADC1018-Q1, conversion is possible at a speed of 3300SPS, but when I actually used it, it took 2~3ms per one channel.
In the future, I may change the component to pin-to-pin to receive all 4 channel results within 1ms, but my current goal is to receive all 4 channel results within 3ms.
Is it difficult to receive all 4 channel results within 3ms due to the limitations of the ADS1018-Q1 component, or is there something I missed?


I will provide basic design information. If you need any additional information, please reply as soon as possible.


static const uint16_t ads1018_cmd[4] = {
0xF1CA, // AIN3
0xE1CA, // AIN2
0xD1CA, // AIN1
0xC1CA // AIN0, PGA 6.144V, 3300SPS, Continuous-Conversion Mode
};


Current Baut rate : 31250 bps
No parity bit
Data length : 16 bit

Target data cycle : All 4 channels of data within 3ms

B.R.

Dong-uk 

  • Hi Dong-uk,

    Thanks for sharing. Are you able to take logic captures of the SPI transactions in order to inspect the timing more closely? Are you polling the falling edge of ~DRDY before switching the MUX through DIN?

    Regards,
    Joel

  • Hi Joel,

    Originally, we were going to show you the latest waveform, but since we didn't have the conditions, we're uploading an old photo to explain.

    As such, it operates by changing the cs pin to HIGH/LOW whenever data is received.
    What I'm curious about is whether it is possible to send 4 data within 3ms when we tried it.
    As such, 4 data within 5ms is possible, but the data is greatly transformed within 3ms.

    Regards,

    Dong-uk

  • Hi Dong-uk,

    It seems to me like the DOUT/~DRDY pin is low for some time between the commands, indicating that conversion data is ready to read. Because of that, I think the delay between the commands can be reduced without any issue. Are you able to change that in your software? 

    Can you elaborate more on what is meant by the data being "transformed within 3ms"?

    Regards,
    Joel