• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 47 subscribers
  • Views 3505 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.

what's the meaning of Single-Cycle Settling

Frank Shao
Prodigy 50 points
Other Parts Discussed in Thread: ADS1147

hi，

how to understand Single-Cycle Settling for All Data Rates on page 1 described in ADS1147 data sheet？ When changing channel,  or PGA, or data rate, how long should MCU need to wait (ADS1147 can work correctly)?

  • 0
    TI__Guru 55466 points

    Hi Frank,

    Single-Cycle settling means that the first conversion result obtained from the ADS1147 is fully settled and the internal digital filter has no latency.  The ADS1147 has a built in linear-phase FIR filter that always settle in a single cycle at all data rates.  This would be in contrast to a device that contains a SINC digital filter where the user has to wait a specific settling time or wait a few conversions for the digital filter to settle.

    The conversion times are given on Table15.   Conversion times are given for different data rates.  The table contains the conversion time for the first conversion after a digital filter reset; and the conversion time for the second and subsequent conversion times.  For example, at 1000 SPS data rate; the first conversion time after a filter reset is 1.014ms and 1 ms for second and subsequent conversions.

    In situations where the user needs to only change the channel but do not require change PGA and data rate settings, simply changing the MUX0 is sufficient.

    In situations where its necessary to change channels and change data rate/PGA settings; it may be necessary to split the communication into two separate communications allowing to change the SYS0 register before the change in MUX0 register to avoid a overload condition.  When the configuration data is transferred to the device, new settings become active at the end of each data byte sent.  Therefore a brief overload condition can occur during the transmission of configuration data after the transmission of the MUX0 byte and before the completion of the SYS0 byte.  To ensure that the overload condition does not occur, split the communication into two separate communications allowing the change of the SYS0 register before the change of the MUX0 register. 

     When changing the data rate, ensure that the PGA is not over-loaded otherwise a slower settling time will occur.  Since the ADS1147 has chopper-stabilized PGA, changing data rates during an overloaded state can cause the chopper to be unstable and this instability results in slow settling time.

    Thank you and Best Regards,

    Luis

  • 0 in reply to Luis Chioye
    Prodigy 50 points

    Thanks, Luis

    I have another question.

    What's the meaning of  PGA is  over-loaded. In what situation it occurs and how to avoid?

  • 0 in reply to Frank Shao
    TI__Guru** 113765 points

    Frank,

    I will attempt to answer for Luis.  An overloaded condition occurs if your input voltage exceeds the full-scale input of the PGA at a particular gain setting.  The full-scale input is based on the reference voltage and PGA setting.  For example, if the reference is 2.048 V and PGA is 1, exceeding 2.048V at the input will overload the PGA.  If the PGA is 16, the PGA is overloaded if more than 128mV is applied (2.048/16).  To prevent this situation, you need to make sure that you change the PGA to a lower setting when applying a larger input voltage. 

    For example, if you are measuring one set of MUX inputs and it is a lower voltage and are using a higher PGA setting, but the next set of MUX inputs is a higher voltage, you need to make sure you change the PGA first, then change the MUX to prevent the overloaded condition. 

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Intellectual 855 points

    What would the expected settling time be if an overload did occur?

    I change the PGA gain following an overload, wait 500ms (in a test) and the next reading is still clipped at the max value. The subsequent readings (570us intervals) are all correct. It seems that what ever wait time I put in after the PGA change, the first following sample is always clipped.

    I may have to detect overload and throw the following sample away, but I would hope this is unnecessary. Any suggestions on this?

    Regards,

     Ben

  • 0 in reply to Ben Henricksen
    TI__Guru 55466 points

    Hello Ben,

    When you mention you waited 500ms in the test, is the device coming on after sleep mode or are you continuously converting?  What are the PGA Gain settings and the conversion Data Rates involved?  Please provide the details of the device settings and configuration before and after the 500mS.  

    We have observed in our labs that when the PGA is overloaded; the device will typically take 4 to 5 conversion cycles to settle; so the settling time is dependent on the data rate.  The best suggestion is to reduce the PGA gain before changing data rates to a non-overload condition to avoid the long settling times.

    Best Regards,

    Luis 

     

  • 0 in reply to Luis Chioye
    Intellectual 855 points

    Hi Luis, thanks for following this up.

    We are running the adc at maximum sample rate, 2000 sps, using the default internal chip clock. We are doing single triggered reads at about 800 us period. I keep START low when not triggering a sample and use a START pulse to trigger the sample, so the device will be asleep after I capture the first readings at Gain 8 (input voltage 200mV). This shows we are clipping at the maximum adc value and the readings stop. I set the PGA gain to x1, pause to allow settling (temporarily set to 500ms for this test, for no overload condition I expect this to be 1ms max), then start reading again at 800 us intervals. This first reading is clipped but the following ones are fine.

    We have an interrupt routine to extract the data on the DRDY signal, so I'm pretty sure it is fresh data we are reading out.  DRDY is separate from DOUT.

    "We have observed in our labs that when the PGA is overloaded; the device will typically take 4 to 5 conversion cycles to settle; so the settling time is dependent on the data rate."

    Is that just a case of the device needing the 5 conversion time (i.e. 2.5ms in this case) or does the device have to have 5 START signals?

     

    It would be nicer to start at gain 1 and work up, to avoid overloads, but we have tight time constraints and would like it to be freely adaptive if possible.

     

  • 0 in reply to Ben Henricksen
    TI__Guru 55466 points

    Hi Ben,

    If you can not avoid the overload and you are concern about timing constraints, I believe the less time consuming solution may be to have a separate routine on your code that executes when the overload is detected.  

    If the overload condition occurs, you may want to leave the START pin high allowing the device to run in continuous conversion mode.  While keeping the START pin high, change your PGA gain to a lower non-overloaded state and wait approximately ~3ms before the next conversion is read (assuming you are using 2000 SPS data rate).  Leaving the device in continuous conversion mode will allow the internal chopper-stabilized PGA amplifier stage to settle.  You could use the SDATAC and use RDATA command to perform this reading.  After the device is settled and not over-loaded , you could come back to your normal configuration routine where you trigger the conversions with the START pin and the device goes to shutdown mode between conversions.  If the PGA is overloaded,  you will have thrown away the overloaded result,  and wait the ~3ms additional settling time at 2000SPS.

    Regards,

    Luis

     

  • 0 in reply to Luis Chioye
    Intellectual 855 points

    Hi Luis,

    Thanks for the advice.

    Would the continuous data have to be actually read out to flush things? So far I'm not seeing a difference even though the continuous data is clocking away for 10ms (this the max. settling time we have seen for X64 to X8 PGA change on overload in a continuous sample/read test program with the Eval board).

    I will have a go at setting up a different interrupt handler on DRDY for this case.

    Regards,

      Ben