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.

ADS1282: SYNC command with RDATA in 500us frames

Part Number: ADS1282

Hi, I am trying to get a consistent reading of the chip every 500 us

currently I send the SDATAC command. I set config 0 to 0x51 and config 1 to 0x08. I have my SPI set to 2MHz and every 500 us I send my RDATA command, wait 12 us and then read 4 bytes. I then switch an external mux (that feeds into AN1) and then send my SYNC command and wait the 500 us till the next cycle. However, I am getting inconsistent readings and sometimes see that the conversion isn't fully complete (two LSB's are still at 0). Is there something blatantly wrong in the way I am using this chip? 

  • Hi Fady,

    Welcome to the TI E2E Forums!

    If you have ability to configure an interrupt on your MCU and only read data after a /DRDY falling edge interrupt, it will make the process of reading data much easier. However, if you poll for data or clock out data periodically, it can lead to incorrect results...

    When reading data, you are effectively clocking values out of an output shift register. Every time there a /DRDY falling edge that output shift register gets updated. Therefore, if you are in the process of clocking out data during a /DRDY falling edge, your microcontroller will read an incorrect value that is a combination of the old and new data (the LSBs of new data will get placed into the MSBs of the old result, so there's no telling what value you may get).

    Using the RDATA command...

    The RDATA command of the ADS1282 is used to tell the device to output the conversion result (when not in RDATAC mode). It should be issued before the /DRDY falling edge. Therefore, you would normally 0) program the device registers, 1) start a conversion, 2) issue the RDATA command immediately, 3) wait for the first conversion to complete (/DRDY will go low, but note that the first /DRDY falling edge always takes longer than expected see this E2E post for details), 4) clock out the data, and then repeat this process from step 2 (by sending another RDATA command and waiting for the next conversion to complete). If you don't monitor the /DRDY signal, it is possible to count the number of clocks (fCLK) provided to the ADS1282 to determine when data is ready. See tDr in table 10 for the timing calculation.

    One-shot mode...

    If you don't have the ability to monitor the /DRDY signal, you might consider using the ADS1282's "one-shot" mode (See section 9.27) ... In one shot-mode, you can start a conversion in RDATAC mode and the device will perform a single conversion and wait. So long as wait sufficiently long enough for the conversion to complete, you can read out data anytime afterwards and then start the next conversion. The down-side to using this mode is that the digital filter taps reset with each new conversion, so the overall data rate will be significantly slower than if you were continuously converting.

  • Thank you Chris, 

    Everything seems clean now. I think I had the misconception that I could read the data at any time after the DRDY signal came low instead of immediately after. 

    Just trying to reduce the timing with a higher sampling rate now

  • Hi Chris, 

    I have some follow ups after using an MSO-28 to measure some of the timings. 

    First off, in RDATA (SDATAC mode), when sending a sync command, should I see the DRDY go low? Or does DRDY only indicate a completed conversion? 

    Secondly, after the RDATA I see about 30us before DRDY falls. Should I be waiting 240 us based on the Tdr settling time? 

    Thanks

  • Hi Fady,

    In SDATAC mode, you'd need to send the SYNC command followed by an RDATA command. I believe without the RDATA command you won't see /DRDY go low.

    NOTE: The SYNC command only needs to be sent just the one time (to restart/re-sync conversions between multiple ADCs), but the RDATA command should be issued for each conversion result.

    After issuing RDATA, you'll need to wait for the /DRDY falling edge (for example using an falling edge interrupt on the MCU). The falling edge of this signal indicates that the conversion has completed (and the result is settled), so don't expect for it to go low immediately after the RDATA command...

    If this is the first conversion result (after power up, or after sending the SYNC command, or after writing to any of the device registers), the first /DRDY falling edge will be delayed due to the digital filter settling.

    • If you are using the FIR filter, the first /DRDY falling edge will take about 63 conversion periods (you can think of the FIR filter as having 64 filter taps that need to fill with data before the conversion result is settled).

    • If you are using the SINC filter, the first /DRDY falling edge will take about 5 conversion periods (i.e. the last five conversion results are averaged).

    /DRDY only goes low when a conversion has completed and the digital filter has settled so the first result will be always be delayed. However, from then on /DRDY will pulse at the normal output data rate, as defined by the DR[2:0] & FILTR1[1:0] register bits and the input clock frequency.

    Example: If you're using the ADS1282 with a 4.096MHz clock and the default 1000 SPS FIR filter mode, you should expect the first /DRDY falling edge to occur about 63.09 ms after the SYNC command, and then every 1 ms for each consecutive falling edge.

    Let me know if my explanation is clear or not...

  • It is clear, But currently I have a 16 channel mux into AN1N and P and after each mux switch I send a SYNC command to start the conversion over. 

    If I send the SYNC and RDATA directly after, the DRDY never goes low. 

    However, If I send the SYNC only, the DRDY also never goes low. 

    Only when sending the SYNC and then the RDATA after 500 us (which is plenty of time outside of the expected 240 us SINC filter at 1000 SPS (32 ksps)) do I see the DRDY signal go low. 

    Is this expected behaviour?

  • Hi Fady,

    When you say you send SYNC followed by RDATA directly after, do you have any delay between these command bytes on the SPI?

    There is a tSCDL timing requirement that requires at least 24 fclks (about 6 us) between command bytes, when sending commands back-to-back. I would expect you could reduce the 500us delay to 6-10 us and still see /DRDY go low.

    Let me know if that resolves this particular issue!

  • I tested a variation. 

    The minimum time that still works (for DRDY to fall) between a SYNC command and RDATA command is 197 us. I really don't know why this would be from looking at the spec. However, for my specific use, I only send commands every 500 us so it wont affect me

  • Hi Fady,

    Which filter type (SINC or FIR) and data rate are you programming to the device registers? Also what is you're fCLK frequency?
    The only thing that comes to mind as a possible problem is if the RDATA command is not completing before the /DRDY falling edge. Maybe I'm mistaken but I believe you should be able to access the first conversion result while in SDATAC mode.

    If you are finding the "read by command" mode of operation to the be problematic, you could try using the "read direct" or RDATAC mode...
    The SPI command sequence for RDATAC mode would only require some small modifications: After programming device registers, you would send SYNC, followed by RDATAC. Then after /DRDY goes low, clock out the data, send SDATAC, send SYNC, and send RDATAC again, and repeat this process for each /DRDY falling edge (wait for /DRDY, read data, SDATAC, SYNC, RDATAC, and so on...).