Hi Magnus Thanks for the detailed information. btw, I've found an easier way to get histogram : sort tdc_test.txt | uniq -c
2014-12-31 23:37 GMT+08:00 Magnus Danielson <mag...@rubidium.dyndns.org>: > Hi, > > First I did a statistical histogram simply by counting how many times a > particular delay measure occurred, thus creating "bins" of occurrence count > for each value. I did this by doing > > grep 1.987 tdc_test.txt | wc -l > 648 > > So, the 1.987 bin has a count of 648. > I sent you the full histogram in the first reply. > > Then, I calculated the average delay by multiply each delay with the count > of that delay, and then add these products to a sum, and divide by the > total count (5100). > > Using this average, I then subtract that for the measure of each bin, thus > getting the distance from the average. This difference is then squared, and > multiplied with the count for it's bin-count. Again this is being summed, > divided by the total count minus 1 (5099) to produce the variance, and > square root produces the standard deviation. > > So far, it relative simple operations. > > These operations could be done directly on the sample-set, but the > histogram is also good in that you can now see if it is unbalanced. > > One analysis you can do is to analyse how well the histogram matches up > the expected Gaussian distribution bell for the noise you have. This can be > done in several ways, but for a coarse set of bins like this, I think the > best is to generate a matching Gaussian bin count from the bin positions, > average and deviation. The difference with the actual bin count will then > illustrate any major deviations. The trained eye will see deviation in the > histogram anyway. However, to do this requires the erfc. > > Hope this have shown you enough of the "magic". But to assist you further, > please find a spread-sheet of it attached. > > Notice that I scaled the values by 100 ns before further processing. > > Cheers, > Magnus > > > On 12/31/2014 01:03 PM, Li Ang wrote: > >> Hi Magnus, >> I'm not familar with error analysis and statistics, can you tell me >> how >> to calculate the jitter with my data? Can you tell me some articles or >> tutorials about the calculation that a time-nut usually use? I want to >> learn stuffs. :) >> >> Thanks. >> >> 2014-12-29 21:58 GMT+08:00 Magnus Danielson <mag...@rubidium.dyndns.org>: >> >> Hi, >>> >>> Darn, not reading all the notes. Again. >>> >>> Well, in that case, scaling should be done... then you get average of >>> 198,5075 ns and 149,8 ps RMS jitter, with 1,1 ns peak-to-peak. >>> >>> The jitter is okish then, but a little better would indeed be nice. >>> >>> Cheers, >>> Magnus >>> >>> >>> On 12/29/2014 01:55 PM, Li Ang wrote: >>> >>> Hi Magnus, >>>> The unit of these data is not ns but reference clock cycles >>>> (100ns). >>>> TDC_GP22 measures the time between the edge of tdc_start and >>>> tdc_stop1, then it measures the reference clock automaticly. The result >>>> you >>>> get from it is the ratio of them. >>>> >>>> 2014-12-29 19:58 GMT+08:00 Magnus Danielson <mag...@rubidium.dyndns.org >>>> >: >>>> >>>> Hi, >>>> >>>>> >>>>> Some quick statistic-processing. >>>>> >>>>> Histogram of your data: >>>>> 1.979 0 >>>>> 1.980 2 >>>>> 1.981 46 >>>>> 1.982 173 >>>>> 1.983 523 >>>>> 1.984 1031 >>>>> 1.985 1301 >>>>> 1.986 1131 >>>>> 1.987 648 >>>>> 1.988 236 >>>>> 1.989 8 >>>>> 1.990 1 >>>>> 1.991 0 >>>>> >>>>> The total sample count is 5100 (wc -l only gives 5099 since there is a >>>>> missing end of line, but word count is 5100). >>>>> >>>>> The average is about 1,985075 ns and it is reasonably gaussian, but >>>>> with >>>>> some systematics, notice how the slope is more abrupt on the higher end >>>>> than the lower end. A quick and dirty spreadsheet gives me about 2,243 >>>>> ps >>>>> RMS jitter, which isn't all that bad. Yes, it will spread out to that >>>>> 11 >>>>> ps >>>>> peak-to-peak jitter, but it is to be expected. >>>>> >>>>> It's pretty respectable for a home-built. >>>>> >>>>> Cheers, >>>>> Magnus >>>>> >>>>> >>>>> On 12/28/2014 03:19 PM, Li Ang wrote: >>>>> >>>>> Hi Bob, >>>>> >>>>>> I did some test according to your suggestions. DUT is a >>>>>> symmetricom >>>>>> x72 >>>>>> rb oscillator. Also, I've tried signal generator as the DUT. R&S SMY01 >>>>>> is >>>>>> not as good as HP8662A but that the best I've got. The signal geneator >>>>>> is >>>>>> also using FE5650 as ref clock. >>>>>> >>>>>> According to my test with the TDC today, this unit is not >>>>>> producing >>>>>> very >>>>>> stable data. >>>>>> I don't have accurate pulse generator, so this is how I test the >>>>>> TDC: >>>>>> 0) power the board with battery. >>>>>> 1) use FPGA to generate time pulse: >>>>>> reg [15:0] shift; >>>>>> always @(posedge refclk10M) begin >>>>>> shift <= {shift[14:0], sw_gate}; >>>>>> end >>>>>> assign tdc_start = shift[3]; >>>>>> assign tdc_stop1 = shift[5]; >>>>>> >>>>>> 2) use MCU to pull down sw_gate, the FPGA sync it to refclk10M domain >>>>>> and >>>>>> generate input signal for TDC. >>>>>> >>>>>> 3) use TDC to test the time betwen tdc_start and tdc_stop1 >>>>>> >>>>>> The result is in tdc_test.zip. number * 100ns = time between tdc_start >>>>>> and >>>>>> tdc_stop1. (TDC highspeed clock is refclk10M/2). >>>>>> >>>>>> There 2 issues from the test: >>>>>> 1) As we can see from the data, the number is around 1.98x not 2.00x. >>>>>> So >>>>>> there is about 2ns delay between tdc_start and tdc_stop1 for this >>>>>> simple >>>>>> test code. If it is from the PCB trace and something inside FPGA, this >>>>>> part >>>>>> should be a constant value at certain temperature. I can calculate it >>>>>> by >>>>>> measuring 2 cycles and 3 cylces. My current code has not implement >>>>>> this >>>>>> part, it should provide some improvement. 2ns time error for 1s gate, >>>>>> that >>>>>> is something. >>>>>> 2) For a 90ps TDC, I think the result should be something like +-0.001 >>>>>> cycle. But I get something like +-0.003 cycle. I do not know the >>>>>> reason >>>>>> for >>>>>> now. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-12-27 22:58 GMT+08:00 Bob Camp <kb...@n1k.org>: >>>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>>> (In reply to several posts. It’s easier for me this way) >>>>>>> >>>>>>> Ok, that’s good news !!! (and useful data) >>>>>>> >>>>>>> Your counter performance degraded a bit when you put in 5 db and not >>>>>>> much >>>>>>> when you put in 8 db. >>>>>>> >>>>>>> It’s also maybe *too* good news. I suspect that cross talk between >>>>>>> the >>>>>>> channels may be impacting your results. >>>>>>> >>>>>>> Next step is to try it with two independent sources and a bit more >>>>>>> attenuation. When you try it with two sources, you need to attenuate >>>>>>> first >>>>>>> one source and then switch the attenuators to the other source. That >>>>>>> will >>>>>>> help you see if crosstalk from one channel is more of a problem than >>>>>>> from >>>>>>> the other channel. >>>>>>> >>>>>>> One parts hint: >>>>>>> >>>>>>> Cable TV attenuators are much cheaper than their fancy 50 ohm >>>>>>> MIniCircuits >>>>>>> cousins. They are also something you can pick up down at the corner >>>>>>> electronics store. For this sort of testing they are perfectly fine >>>>>>> to >>>>>>> use. >>>>>>> At this point in the testing the mismatch between 75 ohms and 50 ohms >>>>>>> is >>>>>>> not a big deal. You will need to adapt connectors, but you probably >>>>>>> still >>>>>>> will save money. >>>>>>> >>>>>>> ======= >>>>>>> >>>>>>> Op-amps that have enough bandwidth and performance for a high input >>>>>>> impedance counter input are rare items. They also are not cheap. >>>>>>> Often >>>>>>> they >>>>>>> come as some sort of current feedback part with low(er) input >>>>>>> impedance. >>>>>>> If >>>>>>> you want your counter to work to 300 MHz, it should accept a 300 MHz >>>>>>> square >>>>>>> wave. That might mean passing the third or even the fifth harmonic of >>>>>>> the >>>>>>> square wave. An input channel with 900 or 1500 MHz bandwidth is >>>>>>> quite a >>>>>>> challenge. >>>>>>> >>>>>>> One very simple solution is to just grab a high speed comparator like >>>>>>> the >>>>>>> one used by Fluke / Pendulum (ADCMP565). Drive it directly with your >>>>>>> input >>>>>>> or clock. Make it your front end device. That’s not an ideal >>>>>>> solution, >>>>>>> but >>>>>>> it will give you the bandwidth and a reasonable input impedance. It >>>>>>> requires messy things like a negative supply or a “fake” ground (so >>>>>>> would >>>>>>> the op amp). It also has an ECL output that needs to be converted to >>>>>>> match >>>>>>> your FPGA ( hint: use the clock inputs, they are LVPECL compatible). >>>>>>> Driving into the FPGA with a differential signal is probably needed >>>>>>> to >>>>>>> reduce crosstalk. >>>>>>> >>>>>>> No matter how you do it, input channels are *not* an easy thing to do >>>>>>> properly. Even on commercial counters, they often are easy to fool. >>>>>>> Designing one is only the start. Fully testing it is equally complex. >>>>>>> >>>>>>> ========= >>>>>>> >>>>>>> Do not underrate your skills in any way. You are doing far more on >>>>>>> this >>>>>>> project than any of the rest of the list members have done. We have >>>>>>> talked >>>>>>> and talked forever about these chips. We talk a lot about these >>>>>>> ideas. >>>>>>> We >>>>>>> suggest lots of complex solutions to various possible problems (like >>>>>>> the >>>>>>> expensive comparator I suggested above). What we almost never do is >>>>>>> actually build a counter. If we build something we don’t fully test >>>>>>> it. I >>>>>>> have never seen any list member share their results the way you >>>>>>> have. I >>>>>>> suspect that most of us (yes this includes me) are a bit to scared of >>>>>>> the >>>>>>> response. >>>>>>> >>>>>>> Please do not stop your work. Keep letting us know how it is going. >>>>>>> This >>>>>>> is very exciting !!! >>>>>>> >>>>>>> Bob >>>>>>> >>>>>>> On Dec 27, 2014, at 8:22 AM, Li Ang <lll...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Bob, >>>>>>>> Here is the data and test scheme. >>>>>>>> It does not show much difference. >>>>>>>> >>>>>>>> 2014-12-26 22:12 GMT+08:00 Bob Camp <kb...@n1k.org>: >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>> 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 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 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 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 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 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 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 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.