DAC7611: output is wrong

Hi Yuan,

How is the output wrong? Is it not updating at all or are you seeing an incorrect value as intended? The data is latched on the rising edge of CLK, is that what you are intending?

Are you using chip select?

Thanks,

Paul

1.the value is wrong,for example,the input data is 7D0，but DAC7611 output 765mV. the wave picture is  that  yuan attached.

2.we set cs pin low.

I have tried to some datas， they are wrong,001(1mV),002(11mV),004(47mV),008(190),010(765mV),020(3064mV),040(0mV),0080(0mV),100(0mV),200(0mV),400(0mV),800(0mV),030(3831mV),038(4022mV),03C(4070mV),03E(4082mV),03F(4086mV)

please refer to the sch

what is the rising time of clk?

here is the clk waveform from customer.

do you think it's correct?

thanks.

waiting for your reply.

That transition is acceptable, assuming the data is valid during the transition.  100kΩ on the input pins is a bit high, as our IIL and IIH specification is 10µA max.  Can you also verify if your isolation stage is inverting your data? Also, please verify the voltage on VDD is correct.  What does LD look like after the data is written?

Thanks,

Paul

Hi Paul,

Thanks for your reply. To make the question more clear, here I have a summary:

customer use the SCH as I attached before with those changes: change optocoupler to HCPL-181-060E; remove 100k resistors.

and he tested with different up-load resistor of optocoupler's output. (shown as R81 in SCH) here is the results:

1 R81=2K, it works

2 R81=5.6K, it cannot work.

customer compared two clk waveforms, he found the gap between two trising is around 15us.

so here is the questions:

1 Is clk rising/falling time the real reason for the two different results?

2 if yes, how clk influence? what's the definition and  recommeded range for this spec?

for definition, we feel confused with the description as below, here seems a conflict between "10%~90% of +5V" and "1.6V",

and for recommended range, I don't find words from datasheet.

3 do you know the reason behind that? why rising/falling time influence that?

paul, the first 2 questions are more important, customer want to confirm that, and for 3, if you know the answer, it's nice.

thank you again.

Yuan

Hi Yuan,

1. I do think the rise and fall time alone is the problem, but rather that the edge timing is causing the data to be misformatted.  The isolator's datasheet shows that the tRISE and tFALL time for ~5kΩ is ~100µs.  I am concerned that the data as shown in the first image is not valid with those edge transitions.  Please collect another image, similar to the one below but measured directly at the DAC pins.

Thanks,

Paul

"I am concerned that the data as shown in the first image is not valid with those edge transitions."

reply: I'm sure the data is valid with those edge transitions,because the data is Stable ,"0"(0V)or “1”(5V) ,when the clk changed from 0 to 1 and  the data keep enough time accordind with the datasheet .

"Please collect another image, similar to the one below but measured directly at the DAC pins."

reply:The waves of you see all the pictures are measured directly at the DAC pins.

1R81=5.6K, it cannot work. the dats as below:

0V-5V    tr=41uS，

LD: tLD1=135uS＞15nS

tLD2=208uS＞10nS

SDI:tCl=129.8uS＞30nS   tCH=209uS＞30nS

tDS=129.8uS＞15nS   tDH=209uS＞15nS

2 R81=2K, it works the dats as below:

0V-5.0V    tr=19uS

LD: tLD1=126uS＞15nS

tLD2=221uS＞10nS

SDI:tCl=113.0uS＞30nS   tCH=227uS＞30nS

tDS=113.0uS＞15nS   tDH=227uS＞15nS.

Hi Paul,

For your questions, you can refer to user6258159 's reply. he is the customer I mentioned.

I will give you more waveforms.

R81=5.6k，R87=0R，DACoutput=00000000111111, but voltage level is 4.0125V which should be 63mV，It's wrong.

yellow: clk; green: data; blue: Id; red: dacout;

cs connected to GND, test directly at DAC7611's pin.

next picture is zoom out picture for:

CLK rising:

data change(0 to 1):

after data transfer, Id:

let me whether it clear or not, and looking forward to your reply. thanks.

Hi Yuan,

*** EDITED to remove my false assumption that the data was LSB first. ***

I do not want this post to confuse customers in the in the future who find this thread.

Thanks,

Paul

"0b000000111111 should not be 63mV"

rely:we have tried “0b000000111111” was 63mV,when R81=2K. "The data format is Straight Binary and is
loaded MSB-first into the shift registers." It means we should transmit "0" at 1st clk，“0” at 2nd clk ，“0” at 3rd clk, “0” at 4th clk，，，，，you can see Yuan's pictures.

Hi,

Something to consider is that there are critical digital input voltages that result in the DAC7611 drawing more current.

My suspicion is that the slower ramp rates when using 5.6kΩ resistors result in the VREG output of the XTR116 to collapse or drop enough that the VIH and VIL levels change momentarily, this could cause the device to latch the incorrect data, or potentially reset the part during the transmission.  

Note the current sourcing capability of the VREG output is pretty limited. With a typical short circuit current of 12mA.  This plot in the XTR datasheet shows the VREG output drop with just a few mA of current. 

Using 2kΩ means that the time period where the current is high is shorter, so the supply might not be collapsing enough to cause a problem.  There is a balance that must be found as the 2kΩ resistors also take from the total current budget.

I suggest two experiments:

1. Monitor the VREG output during the communication with both 2kΩ and 5.6kΩ.  This will give us an idea of how much the supply has collapsed.

2. Try sourcing VDD externally. If the supply is approximately the same voltage as VREG, then they can even be connected in parallel.  If communication using the 5.6kΩ works with an external supply, then we have high confidence that the supply drop is the problem.

Thanks,

Paul

Hi Paul,

Thanks for your reply.

customer check their power supply(external LDO). power ability is good. and all the test above is without XTR116U.

could you please recurrence the situation on demo? thanks.

Yuan

Hi Yuan,

I have not been able to reproduce this.  I suspect that the very slow edges are causing this high-current state and that is causing a reset.  Are you able to use the lower resistance values in the application? If that impacts the current budget too much, could they implement a simple digital buffer to remove the slow edges from the DAC?

Thanks,

Paul