Thanks Tom,

The "front end" is still 75ALS176, but I put another simple transistor
circuit from wenzel to to compare the performance.
http://www.wenzel.com/wp-content/uploads/diffsqr.gif

2014-12-12 17:04 GMT+08:00, Tom Van Baak tvb@leapsecond.com:

HI

Very nice looking. I hope it works !!!

Be careful pre-processing ADEV data. There are a variety of statistical “traps” you can fall into. An overly simple explanation is that ADEV looks at noise and that most pre-processing is a filter. Filters take out noise. Finding one that only takes out the “bad noise” and keeps the “good noise” can be quite difficult.

What exactly are you doing in your linear regression computation?

Bob

Hi Bob,
The job done by linear regression is to reduce the uncertainty. This
counter is designed to use continous timestamp method. My current design
can measure 9000 times/second. If I only use the 1st and last one to
calculate, it's the traditional recipocal + interploator method. This is
what you can see on the chart named "without linear regression". The
uncertainty of slope(the frequency ratio of ref and signal ) is contributed
by these 2 measurements. With linear regression of all 9000 data within one
second, the uncertainty will reduced to smaller one. (I really can't
remember the ratio. Something like sqrt(9000)).

while(1) {
double t3;  //fraction part of refcnt, measured by tdc_gp22
double ref_curr;
uint32_t sig_curr;
static double ref_start;
static uint32_t sig_start;
uint32_t refcnt, sigcnt;
const uint32_t gate_time = 1000; // 1000ms gate time

    if (i == 0) {
            init_regression(&rv);
            cpld_rst();
            timestamp(&refcnt, &sigcnt, &t3);
            ref_start = refcnt - t3;
            sig_start = sigcnt;
            i++;
            continue;
    }

    timestamp(&refcnt, &sigcnt, &t3);

    regression_enter_data(&rv, refcnt - t3 - ref_start, sigcnt - sig_start);
    if (msecond < gate_time) {
        i++;
        continue;
    } else  {
            t = regression_slope(&rv) ; // with linear regression
            printf("\r\nFreq=%.*f", 14, t);
            ref_curr = refcnt - t3;
            sig_curr = sigcnt;

            t = CalcFreq(ref_curr - ref_start, sig_curr -

sig_start); // without linear regression
printf(" Interpolated=%.*f", 12, t);

            msecond = 0;
          i = 0;
    }

}

2014-12-12 21:18 GMT+08:00 Bob Camp kb8tq@n1k.org:

Hi

… and in DSP terms, that’s a low pass filter. Counters very commonly do this sort of thing for noise reduction. It does mess up the ADEV statistics. That’s not to say you should not do it. You simply need to be careful when you look at the results.

Bob

Hi

In your original data:

Is the blue “5650 to 5650” trace looking at the same source for input and reference?

Is the green “PRS10 to 5650” trace looking at two independent sources (one reference and the other as input)?

I’m guessing that the answer is yes in both cases.

Bob

Yes, you are right. 5650_5650 is sig=ref case. prs10_5650 is sig=prs10 and
ref=5650 case.

Since I really want to reduce the noise, what is the best test set you
suggest? All the frequency source I have: FE5650 Rb , PRS10 Rb , MV89a2
OCXO, Thunderbolt GPSDO, 8663-XS2 OCXO, Wenzel 100M OCXO(not sure).

How to analyze the ADEV plot to get information about noise?

Thanks

2014-12-13 0:31 GMT+08:00 Bob Camp kb8tq@n1k.org:

Hi

In the “both same (5650 / 5650) case” your linear regression filtering is faking you out a bit. The SR620 counter has exactly this same issue. That’s probably for the same reason. It’s a fine test to see if you have various problems under control. It’s not a perfect way to estimate the number of digits you will get on a real measurement. Using two independent sources is a better way to do that.

When you have two identical signals, the TDC noise is the main issue. All the edges are arriving in the same relation to each other (same timing). The linear regression is (obviously) good at suppressing the sort of noise the TDC has. With two independent signals the noise is more complex. The edges arrive at various times relative to each other. More things contribute to the total noise. The linear regression is having a harder time suppressing that sort of noise. In some cases (as you observed) the linear regression is actually making things worse.

If Magnus was here, he would be tossing empty beer bottles at me and saying — see Bob, sqrt(N) doesn’t always work ….

The filtering process used does need to be adapted to the noise of the total system.

If the MV89’s are in good working condition, they are the best thing to compare.The have the best ADEV of the group you have available I would check them for output level and stability before I trusted them. There are a lot of defective parts on the market. People get some, sort them and sell the bad ones. The bad ones just keep getting re-sold again and again … My guess is that they were good parts at one time and they got damaged when pulled off boards. If you use them, keep them on power at all times. Any OCXO will do better if you run it that way.

Bob

Hi

Since you are running TimeLab, there are multiple plots you can do to look at what is going on. Each one will show you slightly different data. It’s probably best to look at all of them in order to work things out. So far, there is nothing obvious in your ADEV plots that points to a single issue.  That’s partially because of the short length of the runs. Most of the data seems to be going as 1/ sqrt( tau). That’s a lot like the sqrt (N) thing when averaging noise. It’s the expected result …

Bob

Hi Li,

What you're doing is the same "trick" the Pendulum CNT-91 uses, as well as modern Agilent frequency counters, and even my own picPET.

The good news is that for frequency measurement all those many samples and the sqrt(N) advantage allow you to measure the frequency far more accurately than with traditional methods. That's why a hp 53132A can rightly advertise "12 digits/second".

The bad news is that what you gain in frequency resolution you lose in temporal resolution. This is why in spite of having 1 ps/s frequency specs, the counter has 150 ps single-shot time resolution. What most time interval counters then do is average in order to gain precision. This works fine unless what you're trying to measure is not time, or even frequency, but frequency stability (modulation domain). In that case averaging may remove the very thing you are trying to measure.

As for ADEV, all you need is the raw phase data, even at 9000 points per second (USB is fast enough), and let TimeLab take care of the rest. It will properly scale, decimate, and filter the data to produce correct ADEV plots, from your minimum tau0 of 0.000111 s out any tau you want. You will quickly see the noise floor of the counter this way.

Some papers to read:

Continuous time stamping
http://www.spectracomcorp.com/Desktopmodules/Bring2Mind/DMX/Download.aspx?EntryId=450

Continuous Measurements with Zero Dead-Time in CNT-91
http://www.spectracomcorp.com/Desktopmodules/Bring2Mind/DMX/Download.aspx?EntryId=442
http://www.testmart.com/webdata/mfr_promo/whitepaper_cnt91.pdf

Modern frequency counting principles
http://www.npl.co.uk/upload/pdf/20060209_t-f_johansson_1.pdf

New frequency counting principle improves resolution
http://tycho.usno.navy.mil/ptti/2005papers/paper67.pdf
http://www.spectracomcorp.com/Desktopmodules/Bring2Mind/DMX/Download.aspx?EntryId=446

Time & Frequency Measurements for Oscillator Manufacturers using CNT-91
http://www.spectracomcorp.com/Desktopmodules/Bring2Mind/DMX/Download.aspx?EntryId=444

/tvb

----- Original Message -----
From: "Li Ang" lllaaa@gmail.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Friday, December 12, 2014 7:40 AM
Subject: Re: [time-nuts] Homebrew frequency counter, need help

Hi Bob,
The job done by linear regression is to reduce the uncertainty. This
counter is designed to use continous timestamp method. My current design
can measure 9000 times/second. If I only use the 1st and last one to
calculate, it's the traditional recipocal + interploator method. This is
what you can see on the chart named "without linear regression". The
uncertainty of slope(the frequency ratio of ref and signal ) is contributed
by these 2 measurements. With linear regression of all 9000 data within one
second, the uncertainty will reduced to smaller one. (I really can't
remember the ratio. Something like sqrt(9000)).

while(1) {
double t3;  //fraction part of refcnt, measured by tdc_gp22
double ref_curr;
uint32_t sig_curr;
static double ref_start;
static uint32_t sig_start;
uint32_t refcnt, sigcnt;
const uint32_t gate_time = 1000; // 1000ms gate time

    if (i == 0) {
            init_regression(&rv);
            cpld_rst();
            timestamp(&refcnt, &sigcnt, &t3);
            ref_start = refcnt - t3;
            sig_start = sigcnt;
            i++;
            continue;
    }

    timestamp(&refcnt, &sigcnt, &t3);

    regression_enter_data(&rv, refcnt - t3 - ref_start, sigcnt - sig_start);
    if (msecond < gate_time) {
        i++;
        continue;
    } else  {
            t = regression_slope(&rv) ; // with linear regression
            printf("\r\nFreq=%.*f", 14, t);
            ref_curr = refcnt - t3;
            sig_curr = sigcnt;

            t = CalcFreq(ref_curr - ref_start, sig_curr -

sig_start); // without linear regression
printf(" Interpolated=%.*f", 12, t);

            msecond = 0;
          i = 0;
    }

}

2014-12-12 21:18 GMT+08:00 Bob Camp kb8tq@n1k.org:

Li,

...

Note these two statements are at odds. On the one hand we all want to reduce noise. But ADEV is all about measuring noise, not making it go away. Think frequency instability (not frequency stability). On a log-log ADEV plot the top has more instability and the bottom has less instability.

Correct, for frequency measurements, the finer you can measure the slope the better. That's why linear regression is good for a continuous rolling average frequency counter.

But for instability measurements, it's not the slope but the small deviations around the slope that matter. In this case linear regression is not helpful. Instead just take the raw phase data, noise and all, and the ADEV/MDEV calculation takes care of all the rest.

/tvb

Hi Li Ang,

On 12/12/2014 04:40 PM, Li Ang wrote:

Bob's comment about filtering is correct. The lack of uncertainty is
partly systematic and partly white noise. As you filter it, as with
linear regression, you will weight samples with a parabolic value,
called the Omega filtering, and this will act as a low-pass filter. The
low-pass filter will alter the white-noise shape of the ADEV, as the
bandwidth have reduced. This is strictly predictable by the processing.
The produced ADEV curve is shaped by the measuring device and
processing, not by the DUT, so it's not showing the "real ADEV" of the
DUT, but it would not be doing that anyway. One such filtering mechanism
exists in MDEV, but it has established formulas for how noise-shapes
behave with various degrees of filtering, so therefore it is accepted as
a standard.

Regression filtering for frequency measures have already been done in
the Pendulum counter range, but not for phase measurements.

It's not as much as "right" or "wrong" as how you present the numbers
and interprent them.

Cheers,
Magnus

On 12/12/2014 06:15 PM, Bob Camp wrote:

Indeed, except I would not be tossing empty beer bottles at you, I might
jokingly attempt do, but never actually throw it. One has to realize
that the quantization noise of the TIC may seem to process as if it
where white phase noise, but it isn't random noise, it is a systematic
noise and if you fool around with the systematics is may work for you or
against you.

I do consider to pass another bottle of good beer to Bob for good
behavior. :)

It's one of the forgotten parameters, and I've even seen good Sam Stein
stand up and say "we used to do this wrong" on the same point, you need
to publish and consider the bandwidth of your processing, as it will
affect the ADEV plot (but only MDEV and TDEV somewhat).

In order to test if systematics is messing badly with you, measure the
ADEV of the oscillator as it is steered (and stabilized) to a number of
different frequencies. For larger offsets to the counter reference,
multiple beatings occurs within the regression interval. You want that
number to be an even number of beats, or the beat count to be so large
that the phase of the last beat does not care. Linear regression helps
out, as it weighs out the outermost measures compared to the central
one, making the beating at the beginning and end not care as much.

These are systematic noise effects, and as you play around with
systematics and processing, you might have the systematics works for or
against you, but at the same time, the random noise you try to measure
will suffer the processing filtering, and you need to recall that. If
you balance these properly, you can make good and correct measurements,
it's just that few do.

Oh, and only use ADEV, MDEV and TDEV to estimate random noises, system
noises as they show up there should be estimated separately and removed
from the random noise estimates. They have way different behaviors.

Cheers,
Magnus - considering what beer will be best to start the evening with

Hi

…. as long as we don’t start tossing kegs at each other, I consider myself lucky :)

… and this is where it gets complicated. I would toss in the Hadamard deviation into that mix as well. If I had to only use three, I would include it with modified ADEV (MDEV) and TDEV. All three are available in TimeLab with the click of a button. If you start getting lots of data (9,000 points per second) I would toss in a frequency domain (FFT) analysis as well. FFT on phase data is not (as far as I know) a feature of TimeLab.

To start with, on all of these measures, you are looking for bumps and spikes. They are telling you that something is wrong. If you flip over to the phase plot in TimeLab, spikes and abrupt steps in it also are telling you the same sort of thing. Exactly what this or that bump is telling you may not be obvious at first. Posting plots to the list is a great way to get things sorted out.

That means it’s 5 o’clock somewhere in the world …hmmm …. choice of beers … It’s winter over here, so the dark stuff is slowly taking over the inventory. I have a nasty suspicion that it’s winter in Sweden as well :). Probably something with stout in it’s name ….

Bob

Tom,

On 12/12/2014 08:01 PM, Tom Van Baak wrote:

This is a good overview. Staffan got some minor factoids wrong, but who
cares? It brings out the basic idea of history.

That ses of links is a good read. The HP Application note 200 series is
also a good read for counters in general.

Do notice Staffan's heads-up that you need to measure on stable signals,
as severer frequency drift will cause values to be, well a bit
interesting. The reason is that the linear regression used is for a
linear model and not quadratic model. Jim Barnes did an interesting
analysis, and it turns out that regression measurements can be a bad
solution for drift analysis.

The lesson that Staffan and Jim gives us is that just trying to apply
your favorit magic without understanding side-consequences of systematic
effects, may not give the effects you think.

Cheers,
Magnus

Hi Bob,

On 12/14/2014 06:00 PM, Bob Camp wrote:

Maybe empty, the beer will be so hard to tap if you throw full kegs,
even if full kegs have better impact to get the point through. :)

The Hadamard deviation is a great tool as it is not sensitive to linear
frequency drift as Allan deviation is. This would help to remove the
systematic effect, just as a quadratic curve-fitting of the raw-data and
ADEV of the residual.

Modified Hadamard deviation (MHDEV) is a good replacement for MDEV, with
the same properties for drift. Similarly will Time Hadarmard Deviation
(THDEV) replace TDEV. However, for longer taus you want better
processing, so therefore you want to consider the TOTAL set of
deviations, such that confidence intervals is better.

FFT on phase-data is only available in TimeLab when doing phase-noise
measurements. FFT is the way to analyse systematic noise rather than
random noise where ADEV and friends is being used. You need to separate
them, and the ADEV plot is not good for both.

There is a set of FFT based ADEV-style measures, which uses FFT,
filtering of the various ADEV styles. There is a nice set of articles
covering that approach, and actually the only style of ADEV processing
that I haven't yet implemented, even if I have done most others.

Bumps, spikes and slopes... ADEV isn't the only tool one should be
using, FFT might be much better for systematic noises.

In the end of the day, there is an overbeleife in ADEV both as a scale
as well as a processing tool, to analyze deviations, without considering
the separation of various systmeatic effect and systematic noises, while
ADEV and friends is there to analyze random noise types, it does not
handle systematics good. Seems like we have to kill ADEV as the
universal measure. Ah well.

Hibernation Ale from Great Divide Brewing in Denver, Colorado, USA was
the choice for the evening. Good beer for handling the winter.

Cheers,
Magnus