• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 449 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.

Original question:

DAC8820: Settling time clarification

DAC8820: DAC8820

Avatar
Intellectual 460 points
Part Number: DAC8820
Other Parts Discussed in Thread: OPA828,

Tool/software:

Using a DAC8820 with a OPA828 (+/- 15v), VRef=-12.5v

When the digital value input to the DAC represents a “large” jump (Decimal 65,536 to 20,000 for the DAC falling edge scenario), the DAC output takes a very long time to settle to its final value (≈2msec or more). Scope set to 500usec/div.


When we change the step to a small range (Decimal 30,00 to 20,000), this phenomenon does not exist.

With a 200nsec/Div timescale (and same set-up as above), we see the “short term” settling time of the op-amp output to be within the 0.5µsec data sheet spec for all codes (followed by the "long term" settling to the final correct output voltage value)

It appears that there is the "short term" settling time, and a separate "long term" settling time (????)

TI_DAC_Settling_Issue_083124.pdf

  • 0
    TI__Mastermind 42243 points

    Hello, 

    I've tried simulating this with our SPICE model and the OPA828, and I'm not seeing this same behavior. I also am not seeing the same overshoot you are seeing. 

    When you are doing large jumps are you always starting from either full-scale or zero-scale? 

    is CF219 populated? If so, what is the value? 

    Can you repeat these tests with the digital bus not always active? 

    Best,

    Katlynne Jones

  • 0 in reply to Katlynne Jones
    Intellectual 460 points

    Katlynne

    Thanks for your simulation work on this.

    CF219 is not populated. We actually placed a Schottky diode there to reduce the undershoot. The phenomenon we observe does not seem to care about the start and stop digital codes, just the difference. We tried with 0000 (zero scale) and FFFF (full scale) and a variety of values in between.

    We did also reprogram the FPGA to do the same jumps with the digital bus quiet except to write that single DAC - so the bus is now "quiet". No change in the analog behavior.

    Pat

  • 0 in reply to Avatar
    TI__Mastermind 42243 points

    Hi Pat, 

    This is most likely a measurement issue that comes along with measurements like settling time. 

    This article talks a bit about the issue on page 6 "Limiting Dynamic Range of Input Signals":

    Tools to Boost Oscilloscope Measurement Resolution to More than 11 Bit_48W_27802_4.pdf (tek.com)

    When you zoom in to 200mV/div on the scope, the scope is gaining up the input signal. The gained-up signal clips to the scope input amplifier power rails when you are making the large voltage output steps, and then what you are seeing is the overdrive recovery time of that amplifier. You can try zooming out so that the overshoot is all shown on the scope to prevent overdriving the amplifier, and then zoom in afterwards. You'll lose some resolution doing this, but hopefully you'll see an improvement with the settling time.

    Best,

    Katlynne Jones

  • 0
    Intellectual 460 points

    Katlynne

    You identified the problem. It is within our own digital oscilloscope! Thank you.

    Pat