Hi Oleg,
On 06/06/2018 02:53 PM, Oleg Skydan wrote:
> Hi, Magnus!
>
> Sorry for the late answer, I injured my left eye last Monday, so had
> very limited abilities to use computer.
Sorry to hear that. Hope you heal up well and quick enough.
> From: "Magnus Danielson"
>> As long as the sums C
Hi, Magnus!
Sorry for the late answer, I injured my left eye last Monday, so had very
limited abilities to use computer.
From: "Magnus Danielson"
As long as the sums C and D becomes correct, your
path to it can be whatever.
Yes. It produces the same sums.
Yes please do, then I can
It appears that I replied to the wrong message, please ignore.
Glenn
On 5/27/2018 11:52 AM, Oleg Skydan wrote:
Hi!
From: "Magnus Danielson"
You build two sums C and D, one is the phase-samples and the other is
phase-samples scaled with their index n in the block.
The MSDS is here:
https://simplegreen.com/data-sheets/
They claim that it is non reactive and chemically stable.
It is for water tolerant surfaces and should be rinsed.
Probably due to the citric acid.
Glenn
On 5/27/2018 11:52 AM, Oleg Skydan wrote:
Hi!
From: "Magnus Danielson"
Hi Oleg,
On 05/27/2018 05:52 PM, Oleg Skydan wrote:
> Hi!
>
>>> It looks like the proposed method of decimation can be
>>> efficiently realized on the current HW.
>
> I had some free time yesterday and today, so I decided to test the new
> algorithms on the real hardware (the HW is still an old
Hi!
From: "Magnus Danielson"
You build two sums C and D, one is the phase-samples and the other is
phase-samples scaled with their index n in the block. From this you can
then using the formulas I provided calculate the least-square phase and
frequency, and using
Hi!
--
From: "Magnus Danielson"
From the 2.5 ns single shot resolution, I deduce a 400 MHz count
clock.
Yes. It is approx. 400MHz.
OK, good to have that verified. Free-running or locked to a 10 MHz
reference?
Hi Oleg,
On 05/18/2018 12:25 AM, Oleg Skydan wrote:
> Hi, Magnus!
>
> --
> From: "Magnus Danielson"
>>> 2. Study how PDEV calculation fits on the used HW. If it is possible to
>>> do in real time PDEV option can be
Hi, Magnus!
--
From: "Magnus Danielson"
2. Study how PDEV calculation fits on the used HW. If it is possible to
do in real time PDEV option can be added.
You build two sums C and D, one is the phase-samples and the
Hi,
On 05/13/2018 11:13 PM, Oleg Skydan wrote:
> Hi Magnus,
>
> From: "Magnus Danielson"
>> I would be inclined to just continue the MDEV compliant processing
>> instead. If you want the matching ADEV, rescale it using the
>> bias-function, which can be derived out
Hi
From: "Bob kb8tq"
What I’m suggesting is that if the hardware is very simple and very cheap,
simply put two chips on the board.
One runs at Clock A and the other runs at Clock B. At some point in the
process you move the decimated data
from B over to A and finish out all
Hi
> On May 14, 2018, at 1:50 PM, Oleg Skydan wrote:
>
> Hi!
>
> From: "Bob kb8tq"
>>> If such conditions detected, I avoid problem by changing the counter clock.
>>> But it does not solve the effects at "about OCXO" * N or "about OCXO" / M.
>>> It is
Hi!
From: "Bob kb8tq"
If such conditions detected, I avoid problem by changing the counter
clock. But it does not solve the effects at "about OCXO" * N or "about
OCXO" / M. It is related to HW and I can probably control it only
partially. I will try to improve clock and
Hi
> On May 14, 2018, at 5:25 AM, Oleg Skydan wrote:
>
> Hi Bob!
>
> From: "Bob kb8tq"
>>> I think it will be more than enough for my needs, at least now.
>>>
From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock.
>>>
>>> Yes. It is
Hi Bob!
From: "Bob kb8tq"
I think it will be more than enough for my needs, at least now.
From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock.
Yes. It is approx. 400MHz.
I think I would spend more time working out what happens at “about 400
MHz” X N or
Hi
> On May 13, 2018, at 5:13 PM, Oleg Skydan wrote:
>
> Hi Magnus,
>
> From: "Magnus Danielson"
>> I would be inclined to just continue the MDEV compliant processing
>> instead. If you want the matching ADEV, rescale it using the
>>
Hi Magnus,
From: "Magnus Danielson"
I would be inclined to just continue the MDEV compliant processing
instead. If you want the matching ADEV, rescale it using the
bias-function, which can be derived out of p.51 of that presentation.
You just need to figure out the
Hi,
On 05/13/2018 08:09 PM, Bob kb8tq wrote:
>>> If so, that raises a whole added layer to this discussion in terms of “does
>>> it do
>>> what it says it does?”.
>>
>> This question is also important for amateur/hobby measurement equipment. I
>> do not need equipment that "does not do what it
Hi
> On May 13, 2018, at 1:31 PM, Oleg Skydan wrote:
>
> Hi Bob!
>
> From: "Bob kb8tq"
>> I guess it is time to ask:
>>
>> Is this a commercial product you are designing?
>
> No. I have no abilities to produce it commercially and I see no market for
>
Hi Bob!
From: "Bob kb8tq"
I guess it is time to ask:
Is this a commercial product you are designing?
No. I have no abilities to produce it commercially and I see no market for
such product. I will build one unit for myself, I may build several more
units for friends or if
Hi
I guess it is time to ask:
Is this a commercial product you are designing?
If so, that raises a whole added layer to this discussion in terms of “does it
do
what it says it does?”.
Bob
> On May 13, 2018, at 3:07 AM, Oleg Skydan wrote:
>
> Hi Bob!
>
> From: "Bob
Hi Oleg,
On 05/13/2018 09:31 AM, Oleg Skydan wrote:
> Hi Magnus!
>
> From: "Magnus Danielson"
>>> The leftmost tau values are skipped and they "stay" inside the counter.
>>> If I setup counter to generate lets say 1s stamps (ADEV starts at 1s) it
>>> will generate
Hi Magnus!
From: "Magnus Danielson"
The leftmost tau values are skipped and they "stay" inside the counter.
If I setup counter to generate lets say 1s stamps (ADEV starts at 1s) it
will generate internally 1/8sec averaged measurements, but export
combined data for
Hi Bob!
From: "Bob kb8tq"
It’s only useful if it is accurate. Since you can “do code” that gives you
results that are better than reality,
simply coming up with a number is not the full answer. To be useful as
ADEV, it needs to be correct.
I understand it, so I try to
On 05/12/2018 09:41 PM, Bob kb8tq wrote:
> Hi
>
>
>> On May 12, 2018, at 1:20 PM, Oleg Skydan wrote:
>>
>> Hi!
>>
>> From: "Bob kb8tq"
>>> There is still the problem that the first post on the graph is different
>>> depending
>>> on the technique.
>>
>>
Hi,
On 05/12/2018 08:38 PM, Oleg Skydan wrote:
> Hi!
>
> From: "Magnus Danielson"
>> ADEV assumes brick-wall filtering up to the Nyquist frequency as result
>> of the sample-rate. When you filter the data as you do a Linear
>> Regression / Least Square estimation,
Hi
> On May 12, 2018, at 1:20 PM, Oleg Skydan wrote:
>
> Hi!
>
> From: "Bob kb8tq"
>> There is still the problem that the first post on the graph is different
>> depending
>> on the technique.
>
> The leftmost tau values are skipped and they "stay"
Hi Oleg,
On 05/12/2018 07:20 PM, Oleg Skydan wrote:
> Hi!
>
> From: "Bob kb8tq"
>> There is still the problem that the first post on the graph is
>> different depending
>> on the technique.
>
> The leftmost tau values are skipped and they "stay" inside the counter.
> If I setup
Hi!
From: "Magnus Danielson"
ADEV assumes brick-wall filtering up to the Nyquist frequency as result
of the sample-rate. When you filter the data as you do a Linear
Regression / Least Square estimation, the actual bandwidth will be much
less, so the ADEV measures
Hi!
From: "Bob kb8tq"
There is still the problem that the first post on the graph is different
depending
on the technique.
The leftmost tau values are skipped and they "stay" inside the counter. If I
setup counter to generate lets say 1s stamps (ADEV starts at 1s) it will
Hi,
On 05/11/2018 05:35 PM, Bob kb8tq wrote:
> Hi
>
> If you do the weighted average as indicated in the paper *and* compare it to
> a “single sample” computation,
> the results are different for that time interval. To me that’s a problem. To
> the authors, the fact that the rest of
> the
Oleg,
On 05/11/2018 04:42 PM, Oleg Skydan wrote:
> Hi
>
> --
> From: "Bob kb8tq"
>> The most accurate answer is always “that depends”. The simple answer
>> is no.
>
> I have spent the yesterday evening and quite a bit of the night
Hi Dana,
On 05/10/2018 06:17 PM, Dana Whitlow wrote:
> I'm a bit fuzzy, then, on the definition of ADEV. I was under the
> impression that one measured a series of
> "phase samples" at the desired spacing, then took the RMS value of that
> series, not just a single sample,
> as the ADEV value.
Oleg,
On 05/10/2018 10:46 AM, Oleg Skydan wrote:
> Hi
>
> Now I have some questions. As you know I am experimenting with the
> counter that uses LR calculations to improve its resolution. The LR data
> for each measurement is collected during the gate time only, also
> measurements are
Hi
If you do the weighted average as indicated in the paper *and* compare it to a
“single sample” computation,
the results are different for that time interval. To me that’s a problem. To
the authors, the fact that the rest of
the curve is the same is proof that it works. I certainly agree
Hi
--
From: "Bob kb8tq"
The most accurate answer is always “that depends”. The simple answer is
no.
I have spent the yesterday evening and quite a bit of the night :) reading
many interesting papers and several related
Hi
> On May 10, 2018, at 1:44 PM, Oleg Skydan wrote:
>
> Bob, thanks for clarification!
>
> From: "Bob kb8tq"
>> If you collect data over the entire second and average that down for a
>> single point, then no, your ADEV will not be correct.
>
> That
Bob, thanks for clarification!
From: "Bob kb8tq"
If you collect data over the entire second and average that down for a
single point, then no, your ADEV will not be correct.
That probably explains why I got so nice (and suspicious) plots :)
There are a number of papers on
Hi
More or less:
ADEV takes the *difference* between phase samples and then does a standard
deviation on them. RMS of the phase samples makes a lot of sense and it was
used back in the late 50’s / early 60’s. The gotcha turns out to be that it is
an
ill behaved measure. The more data you
I'm a bit fuzzy, then, on the definition of ADEV. I was under the
impression that one measured a series of
"phase samples" at the desired spacing, then took the RMS value of that
series, not just a single sample,
as the ADEV value.
Can anybody say which it is? The RMS approach seems to make
Hi
If you collect data over the entire second and average that down for a single
point, then no, your ADEV will not be correct.
There are a number of papers on this. What ADEV wants to see is a single phase
“sample” at one second spacing. This is
also at the root of how you get 10 second ADEV.
Hi
I have got a pair of not so bad OCXOs (Morion GK85). I did some
measurements, the results may be interested to others (sorry if not), so I
decided to post them.
I ran a set of 5minutes long counter runs (two OCXOs were measured against
each other), each point is 1sec gate frequency
The CNT91 is really a CNT90 with some detailed improvements to reduce
time-errors to be conform with 50 ps rather than 100 ps resolution.
In the CNT90 the comparators where in the same IC, which caused
ground-bounce coupling between channels, but separating them was among
the things that went in.
Hi
As you have noticed already, it is amazingly easy to get data plots with more
than the
real number and less than the real number of digits. Only careful analysis of
the underlying
hardware and firmware will lead to an accurate estimate of resolution.
This is by no means unique to what
Hi
From: "Bob kb8tq"
Sent: Friday, April 27, 2018 4:38 PM
Consider a case where the clocks and signals are all clean and stable:
Both are within 2.5 ppb of an integer relationship. ( let’s say one is 10
MHz and the other is 400 MHz ). The amount of information in your
data
From: "Azelio Boriani"
Sent: Friday, April 27, 2018 12:16 AM
If your hardware is capable of capturing up to 10 millions of
timestamps per second and calculating LR "on the fly", it is not a so
simple hardware, unless you consider simple hardware a 5megagates
Spartan3
Hi
So what’s going on here?
With any of a number of modern (and not so modern) FPGA’s you can run a clock
in the 400 MHz region.
Clocking with a single edge gives you a 2.5 ns resolution. On some parts, you
are not limited to a single
edge. You can clock with both the rising and falling
i" <azelio.bori...@gmail.com>
> To: "Discussion of precise time and frequency measurement"
> <time-nuts@febo.com>
> Sent: Friday, April 27, 2018 7:39 AM
> Subject: Re: [time-nuts] Question about frequency counter testing
>
>
> You can measure your clocks
sage -
From: "Azelio Boriani" <azelio.bori...@gmail.com>
To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com>
Sent: Friday, April 27, 2018 7:39 AM
Subject: Re: [time-nuts] Question about frequency counter testing
You can measure your clocks do
You can measure your clocks down to the ps averaged resolution you
want only if they are worse than your one-shot base resolution one WRT
the other. In a resonable time, that is how many transitions in your
2.5ns sampling interval you have in 1 second to have a n-digit/second
counter.
On Fri, Apr
Yes, this is the problem when trying to enhance the resolution from a
low one-shot resolution. Averaging 2.5ns resolution samples can give
data only if clocks move one with respect to the other and "cross the
boundary" of the 2.5ns sampling interval. You can measure your clocks
down to the ps
> That might be an interesting way to analyze TICC data. It would work
> better/faster if you used a custom divider to trigger the TICC as fast as it
> can print rather than using the typical PPS.
Hi Hal,
Exactly correct. For more details see this posting:
Hi
Consider a case where the clocks and signals are all clean and stable:
Both are within 2.5 ppb of an integer relationship. ( let’s say one is 10
MHz and the other is 400 MHz ). The amount of information in your
data stream collapses. Over a 1 second period, you get a bit better than
9
olegsky...@gmail.com said:
> No, it is much simpler. The hardware saves time-stamps to the memory at each
> (event) rise of the input signal (let's consider we have digital logic input
> signal for simplicity). So after some time we have many pairs of {event
> number, time-stamp}. We can plot
Hi
The degree to which your samples converge to a specific value while being
averaged
is dependent on a bunch of things. The noise processes on the clock and the
measured
signal are pretty hard to avoid. It is *very* easy to over estimate how fast
things converge.
Bob
> On Apr 26, 2018, at
If your hardware is capable of capturing up to 10 millions of
timestamps per second and calculating LR "on the fly", it is not a so
simple hardware, unless you consider simple hardware a 5megagates
Spartan3 (maybe more is needed). Moreover: if your clock is, say, at
most in an FPGA, 300MHz, your
From: "Hal Murray"
Sent: Thursday, April 26, 2018 10:28 PM
Is there a term for what I think you are doing?
I saw different terms like "omega counter" or multiple time-stamp
average counter, probably there are others too.
If I understand (big if), you are doing the
olegsky...@gmail.com said:
> The plots I showed were made with approx. 5*10^6 timestamps per second, so
> theoretically I should get approx. 4ps equivalent resolution (or 11+
> significant digits in one second).
Is there a term for what I think you are doing?
If I understand (big if), you
Hi
Even with a fast counter, there are going to be questions about clock jitter
and just
how well that last digit performs in the logic. It’s never easy to squeeze the
very last
bit of performance out …..
Bob
> On Apr 26, 2018, at 3:06 AM, Azelio Boriani wrote:
>
From: "Azelio Boriani"
Sent: Thursday, April 26, 2018 10:06 AM
Very fast time-stamping like a stable 5GHz counter?
No, it is not 5GHz counter. It does the trick I first saw in CNT91
counters. The hardware is capable of capturing up to 10 millions
of timestamps per
Very fast time-stamping like a stable 5GHz counter? The resolution of
a 200ps (one shot) interpolator can be replaced by a 5GHz
time-stamping counter.
On Thu, Apr 26, 2018 at 12:28 AM, Bob kb8tq wrote:
> Hi
>
> Unfortunately there is no “quick and dirty” way to come up with an
Hi
Unfortunately there is no “quick and dirty” way to come up with an accurate
“number of digits” for a
math intensive counter. There are a *lot* of examples of various counter
architectures that have specific
weak points in what they do. One sort of signal works one way, another signal
works
Dear Ladies and Gentlemen,
Let me tell a little story so you will be able to better understand what my
question and what I am doing.
I needed to check frequency in several GHz range from time to time. I do not
need high absolute precision (anyway this is a reference oscillator problem,
not
63 matches
Mail list logo