• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 46 subscribers
  • Views 687 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.

ADS1262: Effective data rate in contiuous conversion with chop mode ON

Simon Steinegger
Prodigy 170 points
Part Number: ADS1262


Hi there,

I intend to run two ADS1262 in parallel. Both shall convert at 50 SPS with a common external clock (7.373 MHz sourced from an FPGA - yes not exactly 7.3728 MHz). To allow other other measurements  to run at the same sampling rate with a known phase shift I have implemented a counter that triggers all other measurements after 147'456 clock cycles (Table 8 in the datasheet: decimation ratos 8*64*288) to get exactly the same data rate.

Now the problem: Datasheet chapter 9.4.12

"As a result of the delay required by the digital filter to settle after reversing the inputs, the chop-mode data rate is less than the nominal data rate, depending on the digital filter order and programmed settling delay."

My setup works perfectly fine - as long as chop mode is disabled - which is NOT an option.

Is there anyone (probably TI insider) who can give me precise numbers (best in #fclk_cycles or us) how sinc1, sinc2, sinc3 and sinc4 affect the data rate? So I could correct my counter in the FPGA design.

Thanks and best regards

Simon

  • 0
    TI__Mastermind 44720 points

    Hi Simon,

    I'm looking into this but will need a day or two to consult our design team for the additional information. I'm not sure if I'll be able to get this information for every mode in a reasonable amount of time, so are there a few different data rates and modes that you are most interested in using?

    I would strongly consider looking into using the /DRDY signal to trigger other measurements. The effective data rate will change based on the digital filter type, data rate, and conversion start delay. Therefore, it may be easier to trigger these auxiliary measurements using a hardware interrupt and not having to relay on a timing parameter that will need to be adjusted according to the ADC settings.

  • 0 in reply to Christopher Hall
    Prodigy 170 points

    Hi Chris,

    Thanks for your reply. I made some measurements meanwhile, so I can give more precise data.

    Continuous conversion and chop are still mandatory. Sinc1 is now set, since the other filters create to much additional conversion time.

    With conversion start delay set to 0us, I find the sampling time equal to 150'063 * tclk. Which results in 20.35ms. That is acceptable for the resulting data rate in our application. 

     - so for chop mode the "first conversion latency" remains also for further continuous conversions - correct?

    -  as long as I do not set start delay > 0us this conversion time is only depending on the found #cycles (150'063) and fclk - correct? (which would allow me to keep my "counter solution")

    - in case I need to increase start delay: The start delay numbers to not directly correlate with fclk - correct? (I assume there is some analog circuitry involved - which would force me to use /DRDY as a trigger, as you suggested...)

    I am trying not to use /DRDY as a trigger since other measurements should not depend on successful measurements on the ADS1262. In that case would need an additional supervisory circuit and a "back-up trigger". Possible - but not favored.

    So I hope you find someone to answer my questions.

    Thanks a lot and best regards

    Simon

  • 0 in reply to Simon Steinegger
    TI__Mastermind 44720 points

    Hi Simon,

    I was able to gather information on the Conversion Latency for all of the SINCx filters. Here is a table that shows the conversion latency as a number of fCLK periods, and another table that shows the Conversion start delay in terms of fCLK periods:

    You were within 10*tclk on the 50 SPS, SINC1 filter conversion latency!

    Regarding your additional questions:

    Simon Steinegger said:
    so for chop mode the "first conversion latency" remains also for further continuous conversions - correct?

    Correct, each time the inputs are swapped the digital filter is reset and a new conversion is begun. Therefore, the on-going data rate will be determined by td(STDR) + DELAY.

    As an example with the above data, if you use the 60 SPS data rate, with the SINC1 filter, and a delay of 2.222ms with chopping, the effective rate (ignoring the first conversion latency) will be 125,496 + 16,384 = 141,880 fCLK periods, or about (7.373 MHz / 141,880) =  51.96 SPS.

     

    Simon Steinegger said:
    as long as I do not set start delay > 0us this conversion time is only depending on the found #cycles (150'063) and fclk - correct? (which would allow me to keep my "counter solution")

    Correct. Adding additional conversion start delay will reduce the effective data rate, as I showed in the above example. However, now that you know the number of fCLK periods associated with each data rate and delay, you should be able to determine the data rate for any combination (excluding the FIR filter since I don't have those numbers at the moment). 

     

    Simon Steinegger said:
    - in case I need to increase start delay: The start delay numbers to not directly correlate with fclk - correct? (I assume there is some analog circuitry involved - which would force me to use /DRDY as a trigger, as you suggested...)

    The conversion start delay does correlate to a specific number of fCLK periods (see above table). The datasheet did not show enough significant digits to allow you to accurately compute these values.

     

    I hope that helps!

  • 0 in reply to Christopher Hall
    Prodigy 170 points

    Hi Christopher,

    Sorry for the late reply - I was on vacation.

    Your answer was exactly what I was hoping for. This significantly increases my confidence in my current solution. Although I have to do some testing regarding the 10*tclk difference...

    Best regards Simon