DAC82001: Output noise (0.1 - 10Hz) graph

Hello Katlynne-san,

Thanks for your comment.

Katlynne Jones said:

Our 0.1uVpp spec for flicker noise is promised by design. This is an unbuffered DAC, so the only noise in this device is due to the 6.25kΩ resistor string. The noise of the system will be dominated by the external output buffer chosen.

So why does the noise density plot show such high value especially at low frequency area? Is it measured with external output buffer?

Best regards,

Hi Sato-san, 

I asked the validation engineer and it seems like the noise density plot in the datasheet is pretty close to the noise floor of the scope used (PXI scope card). 

The DAC82001 output was connected directly to the scope input.

Best,

Katlynne 

Hello Katlynne-san,

Thanks for confirming with validation engineer.

So figure 6-21 represents not DAC82001 performance especially at low frequency area, and actual DAC82001 noise density plot should be flat behavior entire frequency area with 10nV/rtHz value, correct?

Also I have one more question.

Is DAC update timing a rising edge of /SYNC when sending LDAC in synchronous mode, which is same as the case of asynchronous mode?

Best regards,

Hi Sato-san, 

Let me check with the design team for your first question. 

For your second question, the LDAC is only used to update the DAC output in synchronous mode. In asynchronous mode the rising edge of /SYNC acts the same as the LDAC signal in synchronous mode. The LDAC pin is "don't care" in asynchronous mode. .

Best,

Katlynne Jones

Hello Katlynne-san,

Thanks for comment on noise density plot. I understand it should be flat with 10nV/rtHz. If with the information we can calculate 0.1uVpp from the noise density.
 

Thanks for comment on also software LDAC programming.

Katlynne Jones said:

For your second question, the LDAC is only used to update the DAC output in synchronous mode. In asynchronous mode the rising edge of /SYNC acts the same as the LDAC signal in synchronous mode. The LDAC pin is "don't care" in asynchronous mode.

I would like to know the timing of Vout update in case of sending LDAC=1 to trigger register in synchronous mode.

Is the update timing /SYNC rising edge? or immediately update soon after sending trigger register without waiting /SYNC rising edge?

Best regards,

Hello Katlynne-san,

Figure 6-16 and 6-17 show delay from /SYNC rising edge timing to DAC output transition timing. There is 200ns delay seem to exist.

Is the 200ns fixed delay time? or is the delay time may change depending on some conditions?

It would be appreciated if you have the delay time variation data.

Best regards,

Hi Sato-san, 

Are you working with Enhui Yang? They sent an email to Luis about this same question.

I believe Lucas was going to look into this. The delay could be an issue with the DAC coming out of the rail (ground) on codes starting from zero-scale. What output buffer is the customer using? I am going to assign this thread to him so he can share any updates. 

Best,

Katlynne 

Hello Katlynne-san,

I am supporting customers in Japan and don't work with Enhui Yang. If he/she asked same inquiry and your team already answered it it would be appreciated if you could forward it to me.

What I wanted to confirm is response time of DAC output starts to change, not settling time. or do you mean the response time will change from 200ns if it start with for example mid-scale code? 

Best regards,

Hi Sato-san,

The 200 ns delay after the rising edge of the SYNC signal appears to be relatively fixed due to the digital design of the DAC.

I've tested this with the EVM and always saw 200 ns with different ranges of output changes.

Thanks,
Lucas

Hello Lucas-san,

Thanks for confirmation. It would be nice if you could confirm the behavior with also design team because the information is important when considering sync with multiple devices.

Best regards,

Hi Sato-san,

I've reached out to the design team and will get back to you with more information.

Thanks,
Lucas

Hello Lucas-san,

Thanks for confirming this with the design team.

It would be also appreciated if you could confirm accuracy of the "200ns" with the team, in case the 200ns is fixed value.

It will help customer how to design sync timing in their system. 

Best regards,

Hi Sato-san,

I think Lucas is still waiting on a response. He will respond when he hears back. 

Best,

Katlynne 

Hi Sato-san,

It will take another day to get a definitive answer on the accuracy.

I will reach out to you when I know more.

Thanks,
Lucas

Hello Lucas-san,

Thanks for your support. I will wait for your feedback.

Best regards,