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.

ADS131E06: Using ADS131e06 chip without monitoring DRDY pin

Part Number: ADS131E06

Hi All,

Good Morning !

I need some clarification on ADS131e06 ADC chip regarding the usage of DRDY pin. I actually gone through the data sheet several times, but still it is bit confusing to me.

I have following queries;

1. Can we read data from this device without monitoring DRDY signal ?

2. I understand that there are two reading methods called RDATAC mode and RDATA command mode. And for RDATAC mode it is compulsory to monitor DRDY signal.

    But in the description of RDATA command mode it is explained as below;

9.5.3.10 RDATA: Read Data

The RDATA command loads the output shift register with the latest data when not in Read Data Continuous mode. Issue this command after DRDY goes low to read the conversion result. There are no SCLK rate restrictions for this command, and there is no wait time needed for the subsequent commands or data retrieval SCLKs. To retrieve data from the device after the RDATA command is issued, make sure either the START pin is high or the START command is issued. When reading data with the RDATA command, the read operation can overlap the next DRDY occurrence without data corruption. RDATA can be sent multiple times after new data are available, thus supporting multiple data readback. Figure 41 illustrates the recommended way to use the RDATA command. RDATA is best suited for systems where register settings must be read or the user does not have precise control over timing. Reading data using the RDATA command is recommended to avoid data corruption when the DRDY signal is not monitored.

    Please check the two statements above and it creates some confusion about DRDY signal.

3. In our design currently we are only planning to use pure SPI interface without using any external GPIO dependencies.

4. Can anyone please tell me what will be difference in DRDY signal behaviour in both RDATAC and RDATA command modes.

Thanks and Regards,

Renil Raju

  • Ranil,


    DRDY is provides so that you can read data every time new data is available. It's not absolutely required, but you may get out of sync between the data period and the read, and you may miss a data reads.

    Between RDATA and RDATAC modes, the DRDY does not behave differently. In both cases, if a new conversion completes, DRDY goes low. DRDY returns high on the first falling edge of SCLK or it stays low until a 4fclk pulse indicates the new data conversion is ready. The difference between RDATA and RDATAC modes is what data you might get out if you use the different modes of reading data.

    In RDATAC (read data continuous) mode, the ADC data appears every time you clock out SCLK. This is convenient when you're trying to simplify the communications and just want to see the data coming out of the device. The problem in this mode is that you shouldn't do this without looking at DRDY. This way you can clock out the data at the right time and clock it out before a new conversion completes.

    If you are in the middle of clocking out the data and a new conversion completes, the new data is still put on the DOUT register. In this situation, you would clock out the first bits of the data, and then you would clock out the first bits of data from the new conversion. This would give the wrong data for the ADC read.

    Using the RDATA command, eliminate this type of error. When the RDATA command is used, the output data is buffered to the DOUT register. Even if you get a new conversion, the output data doesn't go to DOUT unless another RDATA command is issued.

    In short, RDATAC has unbuffered data on DOUT and updates if there's a new conversion completed, RDATA command has buffered data on DOUT, and updates when RDATA command is issued.

    Hopefully that answers your question. Post back with any other comments or questions.


    Joseph Wu
  • Renil & Joseph -

    We attempted to use the same SPI only design with the ADS131E06 that you are discussing, and discovered that the RDATA command does not work as documented in the data sheet; if you read data at the wrong time, the data will be corrupted. The window of time resulting in corruption is much smaller than for the RDATAC command, but still present. You can see the relevant thread here: e2e.ti.com/.../615552

    Good Luck,

    Brian Clendenin
  • Brian,


    Thanks for the reference on this post. I had never seen this one before.


    Joseph Wu
  • Joseph and Brian,

    Thank you so much for your valuable inputs..

    @brian,

    I checked your thread, but you were sending data (or SCLKS) Byte by Byte right ? As per my understanding (please correct me if I am wrong!), we need to send SCLKs continuously after issuing RDATA command right ?

    Thanks and Regards,
    Renil Raju
  • Hi Joseph,

    Thanks for your reply.

    I just want to add one more question here.

    1. As you said, if RDATA command has buffered data on DOUT, then what will happen if any new conversion data arrives ? will it just update the output buffer independent of RDATA command ? or the output buffer updation will happen only if we read the previous data by issuing RDATA command ? Otherwise I believe this will also cause corrupted readings if we try to issue RDATA command while the output buffer is being updated, right ?

    Thanks and Regards,
    Renil Raju
  • Ranil,


    As Brian's post indicates, there might be a problem when new conversion data arrives. I haven't had a chance to read through the entire post, or follow this up with Tom for more details. However, it looks like if 1) /DRDY falls within 3.4us of the RDATA command and 2) the status register isn't read by the time /DRDY falls, then the data might be corrupted.

    In the post, Brian says that there are two work arounds: 1) delay issuing RDATA until /DRDY has fallen, or (2) reissue RDATA if /DRDY falls before the status register is read. In either case it seems that you still need to monitor /DRDY to get around this problem. In this problem, it looks as if there may be some error latching the data onto DOUT after the RDATA command is issue.

    At this point, I don't know anything about the source of this error and I've never personally observed it. I do think that using /DRDY as an interrupt is the safest way to go to prevent read problems, and I'd use that method to read the data correctly.


    Joseph Wu
  • Renil -

    We were sending SCLKs as fast as we could, which for our microcontroller results in (best case) a small delay between each byte of SCLKs. It seemed that if the status register was in the process of being clocked out when DRDY fell (it did not have to fall between bytes), the data registers would be corrupted in unpredictable ways (we ran the ADC in the internally shorted mode, and the corruption was very evident with that). I added extra delay between bytes for some of the testis. As we only have limited SPI bus speeds, we couldn't see if there was a speed fast enough to avoid the problem altogether. 

  • Joseph and Brian,

    Once again thank you so much for your replies.

    So as conclusion,

    1. For reading ADS131e06 ADC chip in RDATAC mode, it is compulsory to monitor DRDY pin as an interrupt.

    2. For reading by RDATA mode, even though it is not mandatory, it is also recommended to monitor DRDY pin as an interrupt to avoid data corruption.

    Thanks and Regards,
    Renil Raju