[time-nuts] Homebrew frequency counter, new board test result

Magnus Danielson magnus at rubidium.dyndns.org
Sun Dec 21 08:08:55 EST 2014

Li ang, Bob,

On 12/20/2014 06:22 PM, Bob Camp wrote:
> Hi
>> On Dec 20, 2014, at 10:28 AM, Li Ang <lllaaa at gmail.com> wrote:
>> 4) add 74ALV2G14 since FPGA does not support schmitt input
> I would suggest trying it with a non-schmitt trigger part as well. It should be a simple swap out since it’s a leaded part. In some cases the trigger level hysteresis is not helpful. The better over voltage immunity of the leaded parts compared to the FPGA inputs *is* a good idea. They also are a lot easier to swap out if you blow one out accidentally.

I have been able to get much lower noise by using a sine to square 
shaper. I have modified my TADD-2 to output the shaped clock. For better 
counters, the difference is noticeable. You want such an amplifyinng 
stage prior to the schmitt-trigger to gain yourself out of the slew-rate 

>> test instruments
>> 1) HP6622A as power supply
>> 2) FE5650 rb as reference
>> 3) PRS10 rb as DUT
> I would toss an OCXO or two into the mix eventually.

I concur.

> ———————
> It looks like the three “4 layer FPGA” plots all cluster tightly at just under 2x10^-10 at 1 second as long as linear regression is turned off. That’s pretty good performance. I *think* I’m seeing that correctly on the plots. If I’m not, let me know.
> The two plots with linear regression are still a bit “interesting”:
> The plot with ref and DUT the same ( green) still is showing data that is in the “to good to be true” range. The averaging process of the linear regression is probably still causing this.

If the filtering of the regression spans a significant part of the tau 
(or beyond it) I don't trust the numbers for that part of the slope 
without the pre-filter bandwidth is noted. I would like to see the MDEV 
variants of these plots.

> The plot with ref and DUT not the same (RED) shows some sort of spur. That could indeed be a spur from one or the other of the Rb’s. It also could be something in your lab. Turning out the light is a good thing to check. Because of the low frequency, I would suspect a spur on the Rb. Put another way, the counter is not making a mistake in this case. It’s reporting what is actually going on with the inputs. Another test source (or pair of sources) would help sort this out.

There can a reason to see if there is something modulating into the 
trigger point, which is the danger with schmitt-trigger inputs.

> Something else to look at:
> Check your results vs input level. In other words, attenuate one of the input signals and see what happens. I would start with 3 or 6 db and go from there. The attenuation does not have to be precise. The frequencies involved are not high enough to require fancy parts. The idea is to check if the input noise level of the gates is a problem for you. If the data quickly get worse as you attenuate, they need some help.

If damping the signal causes a sizeable increase in amplitude, you most 
likely have a slew-rate problem on the input. If you damp your signal by 
6 dB and get 6 dB higher noise, then you definitively have 
slew-rate/amplitude problems.


More information about the time-nuts mailing list