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 <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.
_______________________________________________
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.
