about ADF4002 programming

We are having a trouble with ADF4002. In some cases, we don't succeed in the programming of the chip until a while in which temperature raises a bit. the failure depends on temperature, and appears only in relatively cold conditions.

We drive the ADF4002 reference input with a 10 MHz signal from a ultraestable external source using comparator ADCMP602 to remove level uncertainty and improve rise/fall times for low frequency as recommended. We use this latter device in a straighforward mode, without hysteresis. The simple ADCMP602 10 MHz output (3.3V) is drove DC coupled directly to ADF4002.

ADCMP602 input is depending on context a 50 ohm, 0 to +6 dBm sinusoidal 10 MHz signal.

ADF4002 is programmed to lock a 70 MHz VCXO which is feed at RF input with 0.6Vpp level and who receives the control voltage (0 to 3.3V from the 4002 CP out via a filter designed with Adi SYM PLL 3.5.

Searching for the cause of the problem we have measured lots of things, in particular i want remark a doubt. We have observed that the duty cycle of the ADCMP620 output (which is the ref for ADF4002) depends strongly and a bit randomly on temperature, and it is never too close to 50%. It is usually about 45% at room temperature and in one case it goes up with temperature, while in other tested board it goes down. At very cold temperatures one of the chips reaches 75% duty cycle. We checked that the unused input bias Vn moves quickly with temperarure. As I told we use no hysteresis or use the default (no external hysteresis resistor). Anyway we have forced with temperature duty ctcle changes and it does not affect directly, because once programmed, the PLL remains estable. The ref input diagram detail in 4002 data sheet also give impression that duty cycle is not relevant, assuming the input FF's obbey only to rise flange.

We can send electric diagrams, logic control data and even chronograms if convenient. Comparator Vp and Vn inputs are AC coupled with 100nF after 50 ohm terminations for the external source and to ground respectively. Comparator Q output is tied directly to ADF4002 REFin. The 70 MHz square 3.3V output signal is drove in AC to ADF4002 and output filter using a impedance converter. We reduce the ADF4002 RF input level from 3.3 to 0.6Vpp for compatibility with the previous ADF4001 that has a maximum rating for this port and in fact it was damaged if greater RF level is applied (a warning that anyway does nt appear in 4002 data sheet). So ADF4002 RFinA receives a signal coming from a 70 MHz 135 ohm equivalent source, AC coupled through a 10nF capacitor. RFinB is to AC groud via another 10nF capacitor.

The PLL is supplied with independent 3.3V regulators for AVDD and DVDD, using identical chokes to separate VDDs and grounds. It is programmed usign ADYSIM PLL parameters with 5K1 Rset, 2.5mA ICP, R=1, N=7, 2.9ns antibackslash, 1.5KHz 66deg, passive filter. The control interface includes a 2245 transceiver to control this chips and other sharing the data bus, but using tristate to clean the buses when the devices are already programmed, and separated chip selects. In particular ADF4002 bursts are activated with a individual chip select to LE input, then programming the device using the initialization latch system (the same problem appeared testing with the counter reset method)sending 4 bursts for initialization (no counter reset as specified), function, R and N. CE pin is tied to digital VDD with 6.8Kohm.

In fact we hace used ADF4001 and ADF4002 in several identical or very similar circuits without troubles. Apart from the duty cycle issue, my only other suspect is directed to the possible ADF4002 HF sensitivity, because there are some other medium-signal higher frequency RF sources in the board, since this circuit is a subsystem that serves the 70 MHz reference to an UHF upconverter with onboard synthesised LO, so another 70 MHz signal lives in the board, which main device is AD9956 DDS/PLL.

Your help would be very much appreciated, and I can send details depending on the suspects of the reason of our problem.

Thanks in advance

J. Martin

  • I can add, for those interested, but still waiting a expert reply, that we have apparently solved the issue by changing slightly the control timing. In fact the timing diagram is a bit unclear, for example it fixes a time from clock fall flange to latch enable that we respect, even if it looks as if the active clock flange is the rise one. But anyway, we have removed the errors by avoiding that the data are cleared to 0 at the same time that the clock falls. I guess it is not a logical reason but a physical one, for the transmission has several cm and one can suspect, and we have confirmed by checking, that there are small 10ns-time scale overshoots / reflections that increase with temperature, eventually giving spurious data readings or clock transitions. So it is more secure to avoid data transitions in coincidence with clock transitions, even in the clock down transition and even if it seems that at least for the data read the important clock transtion is the rise one. As far as the latch enable is concerned, the false transitions have to be totally avoided. I don't know the exact reason, but in our board, only the data line presents small reflections overshoots with temperature, even if the 3 control lines are very similar.

  • 0
    •  Analog Employees 
    on Feb 9, 2012 12:52 PM

    Good to hear the problem has been solved.

    To debug programming issues, we request that users exercise MUXOUT modes to Vdd and GND, which do not depennd on any other portions of the circuit but the supply pins and GND.