AD9545. Unstable phase lock.

HI,

the AD9545 configuration seems to me OK. I have found only one fundamental thing that is not right. In the system clock compensation, you set REFA(that is the OCXO) as the AuxDPLL source, and you set it correctly to compensate DPLL0 and TDCs. But then you set DPLL0 to compensate the TDCs as well. This is not right. You cannot use the DPLL0 to compensate its own TDCs. You could use DPLL0 to compensate for example DPLL1. But the normal way would be to set directly AuxDPLL to compensate DPLL1.  Bottom line is I recommend unchecking the Compensate TDCs in the DPLL Compensation Settings in the window below.

If I understand correctly, you are testing this on your board, not an AD9545 evaluation board. Please tell me if the AuxDPLL locks by reading register 0x3002, bit 1 (of course, read also bit 2 because this tells you if the AuxDPLL reference (that is the OCXO is faulty)).

The thing that confuses me about your video is that you compare a 38.4MHz clock (which I suppose is OUT0A) against another 38.4MHz clock that is not managed by the AD9545. Where does this 38.4MHz clock come from? You should verify the OUT0B=1Hz is phase aligned to REFAA=1Hz.

When you say the "phase lock is not stable", please tell me if DPLL0 states it is phase locked or not by reading bit 1 in the register 0x3100:

My expectation is that after my recommendation above related to the system clock compensation, the DPLL0 to stay phase locked.

Other things: please make sure REFAA=1Hz is also stable, generated from a very stable source. If the REFAA wonders in time and these wonders are greater than the 700 ps phase lock threshold you have on REFAA (default), then DPLL0 may go in and out of lock as well. And this means the OUT0B=1Hz may wonder as well. If your application allows, you may increase the phase lock threshold above 700ps.

I see you set the DPLL0 loop filter to the one with 88.5deg nominal phase margin. I suggest you select in the beginning the one with 70deg nominal phase margin. Then, after you settle on a configuration, you can then change it to use 88.5deg.

Petre

Petre, thank you for your quick response!

Yes, you are right, I'm working on my own board, not on the AD9545 Evaluation Board.

My project goal is to create a wireless synchronization system which I can then use to calculate the position with an accuracy of 10cm (so every 1ns (~30cm) sync inaccuracy is crucial).

Accordingly, the video showed the OUT0A outputs from two such boards based on the AD9545 chip receiving a PPS signal from the same Trimble Thunderbolt E GPS-receiver (http://trl.trimble.com/docushare/dsweb/Get/Document-383329/).

So, I changed the inaccuracy that you pointed out - I've unchecked compensation box in the DPLL Compensation Settings. Also changed the Phase Lock Threshold, drain and fill rates. But it had no effect.

Yes, with increased threshold, a phase lock occurs and never getting into unlocked state. But the oscilloscope still shows how the output signal floating away and back from RefAA input.

AuxDPLL getting locked immediately when the board is turned on (RefA appears); DPLL0 phase lock indicator switches several times from the lock state and back (in the process of Fast Acquisition, I assume) and then permanently locks (at a sufficiently large value of the phase lock threshold). I also changed the Loop Filter Configuration parameter Phase Margin to Filter0 (70deg nominal phase margin).

I have tried many configurations to monitor the operation of the DPLL0. For example, the configuration attached to this message, uses the 10 MHz OUT0A output, which is then compared to the 10 MHz Thunderbolt output on the oscilloscope.

I apply the waveforms of the output PPS from the GPS receiver and what comes to the AD9545 RefAA input after the usual voltage divider. 

Problem remains the same: the output signals (Out0A, Out0B) floats relative to the input signal (RefAA) and cannot stop at the some kind of one phase position.

I suppose there are several options of causing phase stability problem (assuming the use of precise (quartz resonator, OCXO) elements on the board and a high-quality PPS source) :

1) hardware board design mistakes that led to additional phase noise in circuit which interfere with achieving a stable phase output results;

2) mistakes in ACE configuration (which is unlikely, but maybe i should set exact phase lock threshold, drain, fill values);

3) in spite of accurate GPS-receiver maybe i'm using it wrong and AD9545 gets unstable 1Hz input (RefAA);

4) some my software shortages? (i simply performing initializing sequence and running in infinite empty "while (1)" cycle)

What do you think is causing such an unstable situation with the output signals and what information can I provide you to find out how to solve this problem?

-Dmitry

unstablePhaseLock(v.2).zip

Hi,

I looked over the photos you sent. The 1.5V high level of REFAA seems OK for a dc coupled 1.8V clock. You should also set the validation timer equal to 1s (now it is the default 10ms) , so the REFAA is nonfaulted for 1s before the monitor deems it valid.  If you want to see what the AD9545 reference monitor thinks about REFAA, set one of the Mx pins as an output (status function) with REFAA valid status shown. You then can monitor it with an oscilloscope and see if REFAA ever goes invalid.

The opinion here is your issue is caused by  the GPS reference quantization noise. Let me try to explain:

You see a wonder of a DPLL output relative to the reference (1Hz or 10 MHz coming from Trimble Thunderbolt). You trigger the scope on the reference and you see the output wondering around it. But you do not know how much the wonder is determined by the reference and how much wonder belongs to the output.

I suggest doing this experiment: Set both DPLL0 and DPLL1 to lock onto REFAA=1Hz in internal zero delay mode and generate OUT0A=OUT1A=10 MHz. Use system clock compensation from REFA=20MHz and make sure the AuxDPLL is locked, that is the system clock compensation is active and compensates the DPLLs and TDCs.

Observe on the oscilloscope REFAA, OUT0A, OUT1A. Trigger on OUT1A. 

Then force DPLL1  into holdover. OUT1A will continue to be generated based on the stability of the OCXO, becoming an "independent" output relative to REFAA and OUT0A. Then on the scope you can see and assess the wonder of REFAA and OUT0A relative to OUT1A.

My bet is the wonder (i.e. a frequency spur) comes from REFAA, triggered by the Trimble Thunderbolt quantization noise. This spur should have a frequency lower than 50 mHz, the bandwidth of DPLLs, and OUT0A then matches it. You can only reduce the wonder of the output if you reduce the DPLL bandwidth, for example to 25 mHz, basically hoping the wonder of the reference is above 25 mHz and gets filtered out by the DPLL. But if this wonder/spur changes frequency below the DPLL bandwidth, you will get it again at the output. 

One important note: lowering the DPLL bandwidth increases the stability requirement of the OCXO. So you may need to procure an even more stable OCXO.

Petre

Petre, thank you for your advices!

It seems I have fixed my problem and achieved phase fluctuations <1ns.

Unfortunately, in my board design there are no RefB, RefBB inputs and connections with DPLL1, so i can't conduct your experiment. But it is still interesting to know those frequency spurs details, that you described.

The cause of bad phase stability was the Loop Bandwidth parameter in the DPLL0 Loop Filter Configuration.

When applying a 1PPS signal to the DPLL0 input, it advises setting the Bandwidth to 50mHz, which I did.

Probably, in the process of making the configuration, I tried to change it, but I was given a strange error in the ACE environment (screenshot attached). As a result, I followed your advice and tried to change this parameter, but directly through the ACE interface. At a Bandwidth value of 25mHz, the phase fluctuations were even greater than at 50mHz. I tried setting the value to 100mHz and the accuracy of the phase fluctuations increased and reached 2ns.

From which I can conclude that the problem was not in the quality of the PPS signal from Thunderbolt, but in the accuracy of OCXO, which compensated for the system clock signal.

You wrote that the smaller the Bandwidth, the stricter the requirements for OCXO accuracy. Probably 20ppb is not enough for a Bandwidth of 50mHz, at least on my board in this configuration.

Anyway, the increase in bandwidth has had a fruitful effect on the phase stability of the output signal. I managed to achieve an accuracy of <1ns.

Now the behavior of the AD9545 looks like this: for the first 5 minutes, the output signal has strong phase shifts, and then for 1-2 minutes the signal is very precisely stabilized in phase (I've attached a photo of the first 5 minutes and a video of the phase-stable signal).

Perhaps this is not all with my board and there will be more questions, but in the problem of phase accuracy you helped me a lot!

Thank you!

-Dmitry

phaseStability1ns.zip

HI,

the problem with setting the DPLL0 loop bandwidth at 100mHz or even 200 mHz is that you violate the oversampling ratio of the 1Hz reference.

Please see this specifications table in the rev B data sheet, page 22. It is written that the frequency of the PFD (DPD in DPLL case) divided by the loop bandwidth must be greater than 20. For 1Hz DPD rate, this means 50 mHz max loop bandwidth. This is why ACE was giving you an error and not letting you to click Apply button in the Wizard.

You can violate this rule temporarily during the fast acquisition process, but not permanently as you set it now. The AD9545 functionality is not guaranteed.

I believe the system clock is not stable enough. Maybe the OCXO you use is not stable enough or the clock arriving at REFAP pin does not have a good slew rate. Looking at the OCXO data sheet, it seems to generate a 3.3V CMOS output. The AD9545 accepts at REFAP max 1.8V CMOS. The cso file you sent last time had it set to 1.2V CMOS. Do you have a resistor divider in the circuit to reduce the amplitude of the clock to 1.2V? 

Petre

Hello, Petre.

You are right, 200mHz does not meet the limits of a 1 Hz input signal.

I suppose, I will try to get decent results with a loop filter bandwidth of 50mHz. But I don't fully understand how such an accurate OCXO (20 ppb) can't be enough for a standard 1PPS task.

A voltage divider placed in between the OCXO output and the AD9545 input that reduces the signal amplitude to 1V.

I also heard about switching to Holdover mode for a while to make the necessary calculations. And then back to the adjustment mode. Maybe I can use it somehow and then I can work at 200mHz loop filter bandwidth?

-Dmitry

HI,

In the beginning, I thought your problems come from the GPS generator quantization noise. Because it is really an issue with the reference clock, the solution to reduce the DPLL loop  bandwidth may mitigate it some times, but there is no guarantee to eliminate it.

Then you found out that increasing the loop bandwidth reduced the jitter of the output. This made me think that maybe the reference is OK, but the system clock compensation is not enough and therefore I proposed to use a better OCXO to stabilize the system clock.

To debug this, you need a very stable 1Hz generator to use instead of the Thunderbolt. Then you can analyze the AD9545 output and the system clock compensation functionality.

Petre

HI,

In the beginning, I thought your problems come from the GPS generator quantization noise. Because it is really an issue with the reference clock, the solution to reduce the DPLL loop  bandwidth may mitigate it some times, but there is no guarantee to eliminate it.

Then you found out that increasing the loop bandwidth reduced the jitter of the output. This made me think that maybe the reference is OK, but the system clock compensation is not enough and therefore I proposed to use a better OCXO to stabilize the system clock.

To debug this, you need a very stable 1Hz generator to use instead of the Thunderbolt. Then you can analyze the AD9545 output and the system clock compensation functionality.

Petre