@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 ad
Hi Chris.
As Tom said before these units are cheap and abundant because they can
not be used as time reference even if you do find an antenna.
To make things worse the antenna itself is active (i.e. amplified) with
a down converter that will bring down the 468 MHz signal frequency to
around
I used to own/use a 468-DC. They are, unfortunately, useless now
because NOAA stopped transmitting the UHF-based time code over the GOES
satellites in the early 2000's (this is, very likely, why it was so cheap).
In short ... Even if you got a perfect antenna for the unit,
there's noth
Hi Chris,
Sorry, a 468 MHz GOES antenna won't help. That satellite timing service
ended 15+ years ago, another victim to the global success of GPS. So
antenna or not, the receiver has no signal to lock on to. That's why the
receivers are so cheap these days. There may be old postings in the ti
I'm new to the group. I'm looking for an antenna for a Kinemetrics
468-DC. I only paid a few bucks for the unit and all the surplus
companies want 800-900USD for an antenna.
Does anyone have a source for a reasonably priced antenna, or, has
anyone built one that they would care to share the deta
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?
https://pendulum-instruments.com/wp-content/uploads/2
On 10.01.22 16:23, Lux, Jim wrote:
And I suppose this is why it's worth talking to the mfr than looking
through the catalogs. There might well be some key requirement that if
relaxed slightly would work out quite well in terms of availability.
We run into this all the time in the space busin
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 o
@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 st
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 mea
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
> m
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
the
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 counter
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 issues.
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. Pen
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 allo
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 with
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.
> C
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
21 matches
Mail list logo