EK
Erik Kaashoek
Wed, Aug 3, 2022 6:58 PM
A well know technique for measuring phase pulling is measuring the phase
of two signals 0.01 Hz or less apart.
To test if this pulling has a relevant impact on frequency measurement
the ratio between two 10 MHz output signals from a signal generator was
measured. One output signal was changed in frequency in steps of 0.01 Hz
between 9999999 Hz and 10000001 Hz [1]
The plot shows the error at all measured frequencies differences (+/-
1Hz in steps of 0.01 Hz) is below the accuracy target of +/- 1e-9
Is this a relevant measurement for detecting possible interaction
between the two inputs of a frequency counter?
Any suggestions for how to do a performance evaluation of a frequency
counter?
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
A well know technique for measuring phase pulling is measuring the phase
of two signals 0.01 Hz or less apart.
To test if this pulling has a relevant impact on frequency measurement
the ratio between two 10 MHz output signals from a signal generator was
measured. One output signal was changed in frequency in steps of 0.01 Hz
between 9999999 Hz and 10000001 Hz [1]
The plot shows the error at all measured frequencies differences (+/-
1Hz in steps of 0.01 Hz) is below the accuracy target of +/- 1e-9
Is this a relevant measurement for detecting possible interaction
between the two inputs of a frequency counter?
Any suggestions for how to do a performance evaluation of a frequency
counter?
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
BK
Bob kb8tq
Wed, Aug 3, 2022 11:04 PM
Hi
Frequency pulling on an oscillator is indeed a very real thing. The closer
the injected signal is to the oscillator output, the more likely some form
of lockup is to occur. It’s not at all a bad way to measure / check the output
isolation of a design. Doing the measurement is (unfortunately) a bit tricky.
For a counter, the “big deal” is typically the reference. It’s always there and
you can’t shut it off ( at least if you want a useful measurement …). There are
a lot of counters that go a bit deaf as you get very close to the reference
frequency. Some of it is software based ( not enough data in enough buckets).
Some of it is RF isolation ( one signal masks the other ). Just what goes wrong
with this or that one is never very easy to work out.
With most of them “close” means deltas in the < 1x10^-8 range. A useful sweep
might be over +/- 5x10^-8 or less. Step size could easily be below 1x10^-11.
(= the steps are down in the noise of the sources ….). Run length could be pretty
long to average out noise issues. Running <= a second per step is probably a bit
fast, minutes per step is getting a bit crazy. Yes, this is something you automate
and let run overnight.
One very typical way to try to spot this is with two sources. One is stable and
acts as the reference. The other is allowed to very slowly drift / tune across the
other. Rb’s are not a bad way to do this since they are likely to have the parts
per trillion sort of tuning steps you are looking for. As you plot what should be
a nice linear frequency change, you look for flat spots / jumps / nonsense in the
output data plot.
If you want to extend this to multiple inputs, that could be done. Multiple sources
all being tuned in this or that pattern probably get the job done best time wise.
Cost wise “best" might be a very different thing. They all need to be quite stable
in order to keep random movement in the sources from masking the desired data.
That tends to drive up the cost a bit.
One could play with this or that synthesis approach. There is no rule that says it
can’t work. There is a risk of various spurs / artifacts getting in the way. There’s
also the issues with tuning word length to get really fine grain resolution. My guess
is that a couple ( = 2 to 4 ) of cheap telecom Rb’s still beat a built from scratch gizmo
cost wise.
Looking at your plot, it would be nice to get the “random stuff” down to < 100 ppt.
Then you would have a better idea if the 500 to 600 ppt items are problems or not.
The alternative might be to do a lot of runs and look for things that show up often.
Crazy !!
Bob
On Aug 3, 2022, at 10:58 AM, Erik Kaashoek via time-nuts time-nuts@lists.febo.com wrote:
A well know technique for measuring phase pulling is measuring the phase of two signals 0.01 Hz or less apart.
To test if this pulling has a relevant impact on frequency measurement the ratio between two 10 MHz output signals from a signal generator was measured. One output signal was changed in frequency in steps of 0.01 Hz between 9999999 Hz and 10000001 Hz [1]
The plot shows the error at all measured frequencies differences (+/- 1Hz in steps of 0.01 Hz) is below the accuracy target of +/- 1e-9
Is this a relevant measurement for detecting possible interaction between the two inputs of a frequency counter?
Any suggestions for how to do a performance evaluation of a frequency counter?
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi
Frequency pulling on an oscillator is indeed a very real thing. The closer
the injected signal is to the oscillator output, the more likely some form
of lockup is to occur. It’s not at all a bad way to measure / check the output
isolation of a design. Doing the measurement is (unfortunately) a bit tricky.
For a counter, the “big deal” is typically the reference. It’s always there and
you can’t shut it off ( at least if you want a useful measurement …). There are
a lot of counters that go a bit deaf as you get very close to the reference
frequency. Some of it is software based ( not enough data in enough buckets).
Some of it is RF isolation ( one signal masks the other ). Just what goes wrong
with this or that one is never very easy to work out.
With most of them “close” means deltas in the < 1x10^-8 range. A useful sweep
might be over +/- 5x10^-8 or less. Step size could easily be below 1x10^-11.
(= the steps are down in the noise of the sources ….). Run length could be pretty
long to average out noise issues. Running <= a second per step is probably a bit
fast, minutes per step is getting a bit crazy. Yes, this is something you automate
and let run overnight.
One very typical way to try to spot this is with two sources. One is stable and
acts as the reference. The other is allowed to very slowly drift / tune across the
other. Rb’s are not a bad way to do this since they are likely to have the parts
per trillion sort of tuning steps you are looking for. As you plot what should be
a nice linear frequency change, you look for flat spots / jumps / nonsense in the
output data plot.
If you want to extend this to multiple inputs, that could be done. Multiple sources
all being tuned in this or that pattern probably get the job done best time wise.
Cost wise “best" might be a very different thing. They all need to be quite stable
in order to keep random movement in the sources from masking the desired data.
That tends to drive up the cost a bit.
One could play with this or that synthesis approach. There is no rule that says it
can’t work. There is a risk of various spurs / artifacts getting in the way. There’s
also the issues with tuning word length to get really fine grain resolution. My guess
is that a couple ( = 2 to 4 ) of cheap telecom Rb’s still beat a built from scratch gizmo
cost wise.
Looking at your plot, it would be nice to get the “random stuff” down to < 100 ppt.
Then you would have a better idea if the 500 to 600 ppt items are problems or not.
The alternative might be to do a *lot* of runs and look for things that show up often.
Crazy !!
Bob
> On Aug 3, 2022, at 10:58 AM, Erik Kaashoek via time-nuts <time-nuts@lists.febo.com> wrote:
>
> A well know technique for measuring phase pulling is measuring the phase of two signals 0.01 Hz or less apart.
> To test if this pulling has a relevant impact on frequency measurement the ratio between two 10 MHz output signals from a signal generator was measured. One output signal was changed in frequency in steps of 0.01 Hz between 9999999 Hz and 10000001 Hz [1]
> The plot shows the error at all measured frequencies differences (+/- 1Hz in steps of 0.01 Hz) is below the accuracy target of +/- 1e-9
> Is this a relevant measurement for detecting possible interaction between the two inputs of a frequency counter?
> Any suggestions for how to do a performance evaluation of a frequency counter?
> [1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
EK
Erik Kaashoek
Thu, Aug 4, 2022 8:33 AM
Bob,
Thanks for the advice.
I've updated the sweep from -1.5E-9 to +1.5E-9 with steps of 1E-11 and
used a 10 second gate time.
The used DDS signal generator was locked to the 10 MHz reference output
of the counter
The impact of being close to the reference is clearly visible in the
updated plot [1]
Measurement error well away from 10MHz is in the order of 1E-11
Close to 10 MHz ( +/- 0.5E-9 ) this increases to 1E-10 which is still
acceptable.
Erik.
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
On 4-8-2022 1:04, Bob kb8tq wrote:
Hi
Frequency pulling on an oscillator is indeed a very real thing. The closer
the injected signal is to the oscillator output, the more likely some form
of lockup is to occur. It’s not at all a bad way to measure / check the output
isolation of a design. Doing the measurement is (unfortunately) a bit tricky.
For a counter, the “big deal” is typically the reference. It’s always there and
you can’t shut it off ( at least if you want a useful measurement …). There are
a lot of counters that go a bit deaf as you get very close to the reference
frequency. Some of it is software based ( not enough data in enough buckets).
Some of it is RF isolation ( one signal masks the other ). Just what goes wrong
with this or that one is never very easy to work out.
With most of them “close” means deltas in the < 1x10^-8 range. A useful sweep
might be over +/- 5x10^-8 or less. Step size could easily be below 1x10^-11.
(= the steps are down in the noise of the sources ….). Run length could be pretty
long to average out noise issues. Running <= a second per step is probably a bit
fast, minutes per step is getting a bit crazy. Yes, this is something you automate
and let run overnight.
One very typical way to try to spot this is with two sources. One is stable and
acts as the reference. The other is allowed to very slowly drift / tune across the
other. Rb’s are not a bad way to do this since they are likely to have the parts
per trillion sort of tuning steps you are looking for. As you plot what should be
a nice linear frequency change, you look for flat spots / jumps / nonsense in the
output data plot.
If you want to extend this to multiple inputs, that could be done. Multiple sources
all being tuned in this or that pattern probably get the job done best time wise.
Cost wise “best" might be a very different thing. They all need to be quite stable
in order to keep random movement in the sources from masking the desired data.
That tends to drive up the cost a bit.
One could play with this or that synthesis approach. There is no rule that says it
can’t work. There is a risk of various spurs / artifacts getting in the way. There’s
also the issues with tuning word length to get really fine grain resolution. My guess
is that a couple ( = 2 to 4 ) of cheap telecom Rb’s still beat a built from scratch gizmo
cost wise.
Looking at your plot, it would be nice to get the “random stuff” down to < 100 ppt.
Then you would have a better idea if the 500 to 600 ppt items are problems or not.
The alternative might be to do a lot of runs and look for things that show up often.
Crazy !!
Bob
Bob,
Thanks for the advice.
I've updated the sweep from -1.5E-9 to +1.5E-9 with steps of 1E-11 and
used a 10 second gate time.
The used DDS signal generator was locked to the 10 MHz reference output
of the counter
The impact of being close to the reference is clearly visible in the
updated plot [1]
Measurement error well away from 10MHz is in the order of 1E-11
Close to 10 MHz ( +/- 0.5E-9 ) this increases to 1E-10 which is still
acceptable.
Erik.
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
On 4-8-2022 1:04, Bob kb8tq wrote:
> Hi
>
> Frequency pulling on an oscillator is indeed a very real thing. The closer
> the injected signal is to the oscillator output, the more likely some form
> of lockup is to occur. It’s not at all a bad way to measure / check the output
> isolation of a design. Doing the measurement is (unfortunately) a bit tricky.
>
> For a counter, the “big deal” is typically the reference. It’s always there and
> you can’t shut it off ( at least if you want a useful measurement …). There are
> a lot of counters that go a bit deaf as you get very close to the reference
> frequency. Some of it is software based ( not enough data in enough buckets).
> Some of it is RF isolation ( one signal masks the other ). Just what goes wrong
> with this or that one is never very easy to work out.
>
> With most of them “close” means deltas in the < 1x10^-8 range. A useful sweep
> might be over +/- 5x10^-8 or less. Step size could easily be below 1x10^-11.
> (= the steps are down in the noise of the sources ….). Run length could be pretty
> long to average out noise issues. Running <= a second per step is probably a bit
> fast, minutes per step is getting a bit crazy. Yes, this is something you automate
> and let run overnight.
>
> One very typical way to try to spot this is with two sources. One is stable and
> acts as the reference. The other is allowed to very slowly drift / tune across the
> other. Rb’s are not a bad way to do this since they are likely to have the parts
> per trillion sort of tuning steps you are looking for. As you plot what should be
> a nice linear frequency change, you look for flat spots / jumps / nonsense in the
> output data plot.
>
> If you want to extend this to multiple inputs, that could be done. Multiple sources
> all being tuned in this or that pattern probably get the job done best time wise.
> Cost wise “best" might be a very different thing. They all need to be quite stable
> in order to keep random movement in the sources from masking the desired data.
> That tends to drive up the cost a bit.
>
> One could play with this or that synthesis approach. There is no rule that says it
> can’t work. There is a risk of various spurs / artifacts getting in the way. There’s
> also the issues with tuning word length to get really fine grain resolution. My guess
> is that a couple ( = 2 to 4 ) of cheap telecom Rb’s still beat a built from scratch gizmo
> cost wise.
>
> Looking at your plot, it would be nice to get the “random stuff” down to < 100 ppt.
> Then you would have a better idea if the 500 to 600 ppt items are problems or not.
> The alternative might be to do a *lot* of runs and look for things that show up often.
>
> Crazy !!
>
> Bob
MD
Magnus Danielson
Thu, Aug 4, 2022 8:46 AM
Hi Erik,
Be aware that frequency pulling of the oscillator is not the same
phenomena as exposing non-linearity in time-interval measurement. The
later being more complicated by presence of noise. This nonlinearity is
actually a bit of a complex animal. I would not use the term frequency
pulling to describe the overall phenomena. If you see the same pattern
of deviation at some other frequency the actual frequency pulling would
be much less. Consider for instance 15000001 Hz.
First of all you need to consider that you will have noise causing your
frequency estimates to spread out. The four classical noises of
oscillators will cause a Gaussian distribution on frequency estimates.
In itself it has zero mean contribution, but as one makes limited length
measure there will be a residual offset here or there, which jumps
around in Gaussian shape.
The frequency flicker modulation as converted into flicker frequency
readings isn't strictly Gaussian, but good enough that we can use it as
an approximation.
Frequency pulling of the counters reference oscillator would pull it
towards the frequency of the other signal, so if you use a higher
frequency the reference would go higher. Observing this in the noise
variations require a bit of patience, but it possible, so that the
confidence interval around the average is tight enough that you see the
change. As we measure the external frequency it would mean that we would
see it count the assigned signal lower. This would work if we can
maintain stability of the oscillators well enough that they have not
glided towards each other, which they naturally also could do.
So, there is a bit of careful measurements to be done before claiming
frequency pulling.
Naturally, using accelerated least square processing for frequency
estimation is recommended. Helps to surpress noise.
Cheers,
Magnus
On 2022-08-03 20:58, Erik Kaashoek via time-nuts wrote:
A well know technique for measuring phase pulling is measuring the
phase of two signals 0.01 Hz or less apart.
To test if this pulling has a relevant impact on frequency measurement
the ratio between two 10 MHz output signals from a signal generator
was measured. One output signal was changed in frequency in steps of
0.01 Hz between 9999999 Hz and 10000001 Hz [1]
The plot shows the error at all measured frequencies differences (+/-
1Hz in steps of 0.01 Hz) is below the accuracy target of +/- 1e-9
Is this a relevant measurement for detecting possible interaction
between the two inputs of a frequency counter?
Any suggestions for how to do a performance evaluation of a frequency
counter?
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Erik,
Be aware that frequency pulling of the oscillator is not the same
phenomena as exposing non-linearity in time-interval measurement. The
later being more complicated by presence of noise. This nonlinearity is
actually a bit of a complex animal. I would not use the term frequency
pulling to describe the overall phenomena. If you see the same pattern
of deviation at some other frequency the actual frequency pulling would
be much less. Consider for instance 15000001 Hz.
First of all you need to consider that you will have noise causing your
frequency estimates to spread out. The four classical noises of
oscillators will cause a Gaussian distribution on frequency estimates.
In itself it has zero mean contribution, but as one makes limited length
measure there will be a residual offset here or there, which jumps
around in Gaussian shape.
The frequency flicker modulation as converted into flicker frequency
readings isn't strictly Gaussian, but good enough that we can use it as
an approximation.
Frequency pulling of the counters reference oscillator would pull it
towards the frequency of the other signal, so if you use a higher
frequency the reference would go higher. Observing this in the noise
variations require a bit of patience, but it possible, so that the
confidence interval around the average is tight enough that you see the
change. As we measure the external frequency it would mean that we would
see it count the assigned signal lower. This would work if we can
maintain stability of the oscillators well enough that they have not
glided towards each other, which they naturally also could do.
So, there is a bit of careful measurements to be done before claiming
frequency pulling.
Naturally, using accelerated least square processing for frequency
estimation is recommended. Helps to surpress noise.
Cheers,
Magnus
On 2022-08-03 20:58, Erik Kaashoek via time-nuts wrote:
> A well know technique for measuring phase pulling is measuring the
> phase of two signals 0.01 Hz or less apart.
> To test if this pulling has a relevant impact on frequency measurement
> the ratio between two 10 MHz output signals from a signal generator
> was measured. One output signal was changed in frequency in steps of
> 0.01 Hz between 9999999 Hz and 10000001 Hz [1]
> The plot shows the error at all measured frequencies differences (+/-
> 1Hz in steps of 0.01 Hz) is below the accuracy target of +/- 1e-9
> Is this a relevant measurement for detecting possible interaction
> between the two inputs of a frequency counter?
> Any suggestions for how to do a performance evaluation of a frequency
> counter?
> [1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
EK
Erik Kaashoek
Thu, Aug 4, 2022 2:03 PM
Hi Magnus,
The measurements uses least square processing over 200000 samples per
measurement
As you proposed a high resolution scan was made showing the pulling to
be indeed in the order of the delta to the reference frequency [1]
But its not a constant pull and the measured frequency sometimes jumps
back to the correct frequency or even to the opposite side.
The bandwidth of the variations (2E-10) is too constant not to be based
on some underlying phenomena still to be investigated, especially above
the reference frequency.
Please keep in mind this is still measured using prototype HW using long
connecting wires.
Hope this improves when done on a PCB.
Erik.
[1] http://athome.kaashoek.com/time-nuts/Freq_error_fine.PNG
On 4-8-2022 10:46, Magnus Danielson via time-nuts wrote:
Hi Erik,
Be aware that frequency pulling of the oscillator is not the same
phenomena as exposing non-linearity in time-interval measurement. The
later being more complicated by presence of noise. This nonlinearity
is actually a bit of a complex animal. I would not use the term
frequency pulling to describe the overall phenomena. If you see the
same pattern of deviation at some other frequency the actual frequency
pulling would be much less. Consider for instance 15000001 Hz.
First of all you need to consider that you will have noise causing
your frequency estimates to spread out. The four classical noises of
oscillators will cause a Gaussian distribution on frequency estimates.
In itself it has zero mean contribution, but as one makes limited
length measure there will be a residual offset here or there, which
jumps around in Gaussian shape.
The frequency flicker modulation as converted into flicker frequency
readings isn't strictly Gaussian, but good enough that we can use it
as an approximation.
Frequency pulling of the counters reference oscillator would pull it
towards the frequency of the other signal, so if you use a higher
frequency the reference would go higher. Observing this in the noise
variations require a bit of patience, but it possible, so that the
confidence interval around the average is tight enough that you see
the change. As we measure the external frequency it would mean that we
would see it count the assigned signal lower. This would work if we
can maintain stability of the oscillators well enough that they have
not glided towards each other, which they naturally also could do.
So, there is a bit of careful measurements to be done before claiming
frequency pulling.
Naturally, using accelerated least square processing for frequency
estimation is recommended. Helps to surpress noise.
Cheers,
Magnus
Hi Magnus,
The measurements uses least square processing over 200000 samples per
measurement
As you proposed a high resolution scan was made showing the pulling to
be indeed in the order of the delta to the reference frequency [1]
But its not a constant pull and the measured frequency sometimes jumps
back to the correct frequency or even to the opposite side.
The bandwidth of the variations (2E-10) is too constant not to be based
on some underlying phenomena still to be investigated, especially above
the reference frequency.
Please keep in mind this is still measured using prototype HW using long
connecting wires.
Hope this improves when done on a PCB.
Erik.
[1] http://athome.kaashoek.com/time-nuts/Freq_error_fine.PNG
On 4-8-2022 10:46, Magnus Danielson via time-nuts wrote:
> Hi Erik,
>
> Be aware that frequency pulling of the oscillator is not the same
> phenomena as exposing non-linearity in time-interval measurement. The
> later being more complicated by presence of noise. This nonlinearity
> is actually a bit of a complex animal. I would not use the term
> frequency pulling to describe the overall phenomena. If you see the
> same pattern of deviation at some other frequency the actual frequency
> pulling would be much less. Consider for instance 15000001 Hz.
>
> First of all you need to consider that you will have noise causing
> your frequency estimates to spread out. The four classical noises of
> oscillators will cause a Gaussian distribution on frequency estimates.
> In itself it has zero mean contribution, but as one makes limited
> length measure there will be a residual offset here or there, which
> jumps around in Gaussian shape.
>
> The frequency flicker modulation as converted into flicker frequency
> readings isn't strictly Gaussian, but good enough that we can use it
> as an approximation.
>
> Frequency pulling of the counters reference oscillator would pull it
> towards the frequency of the other signal, so if you use a higher
> frequency the reference would go higher. Observing this in the noise
> variations require a bit of patience, but it possible, so that the
> confidence interval around the average is tight enough that you see
> the change. As we measure the external frequency it would mean that we
> would see it count the assigned signal lower. This would work if we
> can maintain stability of the oscillators well enough that they have
> not glided towards each other, which they naturally also could do.
>
> So, there is a bit of careful measurements to be done before claiming
> frequency pulling.
>
> Naturally, using accelerated least square processing for frequency
> estimation is recommended. Helps to surpress noise.
>
> Cheers,
> Magnus
MD
Magnus Danielson
Thu, Aug 4, 2022 2:35 PM
Hi Erik,
How long is the measurement in time for each measurement? The time
between each measurement is another way to answer as I suspect the
200000 samples is done back-to-back.
Thing is, the actual digitizing of time difference has a systematic
effect in it which is in itself problematic. It is interesting in your
plot that the outer shape of peaks narrow down and go through zero at
the center frequency.
If aim to measure the pulling of the reference, you should consider
measuring the refrence oscillator output with another counter, as this
will help to separate the effect of the input frequency offset into the
counter you design from the pulling of the reference.
The time interval measurement input has both systematic and random
components to them. A small frequency offset those expose the input to a
slow phase ramp that then cycles over the interpolator's systematics.
The period of this beat pattern then might not align up with the length
of the measurement run, so positive and negative contributions may not
even out, so depending on where on the cycle you measured you may get
any range of values within the range. For odd frequencies one get
essentially the same values but in an alternative time-order but it
behaves about the same. Noise tends to average out smaller
phase-differences but not larger, so it takes quite a bit of noise to
smooth things out such that a long term average can take benefit.
This is why I am asking the questions I ask.
Cheers,
Magnus
On 2022-08-04 16:03, Erik Kaashoek wrote:
Hi Magnus,
The measurements uses least square processing over 200000 samples per
measurement
As you proposed a high resolution scan was made showing the pulling to
be indeed in the order of the delta to the reference frequency [1]
But its not a constant pull and the measured frequency sometimes jumps
back to the correct frequency or even to the opposite side.
The bandwidth of the variations (2E-10) is too constant not to be
based on some underlying phenomena still to be investigated,
especially above the reference frequency.
Please keep in mind this is still measured using prototype HW using
long connecting wires.
Hope this improves when done on a PCB.
Erik.
[1] http://athome.kaashoek.com/time-nuts/Freq_error_fine.PNG
On 4-8-2022 10:46, Magnus Danielson via time-nuts wrote:
Hi Erik,
Be aware that frequency pulling of the oscillator is not the same
phenomena as exposing non-linearity in time-interval measurement. The
later being more complicated by presence of noise. This nonlinearity
is actually a bit of a complex animal. I would not use the term
frequency pulling to describe the overall phenomena. If you see the
same pattern of deviation at some other frequency the actual
frequency pulling would be much less. Consider for instance 15000001 Hz.
First of all you need to consider that you will have noise causing
your frequency estimates to spread out. The four classical noises of
oscillators will cause a Gaussian distribution on frequency
estimates. In itself it has zero mean contribution, but as one makes
limited length measure there will be a residual offset here or there,
which jumps around in Gaussian shape.
The frequency flicker modulation as converted into flicker frequency
readings isn't strictly Gaussian, but good enough that we can use it
as an approximation.
Frequency pulling of the counters reference oscillator would pull it
towards the frequency of the other signal, so if you use a higher
frequency the reference would go higher. Observing this in the noise
variations require a bit of patience, but it possible, so that the
confidence interval around the average is tight enough that you see
the change. As we measure the external frequency it would mean that
we would see it count the assigned signal lower. This would work if
we can maintain stability of the oscillators well enough that they
have not glided towards each other, which they naturally also could do.
So, there is a bit of careful measurements to be done before claiming
frequency pulling.
Naturally, using accelerated least square processing for frequency
estimation is recommended. Helps to surpress noise.
Cheers,
Magnus
Hi Erik,
How long is the measurement in time for each measurement? The time
between each measurement is another way to answer as I suspect the
200000 samples is done back-to-back.
Thing is, the actual digitizing of time difference has a systematic
effect in it which is in itself problematic. It is interesting in your
plot that the outer shape of peaks narrow down and go through zero at
the center frequency.
If aim to measure the pulling of the reference, you should consider
measuring the refrence oscillator output with another counter, as this
will help to separate the effect of the input frequency offset into the
counter you design from the pulling of the reference.
The time interval measurement input has both systematic and random
components to them. A small frequency offset those expose the input to a
slow phase ramp that then cycles over the interpolator's systematics.
The period of this beat pattern then might not align up with the length
of the measurement run, so positive and negative contributions may not
even out, so depending on where on the cycle you measured you may get
any range of values within the range. For odd frequencies one get
essentially the same values but in an alternative time-order but it
behaves about the same. Noise tends to average out smaller
phase-differences but not larger, so it takes quite a bit of noise to
smooth things out such that a long term average can take benefit.
This is why I am asking the questions I ask.
Cheers,
Magnus
On 2022-08-04 16:03, Erik Kaashoek wrote:
> Hi Magnus,
> The measurements uses least square processing over 200000 samples per
> measurement
> As you proposed a high resolution scan was made showing the pulling to
> be indeed in the order of the delta to the reference frequency [1]
> But its not a constant pull and the measured frequency sometimes jumps
> back to the correct frequency or even to the opposite side.
> The bandwidth of the variations (2E-10) is too constant not to be
> based on some underlying phenomena still to be investigated,
> especially above the reference frequency.
> Please keep in mind this is still measured using prototype HW using
> long connecting wires.
> Hope this improves when done on a PCB.
> Erik.
> [1] http://athome.kaashoek.com/time-nuts/Freq_error_fine.PNG
>
> On 4-8-2022 10:46, Magnus Danielson via time-nuts wrote:
>> Hi Erik,
>>
>> Be aware that frequency pulling of the oscillator is not the same
>> phenomena as exposing non-linearity in time-interval measurement. The
>> later being more complicated by presence of noise. This nonlinearity
>> is actually a bit of a complex animal. I would not use the term
>> frequency pulling to describe the overall phenomena. If you see the
>> same pattern of deviation at some other frequency the actual
>> frequency pulling would be much less. Consider for instance 15000001 Hz.
>>
>> First of all you need to consider that you will have noise causing
>> your frequency estimates to spread out. The four classical noises of
>> oscillators will cause a Gaussian distribution on frequency
>> estimates. In itself it has zero mean contribution, but as one makes
>> limited length measure there will be a residual offset here or there,
>> which jumps around in Gaussian shape.
>>
>> The frequency flicker modulation as converted into flicker frequency
>> readings isn't strictly Gaussian, but good enough that we can use it
>> as an approximation.
>>
>> Frequency pulling of the counters reference oscillator would pull it
>> towards the frequency of the other signal, so if you use a higher
>> frequency the reference would go higher. Observing this in the noise
>> variations require a bit of patience, but it possible, so that the
>> confidence interval around the average is tight enough that you see
>> the change. As we measure the external frequency it would mean that
>> we would see it count the assigned signal lower. This would work if
>> we can maintain stability of the oscillators well enough that they
>> have not glided towards each other, which they naturally also could do.
>>
>> So, there is a bit of careful measurements to be done before claiming
>> frequency pulling.
>>
>> Naturally, using accelerated least square processing for frequency
>> estimation is recommended. Helps to surpress noise.
>>
>> Cheers,
>> Magnus
>
BK
Bob kb8tq
Thu, Aug 4, 2022 3:43 PM
Hi
Unfortunately the typical DDS generator has a “triangle wave” spur
modulation on the phase of its output. Unless it’s a very unusual part
( = audio ) the DAC resolution limits things at a potentially nasty level.
When the phase truncation / modulation edges come along, they can
create issues with the counter.
Since this is time domain stuff and most designs are looking at frequency
domain, it's an easy thing to miss. The typical app note goes straight
to the frequency domain. They talk about the results, but not about
a nice easy to understand phase error plot. ( = even finding a link with
a nice plot is not something Mr Google seems to want to do ….).
Bob
On Aug 4, 2022, at 12:33 AM, Erik Kaashoek erik@kaashoek.com wrote:
Bob,
Thanks for the advice.
I've updated the sweep from -1.5E-9 to +1.5E-9 with steps of 1E-11 and used a 10 second gate time.
The used DDS signal generator was locked to the 10 MHz reference output of the counter
The impact of being close to the reference is clearly visible in the updated plot [1]
Measurement error well away from 10MHz is in the order of 1E-11
Close to 10 MHz ( +/- 0.5E-9 ) this increases to 1E-10 which is still acceptable.
Erik.
[1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
On 4-8-2022 1:04, Bob kb8tq wrote:
Hi
Frequency pulling on an oscillator is indeed a very real thing. The closer
the injected signal is to the oscillator output, the more likely some form
of lockup is to occur. It’s not at all a bad way to measure / check the output
isolation of a design. Doing the measurement is (unfortunately) a bit tricky.
For a counter, the “big deal” is typically the reference. It’s always there and
you can’t shut it off ( at least if you want a useful measurement …). There are
a lot of counters that go a bit deaf as you get very close to the reference
frequency. Some of it is software based ( not enough data in enough buckets).
Some of it is RF isolation ( one signal masks the other ). Just what goes wrong
with this or that one is never very easy to work out.
With most of them “close” means deltas in the < 1x10^-8 range. A useful sweep
might be over +/- 5x10^-8 or less. Step size could easily be below 1x10^-11.
(= the steps are down in the noise of the sources ….). Run length could be pretty
long to average out noise issues. Running <= a second per step is probably a bit
fast, minutes per step is getting a bit crazy. Yes, this is something you automate
and let run overnight.
One very typical way to try to spot this is with two sources. One is stable and
acts as the reference. The other is allowed to very slowly drift / tune across the
other. Rb’s are not a bad way to do this since they are likely to have the parts
per trillion sort of tuning steps you are looking for. As you plot what should be
a nice linear frequency change, you look for flat spots / jumps / nonsense in the
output data plot.
If you want to extend this to multiple inputs, that could be done. Multiple sources
all being tuned in this or that pattern probably get the job done best time wise.
Cost wise “best" might be a very different thing. They all need to be quite stable
in order to keep random movement in the sources from masking the desired data.
That tends to drive up the cost a bit.
One could play with this or that synthesis approach. There is no rule that says it
can’t work. There is a risk of various spurs / artifacts getting in the way. There’s
also the issues with tuning word length to get really fine grain resolution. My guess
is that a couple ( = 2 to 4 ) of cheap telecom Rb’s still beat a built from scratch gizmo
cost wise.
Looking at your plot, it would be nice to get the “random stuff” down to < 100 ppt.
Then you would have a better idea if the 500 to 600 ppt items are problems or not.
The alternative might be to do a lot of runs and look for things that show up often.
Crazy !!
Bob
Hi
Unfortunately the typical DDS generator has a “triangle wave” spur
modulation on the phase of its output. Unless it’s a very unusual part
( = audio ) the DAC resolution limits things at a potentially nasty level.
When the phase truncation / modulation edges come along, they can
create issues with the counter.
Since this is time domain stuff and most designs are looking at frequency
domain, it's an easy thing to miss. The typical app note goes straight
to the frequency domain. They talk about the results, but not about
a nice easy to understand phase error plot. ( = even finding a link with
a nice plot is not something Mr Google seems to want to do ….).
Bob
> On Aug 4, 2022, at 12:33 AM, Erik Kaashoek <erik@kaashoek.com> wrote:
>
> Bob,
>
> Thanks for the advice.
> I've updated the sweep from -1.5E-9 to +1.5E-9 with steps of 1E-11 and used a 10 second gate time.
> The used DDS signal generator was locked to the 10 MHz reference output of the counter
> The impact of being close to the reference is clearly visible in the updated plot [1]
> Measurement error well away from 10MHz is in the order of 1E-11
> Close to 10 MHz ( +/- 0.5E-9 ) this increases to 1E-10 which is still acceptable.
> Erik.
>
> [1] http://athome.kaashoek.com/time-nuts/Freq_error.PNG
>
> On 4-8-2022 1:04, Bob kb8tq wrote:
>> Hi
>>
>> Frequency pulling on an oscillator is indeed a very real thing. The closer
>> the injected signal is to the oscillator output, the more likely some form
>> of lockup is to occur. It’s not at all a bad way to measure / check the output
>> isolation of a design. Doing the measurement is (unfortunately) a bit tricky.
>>
>> For a counter, the “big deal” is typically the reference. It’s always there and
>> you can’t shut it off ( at least if you want a useful measurement …). There are
>> a lot of counters that go a bit deaf as you get very close to the reference
>> frequency. Some of it is software based ( not enough data in enough buckets).
>> Some of it is RF isolation ( one signal masks the other ). Just what goes wrong
>> with this or that one is never very easy to work out.
>>
>> With most of them “close” means deltas in the < 1x10^-8 range. A useful sweep
>> might be over +/- 5x10^-8 or less. Step size could easily be below 1x10^-11.
>> (= the steps are down in the noise of the sources ….). Run length could be pretty
>> long to average out noise issues. Running <= a second per step is probably a bit
>> fast, minutes per step is getting a bit crazy. Yes, this is something you automate
>> and let run overnight.
>>
>> One very typical way to try to spot this is with two sources. One is stable and
>> acts as the reference. The other is allowed to very slowly drift / tune across the
>> other. Rb’s are not a bad way to do this since they are likely to have the parts
>> per trillion sort of tuning steps you are looking for. As you plot what should be
>> a nice linear frequency change, you look for flat spots / jumps / nonsense in the
>> output data plot.
>>
>> If you want to extend this to multiple inputs, that could be done. Multiple sources
>> all being tuned in this or that pattern probably get the job done best time wise.
>> Cost wise “best" might be a very different thing. They all need to be quite stable
>> in order to keep random movement in the sources from masking the desired data.
>> That tends to drive up the cost a bit.
>>
>> One could play with this or that synthesis approach. There is no rule that says it
>> can’t work. There is a risk of various spurs / artifacts getting in the way. There’s
>> also the issues with tuning word length to get really fine grain resolution. My guess
>> is that a couple ( = 2 to 4 ) of cheap telecom Rb’s still beat a built from scratch gizmo
>> cost wise.
>>
>> Looking at your plot, it would be nice to get the “random stuff” down to < 100 ppt.
>> Then you would have a better idea if the 500 to 600 ppt items are problems or not.
>> The alternative might be to do a *lot* of runs and look for things that show up often.
>>
>> Crazy !!
>>
>> Bob
EK
Erik Kaashoek
Thu, Aug 4, 2022 6:04 PM
Bob, Magnus,
Using a second counter (my famous Picotest U6200A) locked to the
reference output of the DIY counter and measuring the output of the
signal generator and also set to gate of 10 s it is confirmed that the
frequency pulling (if any) is below 1E-11 (not more digits on the
display of the U6200A)
Generator is set to 10.000,000,000,2 MHz and is measured as such by the
U6200A
As there seems to be no frequency pulling I went back to the simulation
of the linear regression algorithm and discovered that when there is a
integer divide/multiply relation between the internal reference and the
measured frequency the regression looses some accuracy.
For sure if the reference is close to an integer multiple of the
measured frequency (10 Mhz measured -> 200 MHz reference) the regression
collapses completely in accuracy. I hoped that by creating a fractional
relation this collapse would not happen at 10 MHz but is still there,
although much smaller. For this test I'm using a "div 3 times 64 e.g.
213.333,333,333,333... MHz" internal reference frequency derived from
the external 10MHz reference. Ton van Baak warned me against using
fractional relations in a counter but otherwise it is impossible to
measure a 10 MHz input signal with any accuracy without a HW time to
digital as the interpolation no longer works. I can switch dynamically
to 200 MHz or 245 MHz reference and these produce much much worse results.
I realize this test only measures if the TCXO used as reference in the
DIY counter does not show frequency pulling but it does not show if the
PLL used to convert the 10MHz to 213.333333333... MHz for the internal
counters shows any frequency pulling.
NOt
Erik.
Bob, Magnus,
Using a second counter (my famous Picotest U6200A) locked to the
reference output of the DIY counter and measuring the output of the
signal generator and also set to gate of 10 s it is confirmed that the
frequency pulling (if any) is below 1E-11 (not more digits on the
display of the U6200A)
Generator is set to 10.000,000,000,2 MHz and is measured as such by the
U6200A
As there seems to be no frequency pulling I went back to the simulation
of the linear regression algorithm and discovered that when there is a
integer divide/multiply relation between the internal reference and the
measured frequency the regression looses some accuracy.
For sure if the reference is close to an integer multiple of the
measured frequency (10 Mhz measured -> 200 MHz reference) the regression
collapses completely in accuracy. I hoped that by creating a fractional
relation this collapse would not happen at 10 MHz but is still there,
although much smaller. For this test I'm using a "div 3 times 64 e.g.
213.333,333,333,333... MHz" internal reference frequency derived from
the external 10MHz reference. Ton van Baak warned me against using
fractional relations in a counter but otherwise it is impossible to
measure a 10 MHz input signal with any accuracy without a HW time to
digital as the interpolation no longer works. I can switch dynamically
to 200 MHz or 245 MHz reference and these produce much much worse results.
I realize this test only measures if the TCXO used as reference in the
DIY counter does not show frequency pulling but it does not show if the
PLL used to convert the 10MHz to 213.333333333... MHz for the internal
counters shows any frequency pulling.
NOt
Erik.
MD
Magnus Danielson
Fri, Aug 5, 2022 2:25 AM
Erik,
Good job there. I suspected that the actual frequency pulling, if any,
was very low.
Yes, numerical issues in linear regression can be painful.
In the accelerated method I developed, you can engineer the values to
avoid major numerical issues. Also, you are not the first to have seen
such issues. This is done first-degree by making sure that things is
accumulated without making any roundings, and secondly by choosing the
number of samples just right to make the unavoidable final division not
too terrible to the end result.
It's well known that you get fractional issues too.
Cheers,
Magnus - tired after driving 600+ km
On 8/4/22 20:04, Erik Kaashoek wrote:
Bob, Magnus,
Using a second counter (my famous Picotest U6200A) locked to the
reference output of the DIY counter and measuring the output of the
signal generator and also set to gate of 10 s it is confirmed that the
frequency pulling (if any) is below 1E-11 (not more digits on the
display of the U6200A)
Generator is set to 10.000,000,000,2 MHz and is measured as such by
the U6200A
As there seems to be no frequency pulling I went back to the
simulation of the linear regression algorithm and discovered that when
there is a integer divide/multiply relation between the internal
reference and the measured frequency the regression looses some accuracy.
For sure if the reference is close to an integer multiple of the
measured frequency (10 Mhz measured -> 200 MHz reference) the
regression collapses completely in accuracy. I hoped that by creating
a fractional relation this collapse would not happen at 10 MHz but is
still there, although much smaller. For this test I'm using a "div 3
times 64 e.g. 213.333,333,333,333... MHz" internal reference frequency
derived from the external 10MHz reference. Ton van Baak warned me
against using fractional relations in a counter but otherwise it is
impossible to measure a 10 MHz input signal with any accuracy without
a HW time to digital as the interpolation no longer works. I can
switch dynamically to 200 MHz or 245 MHz reference and these produce
much much worse results.
I realize this test only measures if the TCXO used as reference in the
DIY counter does not show frequency pulling but it does not show if
the PLL used to convert the 10MHz to 213.333333333... MHz for the
internal counters shows any frequency pulling.
NOt
Erik.
Erik,
Good job there. I suspected that the actual frequency pulling, if any,
was very low.
Yes, numerical issues in linear regression can be painful.
In the accelerated method I developed, you can engineer the values to
avoid major numerical issues. Also, you are not the first to have seen
such issues. This is done first-degree by making sure that things is
accumulated without making any roundings, and secondly by choosing the
number of samples just right to make the unavoidable final division not
too terrible to the end result.
It's well known that you get fractional issues too.
Cheers,
Magnus - tired after driving 600+ km
On 8/4/22 20:04, Erik Kaashoek wrote:
> Bob, Magnus,
>
> Using a second counter (my famous Picotest U6200A) locked to the
> reference output of the DIY counter and measuring the output of the
> signal generator and also set to gate of 10 s it is confirmed that the
> frequency pulling (if any) is below 1E-11 (not more digits on the
> display of the U6200A)
> Generator is set to 10.000,000,000,2 MHz and is measured as such by
> the U6200A
> As there seems to be no frequency pulling I went back to the
> simulation of the linear regression algorithm and discovered that when
> there is a integer divide/multiply relation between the internal
> reference and the measured frequency the regression looses some accuracy.
> For sure if the reference is close to an integer multiple of the
> measured frequency (10 Mhz measured -> 200 MHz reference) the
> regression collapses completely in accuracy. I hoped that by creating
> a fractional relation this collapse would not happen at 10 MHz but is
> still there, although much smaller. For this test I'm using a "div 3
> times 64 e.g. 213.333,333,333,333... MHz" internal reference frequency
> derived from the external 10MHz reference. Ton van Baak warned me
> against using fractional relations in a counter but otherwise it is
> impossible to measure a 10 MHz input signal with any accuracy without
> a HW time to digital as the interpolation no longer works. I can
> switch dynamically to 200 MHz or 245 MHz reference and these produce
> much much worse results.
> I realize this test only measures if the TCXO used as reference in the
> DIY counter does not show frequency pulling but it does not show if
> the PLL used to convert the 10MHz to 213.333333333... MHz for the
> internal counters shows any frequency pulling.
> NOt
> Erik.
TV
Tom Van Baak
Fri, Aug 5, 2022 12:55 PM
the measured frequency the regression looses some accuracy.
Yes, the hp/Agilent/Keysight 53132A does that too. Here's the footnote
from the user manual:
http://leapsecond.com/pages/53132/53132-reduced-resolution.gif
And it's not just at 10 MHz. Any fraction or multiple within 600 ppb is
affected too. What impressed me is that the hp firmware engineers
specifically detected this condition and reduced the number of digits
displayed accordingly. This avoids the user from getting a false sense
of precision.
Tom Van Baak warned me against using fractional relations in
a counter but otherwise it is impossible to measure a 10 MHz
input signal with any accuracy without a HW time to digital
as the interpolation no longer works.
Right, which is probably why many high-end commercial counters use
interpolators. But you aren't, and that's ok because your design spec is
on the order of 9 digits. Keep it simple. Later if you design a 10 or 11
or 12 digit counter you'll have to resort to using h/w interpolation as
well. Even the Lars GPSDO uses a crude interpolator; it's not that
difficult. Many threads in the time-nuts archive on the topic.
Your slow sweeping experiments reminded me of a great example I once ran
into. So I wrote it up with photos and plots:
http://leapsecond.com/pages/racal/
http://leapsecond.com/pages/racal/stdev.htm
Even if you aren't building a frequency counter, this strange event is
quite interesting. One of the plots is attached; the rest are in the URL
above.
/tvb
On 8/4/2022 11:04 AM, Erik Kaashoek via time-nuts wrote:
Bob, Magnus,
Using a second counter (my famous Picotest U6200A) locked to the
reference output of the DIY counter and measuring the output of the
signal generator and also set to gate of 10 s it is confirmed that the
frequency pulling (if any) is below 1E-11 (not more digits on the
display of the U6200A)
Generator is set to 10.000,000,000,2 MHz and is measured as such by
the U6200A
As there seems to be no frequency pulling I went back to the
simulation of the linear regression algorithm and discovered that when
there is a integer divide/multiply relation between the internal
reference and the measured frequency the regression looses some accuracy.
For sure if the reference is close to an integer multiple of the
measured frequency (10 Mhz measured -> 200 MHz reference) the
regression collapses completely in accuracy. I hoped that by creating
a fractional relation this collapse would not happen at 10 MHz but is
still there, although much smaller. For this test I'm using a "div 3
times 64 e.g. 213.333,333,333,333... MHz" internal reference frequency
derived from the external 10MHz reference. Ton van Baak warned me
against using fractional relations in a counter but otherwise it is
impossible to measure a 10 MHz input signal with any accuracy without
a HW time to digital as the interpolation no longer works. I can
switch dynamically to 200 MHz or 245 MHz reference and these produce
much much worse results.
I realize this test only measures if the TCXO used as reference in the
DIY counter does not show frequency pulling but it does not show if
the PLL used to convert the 10MHz to 213.333333333... MHz for the
internal counters shows any frequency pulling.
NOt
Erik.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
> the measured frequency the regression looses some accuracy.
Yes, the hp/Agilent/Keysight 53132A does that too. Here's the footnote
from the user manual:
http://leapsecond.com/pages/53132/53132-reduced-resolution.gif
And it's not just at 10 MHz. Any fraction or multiple within 600 ppb is
affected too. What impressed me is that the hp firmware engineers
specifically detected this condition and reduced the number of digits
displayed accordingly. This avoids the user from getting a false sense
of precision.
> Tom Van Baak warned me against using fractional relations in
> a counter but otherwise it is impossible to measure a 10 MHz
> input signal with any accuracy without a HW time to digital
> as the interpolation no longer works.
Right, which is probably why many high-end commercial counters use
interpolators. But you aren't, and that's ok because your design spec is
on the order of 9 digits. Keep it simple. Later if you design a 10 or 11
or 12 digit counter you'll have to resort to using h/w interpolation as
well. Even the Lars GPSDO uses a crude interpolator; it's not that
difficult. Many threads in the time-nuts archive on the topic.
----
Your slow sweeping experiments reminded me of a great example I once ran
into. So I wrote it up with photos and plots:
http://leapsecond.com/pages/racal/
http://leapsecond.com/pages/racal/stdev.htm
Even if you aren't building a frequency counter, this strange event is
quite interesting. One of the plots is attached; the rest are in the URL
above.
/tvb
On 8/4/2022 11:04 AM, Erik Kaashoek via time-nuts wrote:
> Bob, Magnus,
>
> Using a second counter (my famous Picotest U6200A) locked to the
> reference output of the DIY counter and measuring the output of the
> signal generator and also set to gate of 10 s it is confirmed that the
> frequency pulling (if any) is below 1E-11 (not more digits on the
> display of the U6200A)
> Generator is set to 10.000,000,000,2 MHz and is measured as such by
> the U6200A
> As there seems to be no frequency pulling I went back to the
> simulation of the linear regression algorithm and discovered that when
> there is a integer divide/multiply relation between the internal
> reference and the measured frequency the regression looses some accuracy.
> For sure if the reference is close to an integer multiple of the
> measured frequency (10 Mhz measured -> 200 MHz reference) the
> regression collapses completely in accuracy. I hoped that by creating
> a fractional relation this collapse would not happen at 10 MHz but is
> still there, although much smaller. For this test I'm using a "div 3
> times 64 e.g. 213.333,333,333,333... MHz" internal reference frequency
> derived from the external 10MHz reference. Ton van Baak warned me
> against using fractional relations in a counter but otherwise it is
> impossible to measure a 10 MHz input signal with any accuracy without
> a HW time to digital as the interpolation no longer works. I can
> switch dynamically to 200 MHz or 245 MHz reference and these produce
> much much worse results.
> I realize this test only measures if the TCXO used as reference in the
> DIY counter does not show frequency pulling but it does not show if
> the PLL used to convert the 10MHz to 213.333333333... MHz for the
> internal counters shows any frequency pulling.
> NOt
> Erik.
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
