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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
