[time-nuts] Re: Build a 3 hat timestanp counter

Sat May 28 15:04:16 UTC 2022

Hello Magnus, 

I understood that simply sampling 3 channels fast and averaging does not
solve all the problems ;-). 

I have a HP E740A time interval analyzer that I might use for my
oscillators.
The HP-TIA has 50ps resolution, can sample 10 Mhz directly but has only
512K sample memory. For longer recordings I can use the histogram
function. I still need to do some work on my software for that, but that
might be the fastest way to get results.

Attached is a picture of my HP10811 and another one that someone made
for me as a comparison to other TIAs. 

The third pic shows another meter i have  with TLV3501 and TDC7200
without averaging compared to an FA2.  

I will keep trying with the TDC7200 and maybe better with the LTC6957
and only one channel. 

Am 2022-05-25 22:34, schrieb Magnus Danielson via time-nuts:

> Dear Hans-Georg,
> 
> The sooner you can supply ADEV and MDEV phase-plots from your device, we can provide more detailed recommendations and point you to specifics. I try to raise your awareness in dry-simulation before any measurement is available.
> 
> Please be aware that comparators is inherently slew-rate limited, such that the slew-rate convert the amplitude noise to time-noise, which is later time-tagged by the time-tagger circuits. This follows the classic trigger noise formula:
> 
> t_n = e_n / SR
> 
> where t_n is the time-noise, e_n is the voltage noise and SR is the slew-rate.
> 
> You can stress-test this using two methods:
> 
> 1) change trigger voltage to alter voltage point and thus slew-rate on signal shape. In practice this is mostly useful as you operate a scope, but very illustrative as you see the fuzzyness increase and decrease due to the trigger noise.
> 
> 2) alter amplitude of signal, such as inserting a 6 dB damper, which will double the slew-rate limited noise.
> 
> To complicate matters, there is inherent noise of any channel, so that comes on top of the slew-rate limited noise. Alternate slew-rate to separate the effects is straight-forward.
> 
> So, with that basic on trigger jitter, I aim to complicate matters for you.
> 
> You can make the trigger process better than comparators. There is a paper by Collins that covers it, but it has been further investigated. See the contributions to the field available online by Bruce Griffiths, a fellow time-nuts in New Zeeland. The basic reasoning builds on four observations:
> 
> First, the noise of a circuit depends on the bandwidth of the input. Quite simply, if we have a 300 K noise-source, how much voltage we get depends also on the bandwidth.
> 
> Secondly, the slew-rate we have is limited by the bandwidth, since the reciprocal of bandwidth provides access to the rise-time and slew-rate is rise-time limited.
> 
> Third, we can increase slew-rate by using gain.
> 
> Fourth, each gain-stage will add noise.
> 
> In a reasoning similar to, but not quite matching up to the Friis formula for noise figure is relevant here.
> 
> So, rather than going straight into a comparator, which is a high-bandwidth input with high gain, you can have multiple stages of amplification and successively increasing bandwidth to support the slew-rate. Eventually you have a slew-rate so high, that a straight comparator or even digital input will not care.
> 
> Another complicating factor is that the quantization noise and random noise actually interact. I did analysis on that and presented at a conference. The paper for it is just unreadable and below my standards, but the learnings is important and I will have to revisit the topic. It can actually be good to have more noise than the quantization step has, if you do averaging. Actually, the HP5328A with Option 040, 041 or 042 or a HP5328B will intentionally add noise to the signal to improve the precision as you do averaging. It claims 10 ps resolution achievable if you look in the catalog. Turns out it is better than that, because it assumed a sqrt(N) benefit.
> 
> Now, observe how I just contradicted myself in methods. This is, in Bob Camps lovely terminology, a "it depends" issue. Which way to go depends so much on where your limits are and how you choose to approach it.
> 
> You mention that it may be good to separate things. I can state clearly that it does. As these signals go through the same chip, ground-bounce issues cause cross-talk. This cross-talk looks similar to a capacitive coupling between the signals, at the point of most slew-rate, the cross-talk is worst. This cross-talk causes any time-wise nearby signal to shift it's apparent time, causing a non-linear shift of time-difference between the signals. This will cause the RMS error to increase as measured over all phase-relationships, and it looks like apparent lock-up of the oscillators, when it is in fact the measurement device which causes the imperfection. One trick to be used is to use a short bit of coax and simply time-stamp a delayed version independently. This way you can estimate the effect and it's impact on your measurement. This usually leads to work on the counter to reduce coupling. Notice that this non-linearity increases with increased slew-rate. Care in how traces and it's
ground-imaging variant is traced, de coupled etc. can significantly help to reduce it. Also, decreasing slew-rate where not needed helps. Again, contradictory to what one would think of.
> 
> The magical trick of mixing with a signal is that you subtract frequency but maintain phase, which causes the time-difference amplified. This is the core of the DMTD measurement. Now, what bites you is the slew-rate is reduced by the same factor. But sure, to some degree with the other tricks you can gain something. Can be worth testing.
> 
> Now, with the high-speed ADCs you can approach this differently, convert the IQ samples through arctan, and then decimate the data to arbitrary narrow bandwidth, which is similar to the tricks I've described, but you avoid how noise eats you before you can filter it, since you look at more classical signal-to-noise rather than the more dubious slew-rate. However, it can be good to know that similar effects can be achieved using a bit of knowledge.
> 
> Also, at some point will the white and flicker noise limitations of the measurement cease to be a limitation and one can focus more on the stability between ones sources, which is what you want to do.
> 
> Hope it has been readable and illustrative.
> 
> Now, get some measurements done so we see where you are, and then can see your progress as you approach the various methods that I described and see how it pays off, or not.
> 
> Cheers,
> Magnus
> 
> On 2022-05-25 16:37, Hans-Georg Lehnard via time-nuts wrote: Thanks for your answer and the many suggestions what can be improved.
> 
> The first picture shows my concept for a prototype.
> 
> The input shaper consists of a 4:1 transformer with differential output
> and a TLV3501 comparator. The digital part with divider and start/stop
> logic fit for all 3 channels into a XCR3064XL CPLD. Maybe it is better
> to separate the channels later. The MC is a STM32H743 and runs with 450
> MHz (pll), clocked from the reference frequency. TDC7200 used as TDC.
> The measurement with spi readout takes about 5Âµs, so I decided for 10Âµs
> (100 kHz) sample time.
> 
> The second picture shows the measuring timing inside CPLD.
> 
> The TDC7200 runs in mode 1 and supplies only the fine time. The MC runs
> a 10 MHz (reference) counter with 3 capture channels as coarse time. So
> I only have to read the fine timer and the calibration register from the
> TDC.
> The TDC cannot measure from 0, so a reference cycle is added. (t = x
> +100ns).
> 
> For the averaging I had thought of a linear regression.
> 
> Hans-Georg
> 
> Am 2022-05-25 01:18, schrieb Magnus Danielson via time-nuts:
> 
> Hi,
> 
> The first limit you run into is the 1/tau slope of the measurement setup. This is often claimed to be white phase modulation noise, but it is also the effect of the single-shot resolution of the counter, and the actual slope level depends on the interaction of these two.
> 
> So, you might want to try a simple approach first, just to get started. Nothing wrong with that. You will end up want to get better, so I will try to provide a few guiding comments for things to think of and improve.
> 
> So, in general, try to use as high frequency as you can so that as you average down, your sqrt(f/f0) gets as high as possible as the benefit will be 1/sqrt(f/f0) where f is the oscillator frequency and f0 is the rate after average.
> 
> As you do ADEV, the f0 frequency will control your bandwidth.
> 
> The filter effect of the averaging as you reduce and sub-sample will help to some degree with anti-aliasing, but rather than doing averaging, consider doing proper anti-aliasing filtering as the effect of aliasing into these measures is established and improvements into the upcoming IEEE Std 1139 reflect this. In short, aliasing folds the white noise and straight averaging tends to be a poor suppressor of aliasing noise.
> 
> For white phase modulation (WPM) the expected ADEV response depends linearly with the bandwidth of the measurement filter. It's often modelled as a brick-wall filter, which it never is. For classical counters, the input bandwidth is high, then the sampling rate forms a Nyquist sampling frequency, but wide band noise just aliase around that. Anti-aliasing filter helps to reduce or even remove the effect, and then the bandwidth of the anti-aliasing filter replace the physical channel bandwidth. If the anti-aliasing is done digitally after the counter front-end, you already got some aliasing wrapping, but keeping that rate as high as possible keep the number of overlays low and then filtering-wise reduce it will get you better result.
> 
> For aliassing effects, see Claudio Calosso of INRIM. Great guy.
> 
> This is where the sub-sampling filter approach is nice, since a filter followed by sub-sampling removes the need to produce all the outputs of the original sample rate, so filter processing can operate on the sub-sampled rate.
> 
> As your measures goes for higher taus in ADEV, the significant amount of the ADEV power will be well within the pass-band of the filter, so just making sure you have a flat top avoids surprises. For shorter taus, the anti-aliasing filter will be dominant, so assume first decade of tau to be waste.
> 
> I say this to guide you to get the best result with the proposed setup.
> 
> The classical three-cornered hat calculation has a limitation in that it becomes limited by noise and can sometimes result in non-stable results. The Grosslambert analysis is more robust, since it is essentially the same as doing the cross-correlation measurement. The key is that you average down before squaring where as in the three-cornered hat to square early and is unable to surpress noise of the other sources with as good quality. For Grosslambert analysis, see FranÃ§ois Vernotte series of papers and presentation. FranÃ§ois is another great guy. I spent some time discussing the Grosslambert analysis with Demetrios the other week. I think I need to also say that Demetrios is a great guy too, not to single him out, but he really is.
> 
> There is another trick up the sleeve thought. If you do the modified Allan deviation (MDEV) processing, it actually integrate the sqrt() trick with measurement, achieving a 1/tau^1.5 slope for the WPM. This will push it down quicker if you let it use enough high rate of samples, so that you hit the flicker phase-modulation slope (1/tau), the white frequency modulation slope (1/tau^0.5) and finally flicker frequency modulation (flat) quicker. The reference levels will be different from ADEV for the various noise-types, but that you can look up in tables and correct for.
> 
> Cheers,
> Magnus
> 
> On 2022-05-24 18:37, Hans-Georg Lehnard via time-nuts wrote:
> 
> Hi,
> 
> my Name is Hans-Georg Lehnard from Germany and I'm new here, worked as a
> developer for hardware then for software and last as a system developer.
> Now I'm retired and I can play with hardware again ;-).
> 
> I have:
> 
> 4 x 20MHz Rubium (TEMEX MCFRS-1),
> 2 x 10MHz HP10811-60111
> 1 x Samsung UCCM GPSDO
> 1 x FA2 counter.
> lots of OCXO
> 
> and try to build a house standard that I can trust and qualify my
> oscillators.
> Reproducible measurements with the FA2 in 10s precision mode I trust to
> 10E-11.
> The short-term stability of the HP oscillators cannot be measured with
> it, or both are defective.
> The FA2 is not suitable for short-term measurements of 0.01 ... 1s.
> 
> For measurements against a reference frequency, the stability of the
> reference must be 5 to 10 times better than the measured frequency, and
> I don't have that. Now there are 2 options DMTD mixer or 3-hat
> measurements.
> Because I'm a digital person I chose the 3-hat method.
> 
> The idea is now to divide the 3 measuring frequencies (20 or 10 MHz)
> down to 100Khz and to measure the phases with a TDC against the next
> reference edge. Average the measurement results until I am down to 0.001
> ... 1 s. That should improve the 100ps resolution of a TDC7200 far
> enough and can also be output via RS232.
> 
> Are my thoughts correct and could it work ?
> 
> Hans-Georg
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
 _______________________________________________
time-nuts mailing list -- time-nuts at lists.febo.com
To unsubscribe send an email to time-nuts-leave at lists.febo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TIA_HP10811_1.PNG
Type: image/png
Size: 137733 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220528/47d8db3b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TIAfreqresolutionfix.png
Type: image/png
Size: 82673 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220528/47d8db3b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: counter.PNG
Type: image/png
Size: 138359 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220528/47d8db3b/attachment-0002.png>