AD9546 Clock Correction with 1PPS

Hi,

you should have already found this through my EZ answers: we do not recommend creating the system clock using a OCXO or TCXO. Let me explain: for best phase noise performance of the outputs, we recommend using the 52 MHz crystal resonator to create the system clock. The crystal resonator is used in conjunction with the maintaining amplifier that guarantees the output clock from the amplifier has 50% duty cycle. This allows us to enable the doubler and this further lowers the phase noise. My bet is the OCXO has a 45% to 55% duty cycle specification and this impedes using the doubler. 

Then, because you want to lock onto 1Hz, you can apply the OCXO to one of the reference inputs or Mx pins (in CMOS mode with VDDIOA level) and lock the AuxDPLL onto it with 50Hz loop bandwidth. Then you compensate DPLLs, AuxNCOs and TDCs. This will ensure that the DPLL locks onto 1Hz and that when the DPLL enters freerun or holdover, the outputs will be as accurate as the OCXO.

Returning to your approach:

- the OCXO schematic to XOA is OK. Just verify the signal at the XOA pin is at least 0.9V high level, to match the specification.

"To use an external PPS signal as a reference: R304: 49.9Ω, R305: 0Ω."

I disagree. The CMOS clock cannot support 50 ohm load, so I recommend taking out R304.

" I also connected the 1PPS output of a u-blox EVK-F9T to J304 (REFBB) to be my PPS source."

Verify the u-blox module does not have a quantization error. If it does, I recommend starting this learning of the AD9546 using a rubidium/cesium generator or a different GPS module. The quantization error is seen by the DPLL as a low frequency spur within the 50mHz loop bandwidth and therefore the DPLL will try to replicate it at the outputs. Because you will trigger on u-blox 1Hz on the scope, you'll see the 1Hz output jumping around and will blame the AD9546. The DPLL may go in and out of lock as well.

"1. My specific question: do you know why the DPLL fails to lock in my tests?"

Send me the json file you use, so I can take a look. It may be that 50ohm load on 1 PPS degrades the signal arriving at the TDC, even if the REFBB status is valid. It may be the u-blox.

"My more general question: the AD9546 GUI is quite complicated, so I don't feel confident that I set up everything correctly. Do you know of a procedure that can be used to diagnose clocking failures like this one and fix them? Is there a document that guides the user through setting up clocking configurations that goes into more detail than the AD9546 eval board user's guide?"

The software is complicated because the AD9546 is complicated. As I said, send me the json file, tell me if you want to pursue the system clock created by the OCXO or not and I'll see if there is anything that could be improved. I do not have any other documentation.

Petre

Hi Petre,

Thank you for your detailed response, I appreciate it.

Your explanation of why using the onboard 52 MHz crystal is preferred makes sense. You are correct, our OCXO has a 45-55% duty cycle spec. However, we've already fabricated a set of hardware that has the OCXOs onboard, so we'll need to use the OCXO for our system clock source, if possible.

I verified that our OCXO input to XOA is 900mV high.

Understood on the REFBB input. I removed the 49.9Ω resistor.

I searched through the u-blox EVK-F9T documentation and couldn't find a mention of quantization. However, I can tell you that the EVK-F9T timing module's "Accuracy of the time pulse signal" spec is 5ns, and its "Time pulse jitter" spec is ±4ns. I'm hoping this u-blox GPS will be suitable for our testing. In case it's not, do you have a model number of a GPS unit that's verified to work as a PPS source for the AD9546?

I attached my JSON configuration file. Please provide any feedback that you have.

Thanks,

Cam

AD9546_eval_pps_attempt2.json.txt

HI,

I looked at the documentation u-blox has for the module you indicate and indeed, I do not see any reference to an eventual quantization error. The entry "accuracy of the time pulse signal" does not have any reference to an eventual compensation, so this module should be OK to work with.

You can use the OCXO=60MHz as the system clock PLL reference, just make sure the doubler is disabled. This seems to be the case in your json file, so you should be good here as well.

In the configuration wizard, I see:

- REFBB=1Hz, 1.8V CMOS. This is OK with the updated REFBB schematic.

-DPLL0 is set OK

- I do not see AuxNCO0 being set in the Wizard, but I see it set to 50kHz and embedded 1 Hz in the GUI. This is not good as I am not sure you set all the related registers correctly. 

In the GUI, I see:

- system clock compensation set using AuxDPLL with REFA as reference. But REFA is not defined anymore and now you do not need any system clock compensation because the system clock is created using the OCXO. So the system clock is as stable and accurate as the OCXO, so there is not need to compensate its influence through AuxDPLL. So please uncheck the TDCs and DPLL0 targets.

- REFBB related lock detector settings are at default, but this is acceptable. Decide if 700 ps on the phase lock threshold is the right threshold for your application (basically the difference between REFBB and OUT0A at DPD level). I recommend in the beginning increasing it to 2000 ps, just to get to see the DPLL being locked faster. Then the fill rates are at 10, which means that the locking mechanism that uses the bathtub approach will fill from -2048 to +1024 (lock level) in 300 seconds. I recommend increasing it to 100 for the beginning, so you can reduce the time to around 30s.

- the history is set to average only for 10ms the tuning words, which is too small for the DPLL that functions only every 1 second. I understand you want the history to be calculated after the DPLL has locked, but you need to see how many seconds to average to create a good tuning word when the DPLL enters holdover.

- in DPLL0, Dist0 settings window, the Auto-sync mode is disabled, which means the controller gives the order when to enable the outputs. I usually set this to Immediate, so I get outputs right after the AD9546 was configured and all APLLs locked.  When you get more experience locking the DPLL0, you may also check the Reference Sync box, which will make the DPLL0 to lock fastest right after power up. See page 112, Reference Synchronization section in the data sheet. 

So this json file should have work as my comments do not seem to tough on fundamental things. What results did you get?

Petre