You may want to have a look at http://www.efos3.com/53230A/HPAK53230A-1.html

Ole

Somewhat longer answer; I assume you have set up a frequency measurement
(as opposed to time interval)

1. Timelab uses SCPI-command "READ" to fetch readings from the 53230a (and
   most other counters *). The 53230a does not return gap free frequency
   measurements in this case. There will be deadtime which will be ignored, as
   you say, but the measurements will also be biased. In addition, the
   CONTinous gap free mode is broken when it comes to ADEV, as has been
   documented elsewhere. From my experience, using the 53230a in a time
   interval measurement takes care of these issues, at the expense of a
   slighly more cumbersome setup.

2. You may know this, but from your text it could be a misunderstanding:
   timelab does not configure the instrument; whichever sample interval you
   select in timelab should match the sample interval you have set up the
   53230a to use.

3. Regarding the ADEV number discrepancy; are the measurements made at the
   same time? For "long enough"? (The numbers jump all over the place before
   they settle down, thats normal from my experience.)

Of course, theres the question of what reference you are measuring against.

Ole

• at least this was the case the last  time I checked, but I have not
  looked at the source for 1.31 to verify.

On Thu, Oct 4, 2018 at 7:42 AM AC0XU (Jim) James.Schatzman@ac0xu.com
wrote:

Hi,

On 10/4/18 8:56 AM, Ole Petter Ronningen wrote:

Regardless, the 53230A does a filtered frequency estimation, which is
great for achieving high precision frequency measures quickly, but not
good for ADEV measures, as it introduces a bias due to the lower
bandwidth of the filtering as compared to the sampling interval.
Dead-time gaps biases also comes in.

For any software (TimeLab or Stable32) to process sufficiently unbiased
values, only phase values should be used to avoid both the filtering and
dead-time gap issues.

TimeLab actually assumes that the user really know what they are doing,
but attempts to assist in the overall task. Adding a instrument
configuration tool into TimeLab would be possible, but for most part
consider the configuration you do for a measurement the opportunity to
input to TimeLab under which conditions the measurement was done, how
the instrument was setup etc. From there it just consumes measurements,
scales them according to the configuration, unwrapp phase etc. prior to
record the measurement record that is then used for analysis.

One of the great learning experiences you can get from TimeLab is how
the real-time update of ADEV swings in the highest tau range of the
plot, but as more samples comes in, the same tau range becomes less
uncertain, the confidence bounds (chi-square based) goes down and
TimeLab illustrates this very nicely. Thus, one wants to have enough
samples before judging too much of a value. It's experience one has to
built.

Always. It is always good to look at specs and other measurements to see
if the measurement is reasonably in compliance with what one can expect
from other measurements. Even with very good instruments that does a lot
to solve the measurement problem, you always needs to validate it and
check it. One need to understand how the measurement instrument and
processing will impact the value and understand what part of this is
needed to get "proper" value and what is various forms of impairments.

Cheers,
Magnus

On Thu, Oct 4, 2018 at 11:00 AM Magnus Danielson magnus@rubidium.dyndns.org
wrote:

True - but be aware that the first sample returned from the instrument,
when fetched using "READ", will also be biased in an absolute sense - the
frequency reported will systematically be too high or too low (the
magnitude and direction of the error depending primarily on gate time, from
what I've seen).

So even when using this mode to only look at high resolution "absolute
frequency measurements", it is easy to get bitten if the data is collected
using a computer.

BR,
Ole

Hej Ole!

On 10/4/18 11:21 AM, Ole Petter Ronningen wrote:

Who-oh! OK. This means that one should intentionally let a number of
samples pass before trusting it.

It would be interesting to get some better qualifications of this.

Obviously. Good to know. Many thanks!

It is interesting to learn that we still need to handle the temperament
of instruments.

Cheers,
Magnus

On Thu, Oct 4, 2018 at 1:40 PM Magnus Danielson magnus@rubidium.dyndns.org
wrote:

Precisely. But, crucially, discard 1-2 samples since the last INIT -
which may not be obvious without some investigation. It is a bit
convoluted, but the behaviour is easily observed using TimeLab: Feed the
counter the same 10  MHz signal both on the EXTernal REFerence, and channel

1. Set up a frequency measurement, and collect data using timelab. Observe
   the phaseplot (taking care to NOT have the phase plot in "residual mode").

After a few minutes, a slope will be observed on the phase plot that should
not be there - it is measuring its own reference, so the plot should be
pretty much dead flat over a sufficiently long interval. It is because
timelab calls READ every time it wants a sample, and the instrument returns
a biased frequency estimate. Shorter gate-times, steeper slope.

It would be interesting to get some better qualifications of this.

I have attempted to make a thorough writeup on the previously mentioned
http://www.efos3.com/53230A/HPAK53230A-1.html Also parts 2 and 3 - in
short, the behaviour has been observed on three separate instruments. The
data is available for download on my website. Oh, and Keysight has
acknowledged the issue, but not offered anything towards a solution.

Ole

Hi

Probably also worth mentioning:

For short tau, you are probably measuring the ADEV of the counter noise floor rather than the
ADEV of the GPSDO. Yes, there are noisy GPSDO’s out there but most of what you run into
is not in that category.

Bob