• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 207 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1258-EP: Conversion latency lower then expected

Daniel Rossinsky
Prodigy 10 points
Part Number: ADS1258-EP
Other Parts Discussed in Thread: ADS1258

Tool/software:

I am reading channels AIN0-15 and all SYSRED channels which comes out to 21 channels in auto-scan mode. from the ADS1258-EP datasheet I calculated my sample rate from the following formula:

SPS = Fclk / (128 * (4^(11b-DR) + 4.265625 + TD) * 2^CHOP)

Fclk = 14,400,000Hz

DR = 11b (maximal data rate)

TD = 0

CHOP = 0

SPS = 14,400,000/ (128 * (4^0 + 4.265625 + 0) * 2^0) = 21,365

I calculated the conversion latency from the Calculating Conversion Latency and System Cycle Time for Delta-Sigma ADCs document as follows:

Tcl = x / ODR

Where x is the sinc filter order and got:

Tcl = 5 / 21,365 = 234us

Meaning that the latency for converting all channels should be 21 * 234us = 4914us. However, when I benchmark the software it takes only 2546us and all the samples come out correct.

Here is an example in pseudo code for what is being done:

// Benchmark starts here

CS PIN DRIVEN LOW

FOR CHANNEL in CHANNELS

{

    PULSE CONVERT

    DO {

        CHANNEL READ COMMAND

    } WHILE NEW BIT != 1

}

CS PIN DRIVEN HIGH

// Benchmark ends here

Is this ADC's conversion latency lower then the formula or am I getting something wrong ?

  • 0
    TI__Guru 52326 points

    Hi Daniel Rossinsky,

    The auto-scan mode equation effectively takes into account the sinc5 filter latency, so you do not need to divide by 5 again

    Therefore the data rate for all channels is 21365 SPS in your system, and the effective data rate per channel is 21365 / 21 = 1017 SPS. This does not account for any delays required by the device to communicate, or any software delays for example. But if you just let the system run, you should see the DRDY pin toggle at ~21365 Hz, and it will take ~1ms to read the first channel, scan through all other channels, and then wrap around to read the first channel again.

    -Bryan

  • 0 in reply to Bryan Lizon86
    Prodigy 10 points

    Hi Bryan Lizon,

    Sadly I cant use DRDY. However, my solution was to poll each channel until the NEW bit in the status byte is 1, is it a valid approach? Also, just to make sure I understand correctly, the formula from here (this one: Tcl = x / ODR) is already accounted for in auto-scan mode ? Lastly, if I did use DRDY, I can read the channel as soon as it toggles the first time in auto-scan mode correct?

  • +1 in reply to Daniel Rossinsky
    TI__Guru 52326 points

    Hi Daniel Rossinsky,

    Using the NEW bit is fine, but it's unlikely you could see the exact timing I was referring to with this method because you basically have to blindly read the STATUS byte until the NEW bit is set. But yes, there are no issues reading the STATUS byte to check the NEW bit instead of using DRDY, there's just more communication overhead. You could however probe the DRDY pin on your board to see what I am referring to, even if you cannot use this in your final system

    Yes, the equation given in the ADS1258 datasheet includes the sinc filter latency. The ADC "knows" that it needs to wait for 5 conversion periods (+ some extra fixed delay) in auto-scan mode because it only takes one reading per sequence step. Therefore the digital filter must reset each time

    In fixed channel mode, you can continuously measure the same channel if you want, so after the first conversion you don't need to wait 5 cycles anymore for settled data. That is why Table 5 shows that the data rate for Auto-Scan mode is ~24kSPS while the data rate for fixed channel mode is 125kSPS when Num_Ave = 1 (that is, using just the sinc5 filter). You can see that this is approximately a factor of 5 because again auto-scan mode is all first conversions (to use the app note nomenclature) while fixed channel mode can provide continuous data on the same channel (second and subsequent conversions). However, as Num_Ave increases, this is adding a second filtering stage that starts to dominate the overall latency, which is why the data rates in the two modes start to converge as Num_Ave increases.

    Yes, a high to low transition on DRDY indicates that new data are ready to be clocked out of the ADC. You would of course need to respect the timing conditions stated in Table 1 and Table 2.

    -Bryan