My DIY frequency counter and a request for help
Hello all,
First post here, so I'll start with a quick introduction. I trained as
an electronic engineer but don't work in that field any more, which has
given me the appetite back to do some electronic engineering as a
hobby. I have been a licensed ham for over 25 years (more than 60% of
my life I realised the other day) and used to be rather active on HF as
PA3DQW. At the moment I live in the UK where I am licensed as M0AIU.
I recently designed and build a frequency counter and I need some help
with verifying its performance. I believe it gives me 11 digits in 1
second. I say believe because I have not got the hardware to verify
this. At the moment my assumption is based on calculations and limited
testing with the equipment available to me.
My counter is a "continuous time stamping reciprocal counter". I
implemented this as a USB powered device, with the hardware taking the
time stamps and sending it over USB to a windows PC. Some software
written in C++ takes care of analysing the data.
The hardware takes 5000 time stamps per second using a high speed TDC.
The hardware is a single PCB measuring about 50 by 80 mm. it requires
an external 10MHz reference and apart from using this as the time base
it also uses this for self-calibration of the TDC. The unit requires no
further calibration.
The PC software takes these time stamps and the associated counts and
uses regression to calculate the slope. This slope represents the
frequency of the input signal. I am sure people on here are familiar
with the counters made by Pendulum, and I have to confess that their
marketing material was helpful in putting this thing together.
Since the hardware is true zero dead time, the final capabilities of
this counter are determined by software. At the moment I can
simultaneously display the input at multiple gate times (see the
attached screen shot). For gate times over 1 second I have the option
to use overlapping gates, so that the display gets updated every
second.
Because there is no dead time I can also calculate Allan Deviation. The
two displays at the bottom of the page show both normal and overlapping
Allan deviation at tau=10s. I am still working on the software to do
this at multiple tau in real time and display it as a graph and a
table.
So, after this lengthy introduction here is my request for some
assistance. Is there somebody on the list who can assist me in
verifying the performance of this frequency counter? Ideally somebody
with access to two highly stable and known frequency sources. I can
send the hardware by mail, but if there happens to be somebody with
this kind of gear not too far from where I am (50 north of London) I
will travel. In exchange you get to keep the hardware and will be
supplied with whatever software I come up with.
Thanks in advance and regards,
Gerard, PG5G
Hi Gerard,I'm not fully set up at the moment but if you've had no better offers I may be able to help.I'm located in Cambridge. My equipment includes a Thunderbolt GPSDO, two Efratom FRK-L Rubidiums, Oncore VP GPS, Phillips PM6654 time interval counter, Odetics satsync 325
GPSDO, Datum FTS-1000B OCXO and the usual 'scope, RF generator, spectrum analyser etc.
Robert G8RPI.
--- On Sat, 27/2/10, Gerard PG5G pg5g@b737.co.uk wrote:
From: Gerard PG5G pg5g@b737.co.uk
Subject: [time-nuts] My DIY frequency counter and a request for help
To: time-nuts@febo.com
Date: Saturday, 27 February, 2010, 9:36
Hello all,
First post here, so I'll start with a quick introduction. I trained as
an electronic engineer but don't work in that field any more, which has
given me the appetite back to do some electronic engineering as a
hobby. I have been a licensed ham for over 25 years (more than 60% of
my life I realised the other day) and used to be rather active on HF as
PA3DQW. At the moment I live in the UK where I am licensed as M0AIU.
I recently designed and build a frequency counter and I need some help
with verifying its performance. I believe it gives me 11 digits in 1
second. I say believe because I have not got the hardware to verify
this. At the moment my assumption is based on calculations and limited
testing with the equipment available to me.
My counter is a "continuous time stamping reciprocal counter". I
implemented this as a USB powered device, with the hardware taking the
time stamps and sending it over USB to a windows PC. Some software
written in C++ takes care of analysing the data.
The hardware takes 5000 time stamps per second using a high speed TDC.
The hardware is a single PCB measuring about 50 by 80 mm. it requires
an external 10MHz reference and apart from using this as the time base
it also uses this for self-calibration of the TDC. The unit requires no
further calibration.
The PC software takes these time stamps and the associated counts and
uses regression to calculate the slope. This slope represents the
frequency of the input signal. I am sure people on here are familiar
with the counters made by Pendulum, and I have to confess that their
marketing material was helpful in putting this thing together.
Since the hardware is true zero dead time, the final capabilities of
this counter are determined by software. At the moment I can
simultaneously display the input at multiple gate times (see the
attached screen shot). For gate times over 1 second I have the option
to use overlapping gates, so that the display gets updated every
second.
Because there is no dead time I can also calculate Allan Deviation. The
two displays at the bottom of the page show both normal and overlapping
Allan deviation at tau=10s. I am still working on the software to do
this at multiple tau in real time and display it as a graph and a
table.
So, after this lengthy introduction here is my request for some
assistance. Is there somebody on the list who can assist me in
verifying the performance of this frequency counter? Ideally somebody
with access to two highly stable and known frequency sources. I can
send the hardware by mail, but if there happens to be somebody with
this kind of gear not too far from where I am (50 north of London) I
will travel. In exchange you get to keep the hardware and will be
supplied with whatever software I come up with.
Thanks in advance and regards,
Gerard, PG5G
-----Inline Attachment Follows-----
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gerard PG5G wrote:
Hello all,
First post here, so I'll start with a quick introduction. I trained as
an electronic engineer but don't work in that field any more, which has
given me the appetite back to do some electronic engineering as a
hobby. I have been a licensed ham for over 25 years (more than 60% of
my life I realised the other day) and used to be rather active on HF as
PA3DQW. At the moment I live in the UK where I am licensed as M0AIU.
I recently designed and build a frequency counter and I need some help
with verifying its performance. I believe it gives me 11 digits in 1
second. I say believe because I have not got the hardware to verify
this. At the moment my assumption is based on calculations and limited
testing with the equipment available to me.
My counter is a "continuous time stamping reciprocal counter". I
implemented this as a USB powered device, with the hardware taking the
time stamps and sending it over USB to a windows PC. Some software
written in C++ takes care of analysing the data.
The hardware takes 5000 time stamps per second using a high speed TDC.
The hardware is a single PCB measuring about 50 by 80 mm. it requires
an external 10MHz reference and apart from using this as the time base
it also uses this for self-calibration of the TDC. The unit requires no
further calibration.
The PC software takes these time stamps and the associated counts and
uses regression to calculate the slope. This slope represents the
frequency of the input signal. I am sure people on here are familiar
with the counters made by Pendulum, and I have to confess that their
marketing material was helpful in putting this thing together.
Since the hardware is true zero dead time, the final capabilities of
this counter are determined by software. At the moment I can
simultaneously display the input at multiple gate times (see the
attached screen shot). For gate times over 1 second I have the option
to use overlapping gates, so that the display gets updated every
second.
Because there is no dead time I can also calculate Allan Deviation. The
two displays at the bottom of the page show both normal and overlapping
Allan deviation at tau=10s. I am still working on the software to do
this at multiple tau in real time and display it as a graph and a
table.
So, after this lengthy introduction here is my request for some
assistance. Is there somebody on the list who can assist me in
verifying the performance of this frequency counter? Ideally somebody
with access to two highly stable and known frequency sources. I can
send the hardware by mail, but if there happens to be somebody with
this kind of gear not too far from where I am (50 north of London) I
will travel. In exchange you get to keep the hardware and will be
supplied with whatever software I come up with.
Thanks in advance and regards,
Gerard, PG5G
Are you calculating ADEV and MDEV using the slopes determined by the
regression fit?
If so, what you calculate isn't ADEV or MDEV.
You need to use the raw timestamps taken at a rate of 5000/sec directly
to produce estimates of ADEV, MDEV.
What is the resolution of the TDC?
Bruce
Gerard you have some great comments already and welcome back to the
electronics hobby.
A couple of things.
Curious about whats on the board etc.
Here would be my thoughts.
If the same 10 MC signal thats the reference is also the input.
Then any funny numbers are the process leftovers or jitter.
I think this would also help you find the max resolution quickly.
Once you introduce external signals it becomes more difficult to understand
whats happening.
I built a LORAN C simulator driven by a Rb reference.
When I drive the austron 2100 with the same reference the austron ultimately
settles at its max resolution of 1 E-13.
Very interesting first project you clearly have a good background in applied
electronics
On Sat, Feb 27, 2010 at 7:36 AM, Bruce Griffiths <bruce.griffiths@xtra.co.nz
wrote:
Gerard PG5G wrote:
Hello all,
First post here, so I'll start with a quick introduction. I trained as
an electronic engineer but don't work in that field any more, which has
given me the appetite back to do some electronic engineering as a
hobby. I have been a licensed ham for over 25 years (more than 60% of
my life I realised the other day) and used to be rather active on HF as
PA3DQW. At the moment I live in the UK where I am licensed as M0AIU.
I recently designed and build a frequency counter and I need some help
with verifying its performance. I believe it gives me 11 digits in 1
second. I say believe because I have not got the hardware to verify
this. At the moment my assumption is based on calculations and limited
testing with the equipment available to me.
My counter is a "continuous time stamping reciprocal counter". I
implemented this as a USB powered device, with the hardware taking the
time stamps and sending it over USB to a windows PC. Some software
written in C++ takes care of analysing the data.
The hardware takes 5000 time stamps per second using a high speed TDC.
The hardware is a single PCB measuring about 50 by 80 mm. it requires
an external 10MHz reference and apart from using this as the time base
it also uses this for self-calibration of the TDC. The unit requires no
further calibration.
The PC software takes these time stamps and the associated counts and
uses regression to calculate the slope. This slope represents the
frequency of the input signal. I am sure people on here are familiar
with the counters made by Pendulum, and I have to confess that their
marketing material was helpful in putting this thing together.
Since the hardware is true zero dead time, the final capabilities of
this counter are determined by software. At the moment I can
simultaneously display the input at multiple gate times (see the
attached screen shot). For gate times over 1 second I have the option
to use overlapping gates, so that the display gets updated every
second.
Because there is no dead time I can also calculate Allan Deviation. The
two displays at the bottom of the page show both normal and overlapping
Allan deviation at tau=10s. I am still working on the software to do
this at multiple tau in real time and display it as a graph and a
table.
So, after this lengthy introduction here is my request for some
assistance. Is there somebody on the list who can assist me in
verifying the performance of this frequency counter? Ideally somebody
with access to two highly stable and known frequency sources. I can
send the hardware by mail, but if there happens to be somebody with
this kind of gear not too far from where I am (50 north of London) I
will travel. In exchange you get to keep the hardware and will be
supplied with whatever software I come up with.
Thanks in advance and regards,
Gerard, PG5G
Are you calculating ADEV and MDEV using the slopes determined by the
regression fit?
If so, what you calculate isn't ADEV or MDEV.
You need to use the raw timestamps taken at a rate of 5000/sec directly to
produce estimates of ADEV, MDEV.
What is the resolution of the TDC?
Bruce
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
You went quite??
On Sat, Feb 27, 2010 at 9:54 AM, paul swed paulswedb@gmail.com wrote:
Gerard you have some great comments already and welcome back to the
electronics hobby.
A couple of things.
Curious about whats on the board etc.
Here would be my thoughts.
If the same 10 MC signal thats the reference is also the input.
Then any funny numbers are the process leftovers or jitter.
I think this would also help you find the max resolution quickly.
Once you introduce external signals it becomes more difficult to understand
whats happening.
I built a LORAN C simulator driven by a Rb reference.
When I drive the austron 2100 with the same reference the austron
ultimately settles at its max resolution of 1 E-13.
Very interesting first project you clearly have a good background in
applied electronics
On Sat, Feb 27, 2010 at 7:36 AM, Bruce Griffiths <
bruce.griffiths@xtra.co.nz> wrote:
Gerard PG5G wrote:
Hello all,
First post here, so I'll start with a quick introduction. I trained as
an electronic engineer but don't work in that field any more, which
has
given me the appetite back to do some electronic engineering as a
hobby. I have been a licensed ham for over 25 years (more than 60% of
my life I realised the other day) and used to be rather active on HF
as
PA3DQW. At the moment I live in the UK where I am licensed as M0AIU.
I recently designed and build a frequency counter and I need some help
with verifying its performance. I believe it gives me 11 digits in 1
second. I say believe because I have not got the hardware to verify
this. At the moment my assumption is based on calculations and limited
testing with the equipment available to me.
My counter is a "continuous time stamping reciprocal counter". I
implemented this as a USB powered device, with the hardware taking the
time stamps and sending it over USB to a windows PC. Some software
written in C++ takes care of analysing the data.
The hardware takes 5000 time stamps per second using a high speed TDC.
The hardware is a single PCB measuring about 50 by 80 mm. it requires
an external 10MHz reference and apart from using this as the time base
it also uses this for self-calibration of the TDC. The unit requires
no
further calibration.
The PC software takes these time stamps and the associated counts and
uses regression to calculate the slope. This slope represents the
frequency of the input signal. I am sure people on here are familiar
with the counters made by Pendulum, and I have to confess that their
marketing material was helpful in putting this thing together.
Since the hardware is true zero dead time, the final capabilities of
this counter are determined by software. At the moment I can
simultaneously display the input at multiple gate times (see the
attached screen shot). For gate times over 1 second I have the option
to use overlapping gates, so that the display gets updated every
second.
Because there is no dead time I can also calculate Allan Deviation.
The
two displays at the bottom of the page show both normal and
overlapping
Allan deviation at tau=10s. I am still working on the software to do
this at multiple tau in real time and display it as a graph and a
table.
So, after this lengthy introduction here is my request for some
assistance. Is there somebody on the list who can assist me in
verifying the performance of this frequency counter? Ideally somebody
with access to two highly stable and known frequency sources. I can
send the hardware by mail, but if there happens to be somebody with
this kind of gear not too far from where I am (50 north of London) I
will travel. In exchange you get to keep the hardware and will be
supplied with whatever software I come up with.
Thanks in advance and regards,
Gerard, PG5G
Are you calculating ADEV and MDEV using the slopes determined by the
regression fit?
If so, what you calculate isn't ADEV or MDEV.
You need to use the raw timestamps taken at a rate of 5000/sec directly to
produce estimates of ADEV, MDEV.
What is the resolution of the TDC?
Bruce
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gerard,
Gerard PG5G wrote:
Hello all,
First post here, so I'll start with a quick introduction. I trained as
an electronic engineer but don't work in that field any more, which has
given me the appetite back to do some electronic engineering as a
hobby. I have been a licensed ham for over 25 years (more than 60% of
my life I realised the other day) and used to be rather active on HF as
PA3DQW. At the moment I live in the UK where I am licensed as M0AIU.
I recently designed and build a frequency counter and I need some help
with verifying its performance. I believe it gives me 11 digits in 1
second. I say believe because I have not got the hardware to verify
this. At the moment my assumption is based on calculations and limited
testing with the equipment available to me.
My counter is a "continuous time stamping reciprocal counter". I
implemented this as a USB powered device, with the hardware taking the
time stamps and sending it over USB to a windows PC. Some software
written in C++ takes care of analysing the data.
The hardware takes 5000 time stamps per second using a high speed TDC.
The hardware is a single PCB measuring about 50 by 80 mm. it requires
an external 10MHz reference and apart from using this as the time base
it also uses this for self-calibration of the TDC. The unit requires no
further calibration.
The PC software takes these time stamps and the associated counts and
uses regression to calculate the slope. This slope represents the
frequency of the input signal. I am sure people on here are familiar
with the counters made by Pendulum, and I have to confess that their
marketing material was helpful in putting this thing together.
Since the hardware is true zero dead time, the final capabilities of
this counter are determined by software. At the moment I can
simultaneously display the input at multiple gate times (see the
attached screen shot). For gate times over 1 second I have the option
to use overlapping gates, so that the display gets updated every
second.
Because there is no dead time I can also calculate Allan Deviation. The
two displays at the bottom of the page show both normal and overlapping
Allan deviation at tau=10s. I am still working on the software to do
this at multiple tau in real time and display it as a graph and a
table.
So, after this lengthy introduction here is my request for some
assistance. Is there somebody on the list who can assist me in
verifying the performance of this frequency counter? Ideally somebody
with access to two highly stable and known frequency sources. I can
send the hardware by mail, but if there happens to be somebody with
this kind of gear not too far from where I am (50 north of London) I
will travel. In exchange you get to keep the hardware and will be
supplied with whatever software I come up with.
Would you consider to disclose your architecture somewhat more?
Could you output time and event values from the time-stamping?
Would allow us to do some off-line processing independently.
Could you try different frequencies/amplitudes (would be good for
establishing the slew-rate dependency, i.e. internal noise). Measure
period jitter and plot for different slew-rates (frequency and
amplitude), use shortest tau possible.
Could you hook up the reference clock with different lengths of coax
cables. This would assist in measure the background noise and the
different lengths of cables would allow some indication of interpolator
non-linearity and input cross-talk.
As has already been discussed, software can do a lot for improving the
reading, but one needs to be careful in details or else completely
different measures results and they does not behave correctly. ADEV and
friends wants the raw time-samples. Frequency or period estimation
benefits from improved estimators, but then that is not useful for ADEV
and friends, so it is a dead end for further processing except
presentation level.
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do some
testing, but I am located over in Sweden. However, starting your verify
exercise with a fellow time-nut excursion yourself should be a nice
exercise that I recommend regardless. You should have several
friendly-minded in UK.
Cheers,
Magnus
Rock I take to be crystal. How about gas and air?
Bill Hawkins
-----Original Message-----
From: Magnus Danielson
Sent: Sunday, February 28, 2010 5:15 PM
To: pg5g@b737.co.uk; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] My DIY frequency counter and a request for help
------%<------
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do some
testing, but I am located over in Sweden.
Bill Hawkins wrote:
Rock I take to be crystal. How about gas and air?
Bill Hawkins
-----Original Message-----
From: Magnus Danielson
Sent: Sunday, February 28, 2010 5:15 PM
To: pg5g@b737.co.uk; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] My DIY frequency counter and a request for help
------%<------
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do some
testing, but I am located over in Sweden.
Gas = rubidium vapour??
Bruce
Whack! (sound of hand hitting forehead)
Gas must be Ru and Cs.
How do you run your pneumatic clocks?
Bill Hawkins
-----Original Message-----
From: Bill Hawkins [mailto:bill@iaxs.net]
Sent: Sunday, February 28, 2010 7:34 PM
To: 'Discussion of precise time and frequency measurement';
'pg5g@b737.co.uk'
Subject: Rock, gas, and air
Rock I take to be crystal. How about gas and air?
Bill Hawkins
-----Original Message-----
From: Magnus Danielson
Sent: Sunday, February 28, 2010 5:15 PM
To: pg5g@b737.co.uk; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] My DIY frequency counter and a request for help
------%<------
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do some
testing, but I am located over in Sweden.
A while back we had a thread about Paris and a network of air synced clocks ?
Stanley
----- Original Message ----
From: Bruce Griffiths bruce.griffiths@xtra.co.nz
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Sun, February 28, 2010 7:41:20 PM
Subject: Re: [time-nuts] Rock, gas, and air
Bill Hawkins wrote:
Rock I take to be crystal. How about gas and air?
Bill Hawkins
-----Original Message-----
From: Magnus Danielson
Sent: Sunday, February 28, 2010 5:15 PM
To: pg5g@b737.co.uk; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] My DIY frequency counter and a request for help
------%<------
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do some
testing, but I am located over in Sweden.
Gas = rubidium vapour??
Bruce
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
The winds in Sweden change directions in a very predictable fashion?
Bob
On Feb 28, 2010, at 8:50 PM, Stanley Reynolds wrote:
A while back we had a thread about Paris and a network of air synced clocks ?
Stanley
----- Original Message ----
From: Bruce Griffiths bruce.griffiths@xtra.co.nz
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Sun, February 28, 2010 7:41:20 PM
Subject: Re: [time-nuts] Rock, gas, and air
Bill Hawkins wrote:
Rock I take to be crystal. How about gas and air?
Bill Hawkins
-----Original Message-----
From: Magnus Danielson
Sent: Sunday, February 28, 2010 5:15 PM
To: pg5g@b737.co.uk; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] My DIY frequency counter and a request for help
------%<------
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do some
testing, but I am located over in Sweden.
Gas = rubidium vapour??
Bruce
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I have had a few replies, both on list and off list, including some
offers for help and some suggestions regarding the capabilities of my
counter. Thanks to everyone who took the time to write.
I understand from various replies I had that I cannot measure ADEV the
way I thought I could. I am an electronics man, not a mathematician (or
should that be mathemagician?). Adding the ADEV was an afterthought and
I'll leave the development of that for now.
Magnus sent me the most detailed list of questions and suggestions. I
think that by answering his post I cover most of what others have asked
me as well.
Regards
Gerard
Magnus Danielson wrote:
Would you consider to disclose your architecture somewhat more?
In broad terms:
Input conditioning with ADCMP600 comparators followed by FF divide by 2
to get a 50% duty cycle signal on both the ref and input channel.
PIC micro as time base generates 0.2 ms start pulses, cleaned up with a
FF. Output of this FF is start signal to the TDC.
Synchronisation with the input signal using a few more FFs, generating a
switch signal on the next rising edge. This switch signal is used to
switch between counter A and B (two more PICs) and is the stop signal to
the TDC. I also have the inverse of the input signal available. By
switching on the normal signal and counting the inverse signal I can
make sure I never get the wrong count in a measurement period (hence the
need for 50% duty cycle).
A fourth PIC communicates with the TDC and controls the communication
channel via an FTDI USB interface chip. Internally the counter works
with a normal serial protocol at 1MB, on the PC side it uses FTDI's D2XX
driver to process data in burst mode as opposed to RS232 mode.
Each time stamp consists of 10 Bytes. 2 for synchronisation, 4 for the
count, 4 for the time stamp expressed as a multiple of the TDC clock
period of 200ns (5 MHz). The TDC is an ACAM TDC-GP2. After each
measurement it performs a calibration to the ref clock provided (5 MHz)
and gives an output as a 32 bit fixed point number with 16 integer bits
and 16 fractional bits.
So, apart form the TDC these are all cheap off the shelf components
available from any electronics distributor.
Could you output time and event values from the time-stamping?
Would allow us to do some off-line processing independently.
I'll work on that. I need to get some data logging functions build into
the software anyway. Give me a few days.
Could you try different frequencies/amplitudes (would be good for
establishing the slew-rate dependency, i.e. internal noise). Measure
period jitter and plot for different slew-rates (frequency and
amplitude), use shortest tau possible.
Will do. I am bit limited in what I can generate at the moment. That
screen shot was the output of a HP8922H used as a signal generator set
to 10.000000 MHz. I guess there must be time nuts on here who recognised
the frequency of 10 000 000.461 Hz. If I select 11 MHz I get 11 000
000.461 Hz. At 100 MHz I get 100 000 000.461 Hz. Must be the way the
synthesiser works internally. (BTW, this matches what I get on my 5384A
counter). I'll have to get the data logging sorted before I can take
this much further.
Could you hook up the reference clock with different lengths of coax
cables. This would assist in measure the background noise and the
different lengths of cables would allow some indication of
interpolator non-linearity and input cross-talk.
Will do. I have now written some software which calculates the standard
deviation of the time stamps. If I connect the ref frequency twice than
ideally this should be zero. In reality it shows the noise of the whole
set up. I have noticed already that by disconnecting and reconnecting
the input side I can get my counter to work in two different 'modes'
with regards to the calculated standard deviation of the time stamps. My
guess at the moment is that this depends on whether the two input
dividers are in or out of synch but I need to do some more testing. Good
excuse to upgrade my oscilloscope and other test equipment.
Interestingly, both 'modes' give me a stable 11 digit readout of my 10
MHz reference frequency at 1 second gate time. The higher SDEV indicates
more noise, but it must be fairly well behaved noise not to affect the
frequency readout.
As has already been discussed, software can do a lot for improving the
reading, but one needs to be careful in details or else completely
different measures results and they does not behave correctly. ADEV
and friends wants the raw time-samples. Frequency or period estimation
benefits from improved estimators, but then that is not useful for
ADEV and friends, so it is a dead end for further processing except
presentation level.
I'll keep it for novelty value, but won't put too much more effort into
this.
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do
some testing, but I am located over in Sweden. However, starting your
verify exercise with a fellow time-nut excursion yourself should be a
nice exercise that I recommend regardless. You should have several
friendly-minded in UK.
I had an offer from a well equipped time nut not far from me who I have
contacted off list.
Cheers,
Magnus
Bob Camp wrote:
Hi
The winds in Sweden change directions in a very predictable fashion?
Ghaa! Our secret is out! :)
No, by rock I mean crystal, gas is Rb and Cs but could also be H but I
don't have one of those babies, and by air I mean GPS or other radio-signal.
Cheers,
Magnus
Quoth Magnus Danielson at 01/03/10 19:36...
No, by rock I mean crystal, gas is Rb and Cs but could also be H but I
don't have one of those babies, and by air I mean GPS or other radio-signal.
Well if you think of radio signals as energy, how about:
Air: Rb, CS (gas)
Fire: Radio/GPS
Earth: Crystal
Water: ? Clepsydra?
--
Matthew Smith
Smiffytech - Technology Consulting & Web Application Development
Business: http://www.smiffytech.com/
Blog/personal: http://www.smiffysplace.com/
LinkedIn: http://www.linkedin.com/in/smiffy
Skype: msmiffy
Twitter: @smiffy
Gerard PG5G wrote:
I have had a few replies, both on list and off list, including some
offers for help and some suggestions regarding the capabilities of my
counter. Thanks to everyone who took the time to write.
I understand from various replies I had that I cannot measure ADEV the
way I thought I could. I am an electronics man, not a mathematician (or
should that be mathemagician?). Adding the ADEV was an afterthought and
I'll leave the development of that for now.
Magnus sent me the most detailed list of questions and suggestions. I
think that by answering his post I cover most of what others have asked
me as well.
Regards
Gerard
Magnus Danielson wrote:
Would you consider to disclose your architecture somewhat more?
In broad terms:
Input conditioning with ADCMP600 comparators followed by FF divide by 2
to get a 50% duty cycle signal on both the ref and input channel.
PIC micro as time base generates 0.2 ms start pulses, cleaned up with a
FF. Output of this FF is start signal to the TDC.
Synchronisation with the input signal using a few more FFs, generating a
switch signal on the next rising edge. This switch signal is used to
switch between counter A and B (two more PICs) and is the stop signal to
the TDC. I also have the inverse of the input signal available. By
switching on the normal signal and counting the inverse signal I can
make sure I never get the wrong count in a measurement period (hence the
need for 50% duty cycle).
A fourth PIC communicates with the TDC and controls the communication
channel via an FTDI USB interface chip. Internally the counter works
with a normal serial protocol at 1MB, on the PC side it uses FTDI's D2XX
driver to process data in burst mode as opposed to RS232 mode.
Each time stamp consists of 10 Bytes. 2 for synchronisation, 4 for the
count, 4 for the time stamp expressed as a multiple of the TDC clock
period of 200ns (5 MHz). The TDC is an ACAM TDC-GP2. After each
measurement it performs a calibration to the ref clock provided (5 MHz)
and gives an output as a 32 bit fixed point number with 16 integer bits
and 16 fractional bits.
So, apart form the TDC these are all cheap off the shelf components
available from any electronics distributor.
Many thanks, now we know better what we are referring to.
Could you output time and event values from the time-stamping?
Would allow us to do some off-line processing independently.
I'll work on that. I need to get some data logging functions build into
the software anyway. Give me a few days.
Fair enough. It is always good to be able to drop a log-file and process
and analyze off-line either with ones own tools, off the shelf or toss
something together. Incremental form of ADEV/TDEV estimators would be
nice for the real-time variant tool.
Could you try different frequencies/amplitudes (would be good for
establishing the slew-rate dependency, i.e. internal noise). Measure
period jitter and plot for different slew-rates (frequency and
amplitude), use shortest tau possible.
Will do. I am bit limited in what I can generate at the moment. That
screen shot was the output of a HP8922H used as a signal generator set
to 10.000000 MHz. I guess there must be time nuts on here who recognised
the frequency of 10 000 000.461 Hz. If I select 11 MHz I get 11 000
000.461 Hz. At 100 MHz I get 100 000 000.461 Hz. Must be the way the
synthesiser works internally. (BTW, this matches what I get on my 5384A
counter). I'll have to get the data logging sorted before I can take
this much further.
Sounds like a systematic offset. However, that can be useful for you.
Slowly scans the interpolator bins.
Could you hook up the reference clock with different lengths of coax
cables. This would assist in measure the background noise and the
different lengths of cables would allow some indication of
interpolator non-linearity and input cross-talk.
Will do. I have now written some software which calculates the standard
deviation of the time stamps.
That is indeed what you want to assist you.
If I connect the ref frequency twice than
ideally this should be zero. In reality it shows the noise of the whole
set up. I have noticed already that by disconnecting and reconnecting
the input side I can get my counter to work in two different 'modes'
with regards to the calculated standard deviation of the time stamps. My
guess at the moment is that this depends on whether the two input
dividers are in or out of synch but I need to do some more testing.
You could use a separate DFF to clock the state from one of the outputs
with the other... and just hook a LED to it. That would help you to
visualize the modes in the case that it is true in-/out-of-phase mode of
the input dividers.
I would assume that you are experiencing the cross-talk that I was
referring to. Cross-talk could either be seen as capacitive coupling
between channels or common-inductance of two stages. Channel-to-channel
isolation is important.
Good excuse to upgrade my oscilloscope and other test equipment.
Interestingly, both 'modes' give me a stable 11 digit readout of my 10
MHz reference frequency at 1 second gate time. The higher SDEV indicates
more noise, but it must be fairly well behaved noise not to affect the
frequency readout.
Recall that your frequency readout is just an average of several noisy
time-stamps, and if you take a noisier set of time-stamps more noise is
expected, but only very rarely they create an actual bias in readout of
derivate values like period and frequency.
As has already been discussed, software can do a lot for improving the
reading, but one needs to be careful in details or else completely
different measures results and they does not behave correctly. ADEV
and friends wants the raw time-samples. Frequency or period estimation
benefits from improved estimators, but then that is not useful for
ADEV and friends, so it is a dead end for further processing except
presentation level.
I'll keep it for novelty value, but won't put too much more effort into
this.
OK. I have spent some time on writing some software for ADEV and friends.
I think I have a fairly good setup including bunches of rock, gas and
air clocks alongside a fair set of counters, so I could probably do
some testing, but I am located over in Sweden. However, starting your
verify exercise with a fellow time-nut excursion yourself should be a
nice exercise that I recommend regardless. You should have several
friendly-minded in UK.
I had an offer from a well equipped time nut not far from me who I have
contacted off list.
Good to hear. Would be nice to hear on your progress.
Cheers,
Magnus
Gerard,
Gerard PG5G wrote:
I have had a few replies, both on list and off list, including some
offers for help and some suggestions regarding the capabilities of my
counter. Thanks to everyone who took the time to write.
I understand from various replies I had that I cannot measure ADEV the
way I thought I could. I am an electronics man, not a mathematician (or
should that be mathemagician?). Adding the ADEV was an afterthought and
I'll leave the development of that for now.
Just to follow up on the Pendulum presentation, here is a paper from
Staffan Johansson detailing both frequency and ADEV calculations, and as
I understand the paper they do the ADEV properly and not based on the
linear regression estimated frequency values.
http://tycho.usno.navy.mil/ptti/ptti2005/paper67.pdf
This also fits my memory correct from previous discussions.
Just so that nobody incorrectly believes that they do their ADEV on the
wrong values, but it was just an issue of misunderstanding the presentation.
Cheers,
Magnus