[time-nuts] Experiment in lowering the TAPR TICC noise floor

Matthias Welwarsky time-nuts at welwarsky.de
Thu Oct 8 07:10:38 UTC 2020


On Mittwoch, 7. Oktober 2020 23:49:47 CEST Tom Van Baak wrote:
> Matthias,
> 
> Thanks for posting the raw data. You mention that both channels get the
> same signal and so you expect a sqrt(2) improvement in noise
> measurement. But consider...

I didn't actually expect anything in particular. I just wanted to see if 
there's an improvement. Practically, there is.

> 1) sqrt(2) is only valid if both channels are equal to begin with. Plot
> the ADEV of chA and chB and you'll see this isn't quite the case. It's
> close, but not the same, so your improvement will not be a full sqrt(2).
> It could board layout or the TDC7200 itself. When looking at picoseconds
> one should not expect two counters or different channels of the same
> counter to necessarily have identical noise. Next time plot both
> channels (plus the combination), not just one channel plus the combination.

Well, that's easy, just import the raw files into TimeLab. If I remember 
correctly, one of the channels had indeed a very slightly lower noise floor.

> 2) sqrt(2) is only valid if you ignore DUT and REF noise. What DUT did
> you use for chA and chB, and what REF did you use for the 10 MHz? Your
> ADEV plot is the combination of DUT *and* REF *and* TICC/chA *and*
> TICC/chB so even if there's a sqrt(2) improvement in chA+chB it won't
> appear as large as sqrt(2) if your DUT or REF has its own contributing
> noise at e-10 or e-11 levels.

Hum, as long as the noise is white, it wouldn't matter where it originated 
from as it doesn't contain any information.

> It seems to me your test would be valid, and you would in fact see
> sqrt(2) in the ADEV plot, if your DUT and REF were both stable to low
> e-12 levels and if the TICC's chA and chB h/w both had equal noise.

I don't think this is the deciding factor. It's more that the noise in the two 
channels is contains too much information. I'm actually surprised that there 
is an improvement at all, with so many inputs to the measurement system being 
coherent.

> 
> /tvb
> 
> On 10/3/2020 1:37 AM, Matthias Welwarsky wrote:
> > Dear all,
> > 
> > When I started to look more into the software side of the TICC and
> > especially the ominous "time dilation" parameter, I set up an experiment
> > where I feed the same event into both channels of the TICC, for
> > evaluating the sensitivity of the measurements to this parameter
> > (spoiler: there is a measurable influence but it's not as critical as I
> > originally thought).
> > 
> > While looking at the phase measurements the idea evolved to see if the
> > noise floor could be lowered by combining the measurements of the two
> > channels.
> > 
> > I have attached the resulting ADEV and the raw channel timestamps. The red
> > trace is one individual channel, the blue trace is the combination of both
> > channels. I used Octave to evaluate the measurements.
> > 
> > I used the following commands to get from timestamps to phase data:
> > 
> > A=detrend(cumsum(1-diff(load("chan-a.txt"))));
> > B=detrend(cumsum(1-diff(load("chan-b.txt"))));
> > 
> > The combination of both channels is the an element-wise arithmetic mean:
> > 
> > V=(A+B)/2;
> > 
> > As you can see in the ADEV chart, there is indeed a slight improvement of
> > the noise floor from 7.8e-11 @1s to 6.8e-11 at 1s.
> > 
> > Of course this combining doesn't work too well if the noise of the two
> > channels is correlated, and there's plenty opportunity in this setup for
> > this to happen. For one, both channels are driven by the same clock
> > source, they share the same power supply, connected to the same Arduino
> > base board and the cables from the event source to the channel inputs are
> > of the same length. It would be interesting to repeat the experiment with
> > a more elaborate setup, for example using two TICCs with individual clock
> > sources (locked to each other but not coherent), using different lengths
> > of cables to feed the channels etc.
> > 
> > Regards,
> > Matthias
> > 
> > 
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and
> > follow the instructions there.
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow
> the instructions there.








More information about the Time-nuts_lists.febo.com mailing list