Hi
The whole dead zone / interaction thing is as much layout dependent
as it is circuit related. Even the guys at HP / Agilent / Keysight seem
to struggle on and on with this. The 10 MHz input to the clock
system has created issues for a *long* time.
Bob
> On Feb 1, 2022, at 9:30 AM, Erik
Bob,
Thanks for the feedback, always welcome.
I recognize HW is an important topic that requires a lot of attention.
With respect to the harmonic interaction. How "close" do you think the
input and the clock need to be for the interaction to start? With a
200MHz clock, does that leave some
Hi
The main point about “added hardware” is that this *is* how a counter
gets from the numbers I mentioned to performance that is better than
that. It’s not done by running some magic math that somehow improves
a basic sampling counter by a couple orders of magnitude.
Since that hardware is
@Bob
Yes, the resolution provided with the HW is a given and is good enough
so I am most interested in those well known techniques to improve on it.
Can you provide some pointers?
I am aware of techniques like analog interpolation and time to data to
improve the accuracy but these required
On 1/2/22 04:00, Attila Kinali wrote:
[1] "New frequency counting principle improves resolution", by Johanson, 2005
https://doi.org/10.1109/FREQ.2005.1574007
(there was a non-paywalled version of this, but the link has gone away)
Is this it?
Erik,
On 2022-01-31 22:17, Erik Kaashoek wrote:
@Magnus
The time interval of the capturing of the counters is not always exactly
the same. There could be even substantial variation if the capture interval
is close to the event interval. Is this a problem for the calculation
method you propose?
Hi
What you run into on a lot of setups are dead bands. You get a series
of (effectively) same / same /same /same sample groups. Applying math
to them gives you the (obvious) result … everything is perfect.
If you have (say) a 200 MHz clock, your data will be “chunked” into 5 ns
spaced buckets
@Magnus
The time interval of the capturing of the counters is not always exactly
the same. There could be even substantial variation if the capture interval
is close to the event interval. Is this a problem for the calculation
method you propose?
Erik
In the nist documents a separation is made between a measurement device
that provides single observations spaced in time and the statistical
processing that uses these observations over a long time period. My focus
is the on methods to come to the best possible single observation as input
to the
Erik,
On 2022-01-31 20:32, Erik Kaashoek wrote:
Thanks all for the good input.
@Magnus, I need some time to understand the math as it has been over 30
years since when I used to do this kind of math.
There is no intention to store the collected captures, only to present a
measurement at the
Hi
> On Jan 31, 2022, at 2:32 PM, Erik Kaashoek wrote:
>
> Thanks all for the good input.
>
> @Magnus, I need some time to understand the math as it has been over 30
> years since when I used to do this kind of math.
> There is no intention to store the collected captures, only to present a
>
Thanks all for the good input.
@Magnus, I need some time to understand the math as it has been over 30
years since when I used to do this kind of math.
There is no intention to store the collected captures, only to present a
measurement at the measurement interval, so currently I'm calculating
On Mon, 31 Jan 2022 17:42:38 +0100
Erik Kaashoek wrote:
> he clock is a 200MHz perfect clock.
> The events come from an unknown quality XCO at 10 MHz
> The measurement interval is 0.1 seconds
> The goal is to derive the phase (and also the frequency) of the XCO versus
> the clock from the
Hi
One thing that is still unclear: Why do you have two clocks tagging
the events?
You have a simple crystal oscillator and are looking at 0.1 seconds.
That oscillator likely “bounces around” ( = has a noise floor) at about
1x10^-8 or so. Indeed, your “perfect” clock likely has similar
On Sun, 30 Jan 2022 12:46:19 +0100
Erik Kaashoek wrote:
> 1: Is using linear regression as described above a good method to
> calculate the phase relation between events and clock? If not, what
> method to use?
Yes, it is. You can see each measurment as an statistically independent
sample.
Excellent questions.
The goal is to measure with a certain interval the phase of repetitive
events versus a clock.
The clock is assumed to be perfect. Also the counters are assumed to be
perfect.
The events can change their frequency and phase but any change within one
measurement interval is
Hi Erik,
On 2022-01-30 12:46, Erik Kaashoek wrote:
In a timestamping counter I'm trying to calculate phase and frequency
using statistical techniques.
The counter has two counters, one for the input events and one for an
internal clock.
The capturing of these counters happens synchronized
HI
> On Jan 31, 2022, at 10:23 AM, Erik Kaashoek wrote:
>
> There was a small error in my previous post
>
> Here are the complete and corrected numbers
> Below table shows:
>
> Event counter(Y) : The exact count of events since the start of the counter
> captured at the time of the event.
>
There was a small error in my previous post
Here are the complete and corrected numbers
Below table shows:
Event counter(Y) : The exact count of events since the start of the
counter captured at the time of the event.
Clock Counter(X) : The clock cycles since the start of the counter
captured
19 matches
Mail list logo
