[time-nuts] Homebrew frequency counter, new board test result
lllaaa at gmail.com
Mon Dec 22 08:44:16 EST 2014
Hi Bob & Magnus,
Thanks for the analysis. I will do some more test and post data later.
My verilog code has still some problem that cause a spike on frequency.
It looks like FPGA missed 1 count for the reference clock. I need to fix
2014-12-21 21:08 GMT+08:00 Magnus Danielson <magnus at rubidium.dyndns.org>:
> Li ang, Bob,
> On 12/20/2014 06:22 PM, Bob Camp wrote:
>> 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 limit.
> 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.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> and follow the instructions there.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 49889 bytes
Desc: not available
More information about the time-nuts