[time-nuts] 2.5 Ghz 12 digit counter project

Bruce Griffiths bruce.griffiths at xtra.co.nz
Sun Dec 30 09:58:30 UTC 2012

Robert Atkinson wrote:
> Hi,
> While it may be a waste of time and money for time nuts, it may be a good introduction for others. It may even spawn a few time nuts. Better someone build this and learn something than just buy a cheap Chinese counter on ebay. I've seen much worse projects published. I do agree that not releasing source code is bad practice, especially when a project is code driven.
> Robert G8RPI.
A short, by no means exhaustive, list of some of the quirks and failings 
of this design:

A major issue is that measurements are made every other timebase period.
So if one has a 1000sec gate time the interval between the end of one 
gate time and the start of the next is 1000sec.
A ping-pong counter chain would eliminate the dead time between 

Alternatively if the entire count chain were fully synchronous then the 
count could be latched on the fly when required whilst the counter 
continues to count.
With an FPGA implementing such a counter would be almost trivial.

There are lots of other issues such as the use of a 1 bit synchroniser 
between the timebase clock domain and the clock domain of the frequency 
being measured.
The extensive use of relatively slow 4000 series devices with consequent 
long prpagation delays is another potential issue.

There are at least 3 clock domains:

1) The 32kHz timebase

2) The 8MHz microprocessor clock

3) The (possibly prescaled ) input frequency.

Whenever a signal crosses from one clock domain to another clock domain 
a synchroniser is required.

Prescaling the input by 1000 seems overkill and reduces resolution of 
the 2.5GHz channel.
The counter chain can count frequencies up to 100MHz so a 50x (or 
perhaps 100x) prescaler would suffice.

Using 4 external decade counters in the counter chain is pointless when 
the display is handled by the micro and the internal counter within the 
micro is a binary counter.
Using a 16bit binary counter increase the count by a factor of ~6.5 
before overflow occurs (in the internal software counter).

There are a myriad of issues with respect to production spreads of IC 
parameters and component tolerances as well as transistor switching 
speeds (BC558), the JFET input buffer, the input match of the 2.5GHz 
channel etc.


More information about the time-nuts mailing list