[time-nuts] Phase measurement of my GPSDO

John Ackermann N8UR jra at febo.com
Tue Apr 14 19:01:30 UTC 2020


It's a feature not a bug. :-)

I was going to address possible out-of-sequence output in this update,
but after lots and lots of thinking and experiments, and discussions
with a few bright folks on this list, I've come to the conclusion that
there is no 100% reliable way to do sample ordering within the TICC,
unless you provide it with additional information about the test
configuration and guarantee the integrity of the incoming signals.

It seems trivial to just sort samples if you make some assumptions: that
both channels are providing data at the same rate, that neither one will
ever glitch, and that both of them will always be present.

But... what if chA is at 1 PPS and chB is at 10 PPS?  What if you're
only measuring one channel?  Those could be solved by telling the TICC
what the configuration is, or doing some sort of signal analysis at the
start of the run, but that adds a lot of complexity to the code (and
operation).

And then, what if chA goes away during the measurement but chB keeps on
ticking?  What if one of the DUTs glitches so there is a missing sample?
 Or an extra one?  Those occurrences will screw up any attempt at
sequencing.

Apart from that, there is a subtle quirk in the TICC architecture
(thanks to TVB for spotting this) -- because of the way the TDC7200 chip
works, if a sample arrives on each input nearly simultaneously, you
cannot tell which one occurred first until *after* both samples are
processed.  Because there are non-deterministic latencies in the
processing loop, there can be a situation where, for example, chB has a
slightly earlier timestamp but is processed after chA. So you can get an
output file where the timestamps are not always in ascending order.

I was originally going to say that addressing this particular problem in
the firmware would be sensitive to all the gotchas mentioned in the
previous paragraphs.  But as I was typing I realized that there might be
a fairly simple way to guarantee that the output is at least in
increasing-timestamp order. That doesn't guarantee chA/chB sequencing,
though.  I'll play with this idea when I get a chance.

But taken all together, it is *much* easier to sequence the data outside
the TICC than within it.  Something like:

tail -f /dev/ttyUSB0 | tee >(grep "chA" > chA.dat) >(grep "chB" > chB.dat)

should do it. (Check the syntax; I didn't actually try this out but have
used the idea in the past.)

John
(whose hair, at least what's left of it, is more gray after having
wrestled with this for the last several months)

----
On 4/14/20 1:10 PM, Bob kb8tq wrote:
> Hi
> 
> Have you tried it with the latest firmware update?
> 
> I’ve never seen the problem here.
> 
> Bob
> 
>> On Apr 14, 2020, at 1:05 PM, Taka Kamiya via time-nuts <time-nuts at lists.febo.com> wrote:
>>
>> Bob, Tobias, et al
>>
>> TICC (TAPR) isn't problem free either.  It has a tendency to get TimeLab confused on data from port A and port B.  The data stream has identifier on them but TimeLab discards it.  Then it expects A and B comes alternately.  I communicated with both developers but for time being, the solution is to record the data and inspect. 
>>
>> --------------------------------------- 
>> (Mr.) Taka Kamiya
>> KB4EMF / ex JF2DKG
>>
>>
>>    On Tuesday, April 14, 2020, 7:48:34 AM EDT, Bob kb8tq <kb8tq at n1k.org> wrote:  
>>
>> Hi
>>
>> If the phase slips are “well behaved” they can be handled. The problem 
>> with a dual channel setup is that they are often not well behaved.  The
>> period is 100 ns so a frequency drift of 1 ppb will put you in trouble in 
>> under 2 minutes. 
>>
>> The only real answer is to do it properly and time tag the two outputs. 
>> Any other approach will get you yelling and screaming at the test set. 
>> Playing with two counters and not time tagging is in the “yelling and 
>> screaming” category as well. 
>>
>> Get a TAPPR TICC if you really want to do a DMTD. 
>>
>> Of course you *could* just use a single mixer. That works fine with the 
>> counter you already have. It will give you an A to B test just like a 
>> DMTD. The only limitation is the need to tune at least one of the oscillators 
>> in each pair. 
>>
>> There is no requirement that you tune only one. If both are tunable, 
>> you could tune one to the high end of its range and the other to the low end. 
>> With most OCXO’s, there is plenty of tune range. 
>>
>> Bob
>>
>>> On Apr 14, 2020, at 2:23 AM, Tobias Pluess <tpluess at ieee.org> wrote:
>>>
>>> Hey Bob
>>>
>>> ok now I see your point! you talk about the phase spillovers. Timelab and
>>> also Stable32 can correct for them, so it shouldn't be a problem, right?
>>>
>>> But I agree, if you cannot correct for the spillovers it becomes even more
>>> difficult.
>>>
>>>
>>> Tobias
>>>
>>> On Tue., 14 Apr. 2020, 01:38 Bob kb8tq, <kb8tq at n1k.org> wrote:
>>>
>>>> Hi
>>>>
>>>> The gotcha with using a conventional counter (as opposed to a time tagger)
>>>> is that you never know when things are going to “slip” past each other.
>>>> When they
>>>> do you get a major burp in your data. Bill’s setup is running a time
>>>> tagger ….
>>>>
>>>> ( = It runs an internal time count, each edge gets “labeled” with a
>>>> precise time
>>>> stamp that is good to nanoseconds or picoseconds. A Time Interval Counter
>>>> simply measures the time between edges. That sounds like the same thing,
>>>> but
>>>> it’s not quite ….)
>>>>
>>>>
>>>>> On Apr 13, 2020, at 6:11 PM, Tobias Pluess <tpluess at ieee.org> wrote:
>>>>>
>>>>> Hi Bob
>>>>>
>>>>> Riley suggests to use a single TIC
>>>>>
>>>>> http://wriley.com/A%20Small%20DMTD%20System.pdf
>>>>>
>>>>> when you look at the block diagram Fig. 4, you can see that one TIC
>>>> allows
>>>>> to compare two oscillators.
>>>>> I don't know exactly how, though :-)
>>>>
>>>> The gotcha with using a conventional counter (as opposed to a time tagger)
>>>> is that you never know when things are going to “slip” past each other.
>>>> When they
>>>> do you get a major burp in your data. Bill’s setup is running a time
>>>> tagger ….
>>>>
>>>>>
>>>>> OK and I see your point on the 8663. I will try to use another reference!
>>>>> I definitely didn't keep mine on for a long time. I didn't use the signal
>>>>> generator for a while now, so it was unplugged for a few months. I assume
>>>>> that's far from optimal for the 10811's stability.
>>>>
>>>> Best approach is to mount your reference off on it’s own and just power
>>>> it. That way
>>>> you don’t wear out all the guts of a fancy piece of gear.
>>>>
>>>> Bob
>>>>
>>>>>
>>>>>
>>>>> Tobias
>>>>>
>>>>>
>>>>>
>>>>> On Mon., 13 Apr. 2020, 23:53 Bob kb8tq, <kb8tq at n1k.org> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>>> On Apr 13, 2020, at 5:06 PM, Tobias Pluess <tpluess at ieee.org> wrote:
>>>>>>>
>>>>>>> Hi Bob
>>>>>>> awesome, thanks! of course it is 1e6, not 1e7, I got a mistake :-)
>>>>>>>
>>>>>>> Maybe I have some good OpAmps for this purpose in my box. I will try
>>>> it!
>>>>>> of
>>>>>>
>>>>>> You need something that is quiet (like the OP-37) and has a pretty good
>>>>>> slew
>>>>>> rate. Past that, there are a lot of candidates. The TI OPA-228 family is
>>>>>> one.
>>>>>>
>>>>>>> course I saw that my setup was not ideal as there was a bit of noise on
>>>>>> the
>>>>>>> signals which I guess does lead to some jitter in the trigger circuit
>>>> and
>>>>>>> therefore decreases my measurement noise floor.
>>>>>>
>>>>>> Typically a good limiter takes you from 3 or 4 digits up to 6 or 7 good
>>>>>> digits.
>>>>>> Net result is a measurement that’s good in the vicinity of parts in
>>>> 10^-13
>>>>>>
>>>>>>>
>>>>>>> Can you say something about how it would be done using a TIC?
>>>>>>> I don't have two identically good counters, but the HP 5335A could be
>>>>>> used
>>>>>>> as TIC, couldn't it.
>>>>>>
>>>>>> The standard way of doing the test is to run two counters / two TIC/s /
>>>>>> two whatever’s.
>>>>>> I know of no practical way to do it with a single 5335.
>>>>>>
>>>>>>>
>>>>>>> And the offset source I used is not directly the HP 10811, but the HP
>>>>>> 8663A
>>>>>>> Signal generator internally uses a 10811 as reference source. But I
>>>>>> didn't
>>>>>>> wait for days for it to warm up properly. (Should I?)
>>>>>>
>>>>>> The 8663 synthesizer adds a *lot* of crud to the 10811. Regardless of
>>>> how
>>>>>> you
>>>>>> use the 10811, it needs to be on for a while. How long very much depends
>>>>>> on
>>>>>> just how long it’s been off. Best to keep it on all the time.
>>>>>>
>>>>>>>
>>>>>>>> Fun !!!
>>>>>>> Yea, of course! :-)
>>>>>>> I already implemented the ADEV, MDEV and TDEV calculations in Matlab by
>>>>>>> myself. I use TimeLab to see what numbers I should expect, and then I
>>>>>> want
>>>>>>> to compute it all myself in Matlab because I want to see how it
>>>> actually
>>>>>>> works. ;-)
>>>>>>
>>>>>> Be careful any time you code this stuff for the first time. It’s
>>>> amazingly
>>>>>> easy
>>>>>> ( = I’ve done it ….) to make minor errors. That’s in no way to suggest
>>>> that
>>>>>> you should not code it up yourself. I generally do it in Excel or in C.
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best
>>>>>>> Tobias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 13, 2020 at 10:50 PM Bob kb8tq <kb8tq at n1k.org> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Ok, first the math:
>>>>>>>>
>>>>>>>> If your offset oscillator is 10 Hz high at 10 MHz, you have a:
>>>>>>>>
>>>>>>>> 10,000,000 / 10 = 1,000,000 : 1 multiplier in front of the DMTD
>>>>>>>>
>>>>>>>> You get to add a 6 to what Time Lab shows you.
>>>>>>>>
>>>>>>>> If you are getting an ADEV at 1 second of 1x10^-4 then that multiplier
>>>>>>>> gets you to 1x10^-10
>>>>>>>>
>>>>>>>> So, what’s going on?
>>>>>>>>
>>>>>>>> You can’t feed the mixer outputs straight into a counter. The counter
>>>>>>>> front
>>>>>>>> end does not handle LF audio sine waves very well. You need to do an
>>>>>>>> op-amp based limiter. A pair of OP-37’s in each leg ( or something
>>>>>>>> similar)
>>>>>>>> should do the trick.
>>>>>>>>
>>>>>>>> Second, the offset source needs to be pretty good. A 10811 tuned high
>>>>>> with
>>>>>>>> both the mechanical trim and the EFC is a pretty good choice to start
>>>>>> out.
>>>>>>>>
>>>>>>>> If you only have one counter, simply ignore the second channel. You
>>>> are
>>>>>> now
>>>>>>>> running a single mixer. It still works as a comparison between the
>>>>>> offset
>>>>>>>> oscillator
>>>>>>>> and your DUT.
>>>>>>>>
>>>>>>>> If you want to do it properly as a DMTD, then you set up two counters.
>>>>>> One
>>>>>>>> to measure mixer A and the other to measure mixer B.  Set them both up
>>>>>> to
>>>>>>>> measure frequency. Time tag the data files so you know which reading
>>>>>>>> matches up with which.
>>>>>>>>
>>>>>>>> Fun !!!
>>>>>>>>
>>>>>>>> Bob
>>>>>>>>
>>>>>>>>> On Apr 13, 2020, at 3:18 PM, Tobias Pluess <tpluess at ieee.org> wrote:
>>>>>>>>>
>>>>>>>>> Hi again Bob
>>>>>>>>>
>>>>>>>>> I tried to do some measurements with a DMTD!
>>>>>>>>> In my junk box I found a little PCB from earlier experiments on that
>>>>>>>> topic,
>>>>>>>>> with a power splitter and two SRA-3H mixers, it was even already
>>>> wired
>>>>>>>> for
>>>>>>>>> the DMTD configuration. So I gave it a try!
>>>>>>>>> As "transfer oscillator" I used my HP 8663A signal generator, and set
>>>>>> it
>>>>>>>>> high in frequency by 10 Hz. To the two mixers, I connected the two
>>>>>> 10MHz
>>>>>>>>> signals and at the mixer outputs, I put a little lowpass filter with
>>>>>>>> 100Hz
>>>>>>>>> corner frequency.
>>>>>>>>> The output signals from the two SRA-3 mixers are almost 0.5Vpp, so I
>>>>>>>> tried
>>>>>>>>> to feed them directly into the HP 5335A TIC and used the TI mode to
>>>>>>>> measure
>>>>>>>>> the delay between the two signals.
>>>>>>>>> This gives 10 readings/sec, which I try to process with TimeLab.
>>>>>>>>> It does give some interesting graphs, but I don't know yet how to
>>>>>>>> correctly
>>>>>>>>> set up TimeLab for this kind of measurement. I.e. now, I get an ADEV
>>>> in
>>>>>>>> the
>>>>>>>>> order of 1e-4 (at tau=1sec) to 1e-5 (at tau=500sec). So does that
>>>> mean
>>>>>> I
>>>>>>>>> simply need to multiply this with 1e-7 to get the *real* ADEV at
>>>> 10MHz?
>>>>>>>>> this would mean that my real ADEV is in the range of 1e-11 to 1e-12,
>>>>>>>> which
>>>>>>>>> is indeed my target value, BUT I expect that things are not that
>>>>>> simple.
>>>>>>>>> (i.e. what if I didn't set the transfer oscillator high by +10Hz but
>>>>>> only
>>>>>>>>> by 9.9Hz for example).
>>>>>>>>> Can you give some hints on that?
>>>>>>>>> Of course I also did the noise floor test (i.e. I fed the 10MHz
>>>> signal
>>>>>>>> into
>>>>>>>>> a power splitter and connected the two outputs to my DMTD with two
>>>>>>>>> different lenghts of cables. This gave results starting at 1e-4 going
>>>>>>>> down
>>>>>>>>> to 1e-7, maybe it would have gone even lower but I measured only for
>>>> a
>>>>>>>>> couple of minutes.)
>>>>>>>>>
>>>>>>>>> Can you give some hints on that?
>>>>>>>>>
>>>>>>>>> Best
>>>>>>>>> Tobias
>>>>>>>>> HB9FSX
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 3, 2020 at 1:45 PM Bob kb8tq <kb8tq at n1k.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> The quick way to do this is with a single mixer. Take something
>>>> like
>>>>>> an
>>>>>>>>>>> old
>>>>>>>>>>> 10811 and use the coarse tune to set it high in frequency by 5 to
>>>> 10
>>>>>>>> Hz.
>>>>>>>>>>>
>>>>>>>>>>> Then feed it into an RPD-1 mixer and pull out the 5 to 10 Hz audio
>>>>>>>> tone.
>>>>>>>>>>> That tone is the *difference* between the 10811 and your device
>>>> under
>>>>>>>>>>> test.
>>>>>>>>>>> If the DUT moves 1 Hz, the audio tone changes by 1 Hz.
>>>>>>>>>>>
>>>>>>>>>>> If you measured the 10 MHz on the DUT, that 1 Hz would be a very
>>>>>> small
>>>>>>>>>>> shift
>>>>>>>>>>> ( 0.1 ppm ). At 10 Hz it’s a 10% change. You have “amplified” the
>>>>>>>> change
>>>>>>>>>>> in frequency by the ratio of 10 MHz to 10 Hz ( so a million X
>>>>>> increase
>>>>>>>> ).
>>>>>>>>>>>
>>>>>>>>>>> *IF* you could tack that on to the ADEV plot of your 5335 ( no,
>>>> it’s
>>>>>>>> not
>>>>>>>>>>> that
>>>>>>>>>>> simple) your 7x10^-10 at 1 second would become more 7x10^-16 at 1
>>>>>>>>>>> second.
>>>>>>>>>>>
>>>>>>>>>>> The reason its not quite that simple is that the input circuit on
>>>> the
>>>>>>>>>>> counter
>>>>>>>>>>> really does not handle a 10 Hz audio tone as well as it handles a
>>>> 10
>>>>>>>> MHz
>>>>>>>>>>> RF signal. Instead of getting 9 digits a second, you probably will
>>>>>> get
>>>>>>>>>>> three
>>>>>>>>>>> *good* digits a second and another 6 digits of noise.
>>>>>>>>>>>
>>>>>>>>>>> The good news is that an op amp used as a preamp ( to get you up to
>>>>>>>> maybe
>>>>>>>>>>> 32 V p-p rather than a volt or so) and another op amp or three as
>>>>>>>>>>> limiters will
>>>>>>>>>>> get you up around 6 or 7 good digits. Toss in a cap or two as a
>>>> high
>>>>>>>> pass
>>>>>>>>>>> and low pass filter ( DC offsets can be a problem ….) and you have
>>>> a
>>>>>>>>>>> working
>>>>>>>>>>> device that gets into the parts in 10^-13 with your 5335.
>>>>>>>>>>>
>>>>>>>>>>> It all can be done with point to point wiring. No need for a PCB
>>>>>>>> layout.
>>>>>>>>>>> Be
>>>>>>>>>>> careful that the +/- 18V supplies to the op amp *both* go on and
>>>> off
>>>>>> at
>>>>>>>>>>> the
>>>>>>>>>>> same time ….
>>>>>>>>>>>
>>>>>>>>>>> Bob
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>>>
>>> _______________________________________________
>>> 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.
>>
>> _______________________________________________
>> 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