10 MHz from signal generator differs from GPSLDO

[Moriambar]

Hi, I have a GPSLDO, an arb gen (SDG1032X) and a scope (SDS1104X-E).
I have one of the distribution box output hooked up directly to the scope, showing a steady 10MHz waveform (I'm doing this after 45 minutes of uptime, so I got gps lock AND alm off).
One other output of the distro box is hooked it to the Aux In of the SDG1032 set to have an external clock reference.
Then I set the arb to generate a 10MHz Sine and hook it up to the scope, which is triggered on the GPSLDO 10MHz.
What I see is that the arb sine seems to move relative to the other one, towards the right of the screen. Why does it do that? I thought that perhaps adjusting the "phase" parameter it could magically fix the thing (if anything has to be fixed) but nothing changes at all…

Can you please explain a bit more what is happening, please?

cheers!

[rfclown]

The 10 MHz from the "distribution box output" should be connected to the "10 MHz In/Out" connector on the rear of the arb, and the arb configured for external 10 MHz In.

I looked up the arb manual to see if it had a 10 MHz in. Read the manual. 

[Moriambar]

The 10 MHz from the "distribution box output" should be connected to the "10 MHz In/Out" connector on the rear of the arb, and the arb configured for external 10 MHz In.

I looked up the arb manual to see if it had a 10 MHz in. Read the manual. 

Sorry, My bad, I misspoke. That's where I hooked it up (the 10MHz in/out). As I said I set the arb for 10MHz external source.
So the connection is correct but the problem is still there

[radiolistener]

What I see is that the arb sine seems to move relative to the other one, towards the right of the screen. Why does it do that?

I thought that perhaps adjusting the "phase" parameter it could magically fix the thing (if anything has to be fixed) but nothing changes at all…

if they are moving, then your GPSDO and signal generator generator are clocked from different oscillators. They are asynchronous.

I'm not sure how external reference works for SDG1032, but I guess that it uses external reference period just to tune it's own oscillator frequency. It is very easy to implement in FPGA - just divide oscillator and ext ref to the same frequency, XOR them and then filter to get tuning voltage for VCO pin of it's own oscillator. If it works in such way, it still use it's own oscillator as a clock, so it will be asynchronous to the ext reference clock.

[Joel_Dunsmore]

often test instruments internal ref oscillators are phase-locked to the external input thru a analog phase detector (puts out a voltage for a given phase).  usually this is set to some small offset like 45 degrees to produce a small DC which goes into an op-amp used as an integrator. The other input is sets the offset voltage to set the offset-lock angle.   But, all these elements are subject to drift, temperature changes and aging and so you might find the phase of the 10 MHz output wanders relative to the 10 MHz input signal, but the integrated frequency error will be zero. The phase lock give zero frequency error but NOT zero phase error.

[TurboTom]

Depending on the frequency the phase comparator works at, there may be some initial drift that will stabilize within milliseconds to seconds. But after that, despite some minor jitter (phase noise), the phase should stay locked. For all practical reasoning, the generator's reference frequency can be considered synchronous to the externally supplied one in this condition.
A "walk-through" of the two frequency signals isn't acceptable. Did you enter the output frequency on the AWG with the encoder or typed in as a decimal value? Sometimes, this may make a (tiny) difference. The AWG shoud indicate on the screen that it's using the external clock. Also, you may want to verify that you're using the latest firmware.

[Anthocyanina]

Hi! do you have a frequency counter? when a signal moves relative to another it means their frequencies are not exactly the same, close but not exactly. When they are the exact same frequency, they both look static on the oscilloscope, but there may be some phase shift. In this short video you see 3 signals, channel 2 and 3 are at the same frequency exactly. but there is a slight phase shift, yet both are "locked" to each other, and channel one has a slightly lower frequency. so when triggering on channel one, we see the channel 2 and 3 signals move around, but when triggering on channel 2, we can see channel 2 and 3 are locked and we can see the phase difference between them, and only the channel one signal is moving, wich is why in these captures sometimes we can see channel one's edge and sometimes not.

https://youtu.be/omTYe5WgHVw

(edited the post to attach the other captures since it wouldn't let me post them when i first made this post)

[tautech]

Depending on the frequency the phase comparator works at, there may be some initial drift that will stabilize within milliseconds to seconds. But after that, despite some minor jitter (phase noise), the phase should stay locked. For all practical reasoning, the generator's reference frequency can be considered synchronous to the externally supplied one in this condition.
A "walk-through" of the two frequency signals isn't acceptable. Did you enter the output frequency on the AWG with the encoder or typed in as a decimal value? Sometimes, this may make a (tiny) difference. The AWG shoud indicate on the screen that it's using the external clock. Also, you may want to verify that you're using the latest firmware.

This ^^
Also you need ensure the Ext clock meets SDG1000X datasheet specs:
https://www.siglenteu.com/wp-content/uploads/dlm_uploads/2017/10/SDG1000X_DataSheet_DS0201X_E01G.pdf
P10 Reference Clock Input

Edit to add, most aux inputs are rated for 5V max so it would be wise to not exceed this.

[Moriambar]

Depending on the frequency the phase comparator works at, there may be some initial drift that will stabilize within milliseconds to seconds. But after that, despite some minor jitter (phase noise), the phase should stay locked. For all practical reasoning, the generator's reference frequency can be considered synchronous to the externally supplied one in this condition.
A "walk-through" of the two frequency signals isn't acceptable. Did you enter the output frequency on the AWG with the encoder or typed in as a decimal value? Sometimes, this may make a (tiny) difference. The AWG shoud indicate on the screen that it's using the external clock. Also, you may want to verify that you're using the latest firmware.

Hi, and thanks for your reply.
I have the latest firmware installed, also I tried both with the knob and by manually inputting the frequency, but no difference.
The screen indicates the external clock reference correctly as the menu does

[Moriambar]

Hi! do you have a frequency counter?

Hello, and thanks for your reply.
Unfortunately no, I don't have one [they seem quite expensive] but I have an ongoing project for building one. anyhow no.

when a signal moves relative to another it means their frequencies are not exactly the same, close but not exactly. When they are the exact same frequency, they both look static on the oscilloscope, but there may be some phase shift. In this short video you see 3 signals, channel 2 and 3 are at the same frequency exactly. but there is a slight phase shift, yet both are "locked" to each other, and channel one has a slightly lower frequency. so when triggering on channel one, we see the channel 2 and 3 signals move around, but when triggering on channel 2, we can see channel 2 and 3 are locked and we can see the phase difference between them, and only the channel one signal is moving, wich is why in these captures sometimes we can see channel one's edge and sometimes not.

https://youtu.be/omTYe5WgHVw

OK I see something similar of what's in the video, but the nonstatic signal is going right lol. The rest is exactly that

Thanks

[Moriambar]

The AWG shoud indicate on the screen that it's using the external clock. Also, you may want to verify that you're using the latest firmware.

This ^^

As I stated elsewhere that is correct, all points to the fact that the arb is using the external clock.

Also you need ensure the Ext clock meets SDG1000X datasheet specs:
https://www.siglenteu.com/wp-content/uploads/dlm_uploads/2017/10/SDG1000X_DataSheet_DS0201X_E01G.pdf
P10 Reference Clock Input

Edit to add, most aux inputs are rated for 5V max so it would be wise to not exceed this.

It's 3Vpp, which is well in spec

[jpb]

The generator is a DDS one, I presume - it may be that it can't exactly represent 10MHz, it should be able to at 150MS/s there should be an integer number (15) of samples per wavelength but maybe the digital representation isn't exact (the spec sheet says to within a microhertz).

It may be worth generating say square waves and see if the same drift occurs to find out if it is a DDS thing or if it is the PLL.

You could try generating a slightly different frequency to see if you can get rid of the drift say 10,000,000.000001 Hz or 9,999,999.999999 Hz then you could find out what the effective frequency is.

[fourfathom]

Arb Waveform Generators usually use Direct Digital Synthesis to generate the output frequency, and these typically use a binary power-of-two NCO (Numerically Controlled Oscillator) to set the output frequency.  The arb generator also will multiply the input reference up to a much higher frequency, using this high frequency to clock the NCO.  There will be many output frequencies that can't be generated exactly with the NCO, as the necessary divide ratio isn't possible with the binary NCO.  You can get extremely close, but not exact.

Simple example:
10 MHz reference, multiplied by 50 to get a 500 MHz internal clock.
16-bit NCO (They are usually wider than that, even if the Analog to Digital Converter is only 12 or 16 bits.)
This NCO can divide the 500 MHz clock by n/2¹⁶, where 'n' is the frequency control value.

To get an exact 10 MHz output you would need to divide 500 MHz by 50.  Unfortunately, with the 16-bit control word this would be 1310.72 / 65536, so the closest we can get is actually 1311/65536, which will give you an actual output frequency of about 10.000213 MHz.

With a wider control word you can get arbitrarily close, but often not exact.

[fourfathom]

This NCO can divide the 500 MHz clock by n/2¹⁶, where 'n' is the frequency control value.

I should have inverted that fraction.  In any case, for a binary NCO Fout = Fin * C / 2^N, where 'C' is the control value and 'N' is the bit-width of the NCO accumulator.

[Moriambar]

ok apparently 9.99999999 MHz or similar does the trick. The frontend still rounds it up at 10MHz but…

Cheers

[Anthocyanina]

OK I see something similar of what's in the video, but the nonstatic signal is going right lol. The rest is exactly that

Thanks

The direction in which the signal moves depends on how its frequency differs from the frequency of the signal you're triggering on. Higher frequency than the triggered signal, it will move to the left, lower frequency than the triggered signal, and it will move to the right.

[fourfathom]

ok apparently 9.99999999 MHz or similar does the trick. The frontend still rounds it up at 10MHz but…

Perhaps this just reduces but doesn't eliminate the intrinsic error.  If you have a classic binary DDS / NCO, there are some ratios (divisors) you just can't get.  Try to represent 1/3 or 1/10  or 7/25 as a binary fraction.  You can't do it exactly.