Changing the ADF410X output channel without a glitch?

Document created by Brigid.Duggan Employee on Dec 8, 2014
Version 1Show Document
  • View in full screen mode

Question: During frequency sweeps, the PLL control voltage changes in a nice small signal manner,   occasionally, something happens,  and the control voltage goes to the positive rail for awhile, then settles at the correct Vtune.  Can you explain the reason for this glitch and how to avoid it ? 

When changing channels using the ADF410X parts, in standard LO applications, a write to the N counter in sufficient to change the o/p frequency. This part has been used very successfully for many years in this type of application.

More recently, the ADF410X family of parts has been designed in instrumentation applications, to generate a frequency sweep/ ramp generation, where very consistent short settling time on the V tune o/p is required. These customers have reported that occasionally during the ramp, the Vtune o/p shows a larger than normal glitch, resulting in longer settling time for certain frequency steps.

This is a known issue on our older generation of PLL devices, which can be caused by either of the following scenarios.

  1. if the internal  counters  update  before the digital logic associated with the SPI bus has settled to its correct value ( when changing channels ), incorrect data is loaded into the  counters, but  is re-loaded with correct data on next update of counters. Also explained as :”
  2. If the R counter has timed out to zero when the new contents are latched using LE then there is no R count for a brief period, and the PFD will think the feedback frequency is too high, and force CP down, (this looks to be happening). With VCXO’s this can be bad as if they rail it can take a long time for them to recover.

…hence the glitch on V tune.

The internal counters update on the falling edge of REFIN, so if you load new data from the SPI bus synchronized with the rising edge of REFIN, this will allow the digital logic a full half cycle of REFIN to settle before the next internal counter update.

The recommended workaround for this issue, is to externally synchronize the rising edge of REFIN with the falling edge of LE, this will allow enough time for the digital logic to settle before the internal update of the counters takes place, and so avoid incorrect counter re-load.


A simple flip-flop will do the job, ensuring that the LE pulse is gated by the rising edge of REFIN, meaning the timing delta between the two is always the same.


In addition to ensure repeatable lock time a counter reset before the counters are loaded and released after they are loaded is required.

This longer than expected settling time is very much application specific as it depends on the PFD used and the R divider value, and of course the settling time required following a channel change.