[time-nuts] schematics of frequency counter
Magnus Danielson
magnus at rubidium.dyndns.org
Thu Jan 1 13:59:40 UTC 2015
Hi,
Yes, that is a much quicker approach.
Bit of warning, I might have an error in the details of re-creating the
expected histogram, that was done in haste. I might have to correct that
eventually, but it shows the principle.
I also did not add plots of the histogram, estimated histogram and
difference histogram. Should be done.
Cheers,
Magnus
On 01/01/2015 01:53 PM, Li Ang wrote:
> 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.
>>
> _______________________________________________
> 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