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.

DAC8562: Unexpected propagation delay

Part Number: DAC8562

Hello,

I just came across an unexpected behavior of the mentioned DAC when using it in synchronous mode (see attached file). 

In the datasheet it is described as follows: "In synchronous mode, data update occurs with the falling edge of the 24th SCLK cycle". In my case, the data update leads to a 2us delay, on rising edges and an almost instantaneous response on falling edges.

Is this behavior desired? In the datasheet, I haven't found any additional info on the propagation delay. I'm currently setting up the DAC with 0x380001 and 0x200003.

The data is then sent with 0x18XXXX, where XXXX contains the data.

Additional tests have shown, that the delay appears to vary depending on the data:

0x0000->0x8000 takes 2us until a change in the output can be recognized

0x0001->0x8000 takes 2us until a change in the output can be recognized

0x0010->0x8000 takes 2us until a change in the output can be recognized

0x0100->0x8000 takes 1us until a change in the output can be recognized

  • Hi Leo, 

    It seems like the propagation delay you are witnessing is due to the output buffers of the DAC. Since the output buffer cannot swing all the way down to 0V, it is in an overdrive condition when outputting at or near 0V (which is essentially to say that it isn't acting as it would in its linear range because it has limited footroom to the negative rail). This results in an overload recovery time when the DAC is switched from near 0V to another value. You can see a similar effect in Figure 31 and Figure 33 of the datasheet when the DAC switches from 0h to FFFFh and from 4000h to C000h respectively. When the DAC switches from 0h to FFFFh there is about 2us of delay from the trigger to the output. Alternatively, when the DAC switches from 4000h to C000h the delay from the trigger to the output is nearly zero.

     

    Best, 

    Joshua Rossie

  • Thank you very much, this appears very likely to be the case. I really appreciate the link to figure 31& 33.