[time-nuts] schematics of frequency counter
Li Ang
lllaaa at gmail.com
Thu Jan 1 12:53:31 UTC 2015
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 <magnus at 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 <magnus at 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 <magnus at 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 <kb8tq at 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 <lllaaa at 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 <kb8tq at n1k.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>
>>>>>>> time-nuts mailing list -- time-nuts at 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 at 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 at 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 at 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 at 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 at 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
More information about the Time-nuts_lists.febo.com
mailing list