AD4020 eval board external supply

Hi Mohan,

I'm not sure if this is the cause of the erroneous AD4020 output codes, but you actually want to change SL1 and SL2 to "B" to use external +VS and -VS. SL8 and SL9 are only for the optional external amplifier mezzanine card power supplies.

Table 2 in UG-1042 (Rev. I) gives a list of the link positions for using external supplies. (SL5 and SL6 are only relevant when using J4 to supply +/-VS.)

Try making those modifications and let me know if the problem persists.

Thanks,

Tyler

Thanks a lot :) Will make these modifications and let you know. I'll switch SL1 and SL2 and put back SL9 and SL8 in it's original place. For Vdd and Vref the jumper changes are to made in SL7 and LK2 itself right?

Thanks a lot :) Will make these modifications and let you know. I'll switch SL1 and SL2 and put back SL9 and SL8 in it's original place. For Vdd and Vref the jumper changes are to made in SL7 and LK2 itself right?

Sure thing. Yes, SL7 is for external VDD and LK2 is for external VREF.

Hi, I changed SL1 and SL2 instead of SL8 and SL9. It is still doing the same thing. Any idea why?

How much do you think the fact that I am not using the recommended ICs for power supplies is hurting? Right now, I am giving 5V, 1.8V and 3.3V from the beaglebone. -5V is coming from LMC7660. 

1.8V was a ADC reference voltage on the beaglebone for the inbuilt ADC. I thought it might not be able to supply enough current to run the ADC. So I used an external supply to see if that was the issue. But it still did not fix the issue. I probed the nearest accessible points of the ICs to see if all the voltages were reaching it. It was fine, all the voltages were indeed reaching the IC.

Hi Moran,

I think the problem is that your +VS and VREF voltages are both +5V. The reference buffer (U16) is powered off the +VS supply, and it needs some amount of headroom to ensure that it's output voltage can actually reach +5V.

In addition, if you are driving the ADC driver amplifiers (U12 and U14) with the VCM voltage from the "common mode amplifier" (U18), then the VCM voltages probably also aren't being generated properly, and the AD4020 inputs likely aren't being driven to their specified common mode input voltage. This issue can certainly manifest in the error modes you're seeing.

I'd suggest in the short term at least to drive +VS with a larger voltage (without violating the supply range specs of any of the amplifiers, etc. on the board). The reference buffer and common mode amplifier are both ADA4807-1s, which have max supply voltage ranges of 11 V. So you'll need to limit +VS to +6V when using -VS = -5V. If that doesn't work, then you can try using a smaller VREF for debug purposes and see if that fixes the problem.

Let me know how that goes.

Hi schmitt,

I checked the Vocm voltage. It seemed to be close to 2.5V. But what you said makes sense. I will try both your suggestions tomorrow and let you know how it goes.

Regards

Mohan Prabhakar

I tried both your suggestions, the problem still persisted. First I powered Vs with 6V. Nothing changed. While keeping 6V as Vs I changed Vref to 3.3V. Still, the same problem persisted. So I started probing the SPI signals to see if everything was fine. That's when I realized SCK was not working as expected.

In the above image, yellow waveform is the CNV pin and blue waveform is the SCK pin. The SCK pin is supposed to be toggling 20 times inbetween two CNVs but it's toggling only once. However, when I zoomed into the SCK signal I noticed that there are 20 peaks as shown below.

I have no idea why this is happening. Do you think while changing the ADC, the track got damaged? I had to heat the IC a lot to get it out since it was glued to the PCB. What could be the possible explanations for this?

I thought the fact that I am using a not so short probe to measure the SCK signal might degrade the signal, but if that was the case, then without probing those pins, I should have been getting proper outputs. But that's not happening. So I am not sure about why this is happening. Any ideas?

Hi Moran,

Thanks for letting me know, and hopefully we'll get to the bottom of this for you soon.

It's possible that your scope images of the SCK signal might be appear worse than they are due to the probes you are using, but it's hard to say... So let's not rule out a problem with the digital yet, but I want to double check it's not the power supplies or analog first.

Can you clarify exactly on which node you were measuring the VCM voltage? If U18, R48 and R49 are in their default configurations, then the node labeled "VCM" would be equal to VREF (i.e. +5V in your case).

Can you also clarify the configuration of the analog inputs + ADC driver amplifiers? For example, are the ADA4807-2s or the ADA4940-1 driving the AD4020? And are the associated passive components around those amplifiers the factory defaults, or were they modified? For example, are R27, R28, R34 and R35 all populated with 590ohm resistors?

I forgot to ask whether the common mode voltage on the AD4020 inputs (IN+ and IN-) is definitely VREF/2 volts while you're doing these measurements? The error mode you're seeing is consistent with the common mode input range spec being violated. So I'd suggest hooking up the signal source you are using but don't turn on the 40kHz signal, and just measure the voltages on the IN+ and IN- test points to make sure they are sitting at VREF/2 volts.

Hope those questions/suggestions get us closer to having everything working.

-Tyler

Hi Tyler,

I measured the VCM voltage at one end of R28 where it was 5V and also at the junction of R28 and R27 where it was 2.5V.

The AD4807-1s are driving the AD4020. Yes, all the passive components are in their factory defaults. The only modifications made to the board were the links related to external power.

Yes, the common mode voltage was definitely Vref/2 (2.5V in my case) at the input of AD4020. Yes, I did do it before and it was sitting close to 2.5V.

Also, I had ordered one more AD4020 eval board recently. Without making any changes I just put it to the FPGA board and tried to do a capture. The  exact same thing ended up happening. It was following the frequency but not capturing the waveform. And this eval board was brand new with 0 changes made to it. So I am inclined to believe it is the SCK issue. What is your opinion?

Regards,

Mohan Prabhakar 

Hi Moran,

Thanks for your patience as we continue to try to solve this.

I think this is my last "analog" question - does the code output issue occur only when your signal generator is connected to the EVAL-AD4020FMCZ inputs (i.e. the J7/J11 SMA connecotrs)? Or does it happen even when J7/J11 are not connected to anything? In the EVAL-AD4020FMCZ default configuration, if J7/J11 are not connected to any external source, then the AD4020 inputs will just be driven to VREF/2, and it should return a mean code of close to 0.

The reason I ask is that it's possible that depending on the output stage of your signal generator, it's possible that the ADA4807-1 inputs are getting dragged down to ground or some other voltage when it's connected. I know you said you verified the AD4020 IN+/IN- inputs are at 2.5V already but I just want to double check that this isn't the problem before we start debugging on the digital side.

In the meantime, you could also probe the SDO output of the AD4020 to see if it really is outputting the codes you're seeing in the eval software, or if there's some issue with the FPGA board as you suggested. I recommend probing CNV, SCK, and SDO and seeing what the state of SDO is on each SCK falling edge to see if the results displayed in the eval software match reality.

Hi taylor,

When the signal generator is not connected to the eval board, I typically see the output code to be 0. But before this whole issue started showing up, I would see a noise worth 60-70 codes around 0. However, after this issue, I just see a straight line of code 0.

I tried even that. The SDO is definitely toggling the way it's supposed to. But since the clock is not triggering properly (i.e, instead of 20 pulses, it's kind of showing up as one big pulse) we are getting an ENOB of 2 (0 and -500000). Hence, the output is following the frequency but not able to capture the wave. This was my conclusion after probing the SPI pins. Does this make sense?