AD9542 output stability

HI,

you should have used the Clock and Timing forum because, in the end, the question is about the AD9542.

I looked at the cso file. I see that both DPLLs do not have any profile enabled, although there is a REFB=10MHz reference clock enabled. Note that on the AD9542 eval board, REFB channel is dc coupled and you set it in the configuration as differential ac coupled. So this is not going to work if you use the AD9542 eval board.

I also see the system clock source is a 100MHz clock coming presumably from a 100MHz oscillator.

So basically the AD9542 DPLLs are in free run and so the output frequencies are as stable and accurate as the 100MHz clock creating the system clock.

So when you tell me that the PLL using the OUT0B=100MHz clock as reference has an output that wonders and then the PLL goes unlock, I believe the reason is the 100MHz clock you use as the AD9542 system clock source is not accurate and stable enough.

You see this effect on the 28.75GHz clock because the PLL amplifies the errors of the AD9542 OUT0B.

Please tell me more about the 100MHz clock you use to create the AD9542 system clock and why you did not use the 52MHz crystal resonator the AD9542 eval board already has.

Do you really want to use the AD9542 simply as an oscillator? Why then not applying directly the 100MHz  oscillator clock to your GHz PLL instead at the XOA/XOB pins of the AD9542..

Petre

Hi Petre, 

Thank you very much for your response. 

Once I wrote the post, I tried to change the location but it seems that I cannot. 

The main purpose for using the AD9542 using is to have the same output signal although reference was disconnected at any time. Once system is locked to an external reference, if that reference disappears, output signal must remains exactly in the same frequency. That's why we use AD9542.

Our 100 MHz clock is an OCXO with quite well stability (+/-30ppb).

This morning, I changed Profile and REFB configurations. New configuration is showed in the next figures:

Now, the ACE shows the next diagram:

As you can see in the capture above, DPD is now in red (?)

I attached the new cso in a zip:

test_ref_20231031_100MHZ.zip

With this configuration, and the system working about 8 hours, the output have the next appearance: 

Regarding the MAXHOLD (blue), it's clear that the output is still moving. 

Ca we change any additional configuration or perform any other tests to get a solution for this issue?

Thank you very much. 

David

Hi,

1) you talk about the AD9542, but the cso file is developed as the chip is AD9545 and because the ACE GUI photo shows the system clock and analog PLLs locked, it seems to me you have have an AD9545 eval board. Or maybe you have an AD9542 eval board and you changed the USB EEPROM to make the board be seen by the PC as an AD9545 one. This is OK.

2) we recommend always using the Configuration Wizard to configure the chip whenever a feature touched by the wizard needs to be modified. From the photo and cso file you sent, it seems you changed REFB settings in the Wizard, but enabled the Profile 0 of DPLL0 and set it to work from REFB in the GUI. You should have enabled them from the Wizard. Therefore, because I do not know what else you changed, I built from scratch a cso file that does exactly what you wanted on DPLL0. I tested it on the eval board. I compared it against yours and there were some important differences in setting the DPLL0, because, I believe this change in the GUI instead of the wizard. Try to use this one instead and build on this one after.

AD9545_setup.cso.txt 

I do believe that instead of measuring the 28.75GHz clock you should measure the AD9545 output OUT0B=100MHz and see what the variation is. Then monitor the OCXO=100MHz you use and you should see these variations match.

Petre

Hi Petre,

Thank you very much. I'm going to review all the topics you mention.

Our board es a AD9542 EVAL since the chip is a AD9542, but the board silk screen shows AD9545 EVAL. I supose both evaluation boards share the circuitry and only changes the core chip.

One doubt about your cso file. REFB input is 100 MHz and, actually, we use a 10 MHz reference. Maybe, 10 MHz could generate any issue?

David

HI,

I am surprised that you have an AD9542 board and in ACE you use the AD9545 plugin. Usually, ACE does not communicate from within AD9545 plugin with an AD9542. You have two choices:

- develop the AD9542 configuration using the AD9542 plugin

- or reprogram the USB EEPROM of the AD9542 board with an AD9545 code.  I do not recommend to do this, but I talk about it as an option. See this issue for the USB programmer:  RE: AD9544 Outputs stopped working. 

I'm sorry for the error with REFB. I changed the cso file to have REFB=10MHz. I attach the new cso file. From the perspective of monitoring OUT0B=100MHz stability in time while DPLL0 is in freerun, REFB setting should not matter. But it matters in your application when you regularly will apply REFB=10MHz.

AD9545_setup2.cso.txt

Petre

HI,

I am surprised that you have an AD9542 board and in ACE you use the AD9545 plugin. Usually, ACE does not communicate from within AD9545 plugin with an AD9542. You have two choices:

- develop the AD9542 configuration using the AD9542 plugin

- or reprogram the USB EEPROM of the AD9542 board with an AD9545 code.  I do not recommend to do this, but I talk about it as an option. See this issue for the USB programmer:  RE: AD9544 Outputs stopped working. 

I'm sorry for the error with REFB. I changed the cso file to have REFB=10MHz. I attach the new cso file. From the perspective of monitoring OUT0B=100MHz stability in time while DPLL0 is in freerun, REFB setting should not matter. But it matters in your application when you regularly will apply REFB=10MHz.

AD9545_setup2.cso.txt

Petre