[time-nuts] My DIY frequency counter and a request for help

[Magnus Danielson]

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