Re: [time-nuts] Homebrew frequency counter, new board test result
Li ang, Bob, On 12/20/2014 06:22 PM, Bob Camp wrote: Hi On Dec 20, 2014, at 10:28 AM, Li Ang 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. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Homebrew frequency counter, new board test result
Hi > On Dec 20, 2014, at 10:28 AM, Li Ang wrote: > > Hi >It's me again. I was debugging the new FPGA version board this week. > The attached file is the test result of this new board, and 2 tests of CPLD > version(2014/12/11) are also included. There are few things changed between > these 2 version: > 1) CPLD -> FPGA > 2) XC6206 -> TPS79333 for TDC power supply. Analog and digital part of TDC > use dedicated LDO. good idea > 3) 2 layer -> 4 layer also a good idea > 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. > > A little bit better than before. :) Yes indeed. Not just better in magnitude, but better in terms of the traces all being close to each other. > > > > mistakes of current version: > 1) the board is 1cm bigger than expected……. so you got some board for free :) > 2) the themral pad of FPGA should be connected to ground Often multiple via’s are run to ground from the thermal pad to improve heat spreading. If the part is not hot to the touch, you should be ok for right now. > > 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. ——— 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. 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. The ADEV of a (working) MV89 or similar OCXO over the 1 to 100 second range should be at the < 2x10^-12 level. That’s good enough for the tests you are running. It’s also well below the (maybe) 1x10^-11 of the Rb’s at 1 second. So far the Rb’s ADEV has not been a problem for you. If you get a bit better with what you are doing, it may become an issue. You will need to use TimeLab’s built in “remove frequency error (drift)” capability when you are running OCXO’s. That’s an ok thing to do for the test. —— 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. Enough for now. Thanks for sharing !! Bob ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Homebrew frequency counter, new board test result
Hi It's me again. I was debugging the new FPGA version board this week. The attached file is the test result of this new board, and 2 tests of CPLD version(2014/12/11) are also included. There are few things changed between these 2 version: 1) CPLD -> FPGA 2) XC6206 -> TPS79333 for TDC power supply. Analog and digital part of TDC use dedicated LDO. 3) 2 layer -> 4 layer 4) add 74ALV2G14 since FPGA does not support schmitt input A little bit better than before. :) mistakes of current version: 1) the board is 1cm bigger than expected... 2) the themral pad of FPGA should be connected to ground test instruments 1) HP6622A as power supply 2) FE5650 rb as reference 3) PRS10 rb as DUT Li Ang ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
