[time-nuts] Lady Heather's Tbolt oscillator auto-tune function

Bob Camp kb8tq at n1k.org
Wed Sep 14 11:08:15 UTC 2016


Hi

> On Sep 13, 2016, at 10:36 PM, Scott Stobbe <scott.j.stobbe at gmail.com> wrote:
> 
> Hi bob, thank you for the polite response regarding rise time, indeed I
> would fully agree.
> 
> The rise time I was referring to was the DAC efc value in the plot mark had
> previously attached. He just included a second plot as well. It would
> appear the tbolt is doing something else aggressively before going into
> a PLL, perhaps coarsely phase steering the last +-50 ns, but then runs out
> microseconds in error?

There is some disagreement about the TBolt having multiple lock steps past
the initial jam set of the PPS. What is fairly clear is that it does not step gain 
and control settings past the initial “setup” of the PPS.

Bob


> 
> On Tuesday, 13 September 2016, Bob Camp <kb8tq at n1k.org
> <javascript:_e(%7B%7D,'cvml','kb8tq at n1k.org');>> wrote:
> 
>> Hi
>> 
>> The rise time of the edge is not a good measure of the accuracy of the
>> timing It
>> simply is a way to look at how fast your gate can ramp a signal.
>> 
>> If you do a long term comparison of the frequency vs time and the time
>> error vs time
>> you will see that a tight (small) damping keeps the time close at the
>> expense of
>> jerking the frequency around a lot. A loose (large) damping does not
>> change the
>> frequency much, but the time wanders quite a bit.
>> 
>> Simply put: There is no free lunch.
>> 
>> Bob
>> 
>>> On Sep 13, 2016, at 9:01 PM, Scott Stobbe <scott.j.stobbe at gmail.com>
>> wrote:
>>> 
>>> Bob, that is an excellent proof by contradiction. The reason I asked is
>> on
>>> the plot Mark shared that first rising edge is pretty sharp for a system
>>> with a 500 s time constant.
>>> 
>>> On Tuesday, 13 September 2016, Bob Camp <kb8tq at n1k.org> wrote:
>>> 
>>>> Hi
>>>> 
>>>> The pps sync is done by resetting the counter that generates the PPS.
>> At a
>>>> 1 ppm frequency
>>>> offset, it could take 500,000 seconds to steer it in with the OCXO. It
>>>> unlikely people would wait
>>>> for over a week for the PPS to line up ….
>>>> 
>>>> Bob
>>>> 
>>>>> On Sep 13, 2016, at 5:58 PM, Scott Stobbe <scott.j.stobbe at gmail.com
>>>> <javascript:;>> wrote:
>>>>> 
>>>>> Interesting discussion about startup. At startup the phase error of the
>>>>> synthesized PPS is +- 0.5 s. Is this coarsely set to the nearest ocxo
>>>> cycle
>>>>> once gps time is established (would make sense to do it this way), or
>> is
>>>>> the half second recovered steering the ocxo?
>>>>> 
>>>>> On Tuesday, 13 September 2016, Charles Steinmetz <
>> csteinmetz at yandex.com
>>>> <javascript:;>>
>>>>> wrote:
>>>>> 
>>>>>> Mark wrote:
>>>>>> 
>>>>>> I just ran a tbolt (which has been off for a couple of months) and
>>>> logged
>>>>>>> the state for a couple of hours...  and then remembered something
>>>> about the
>>>>>>> initial DAC value setting that I had figured out long ago... it has
>>>> little
>>>>>>> to nothing to do with oscillator disciplining.    The tbolt drives
>> the
>>>> GPS
>>>>>>> from the 10 MHz ocxo.  If the ocxo is too far off freq it can't track
>>>>>>> satellites.   The initial dac setting is used to speed up acquisition
>>>> of
>>>>>>> satellites and not to speed up the OCXO disciplining loop lock.
>>>>>>> 
>>>>>> 
>>>>>> Well...  by doing the one, it also does the other.
>>>>>> 
>>>>>> As soon as a satellite is acquired (after a couple of minutes), the
>> DAC
>>>>>>> voltage jumps and the disciplining starts.  A few seconds later when
>>>> more
>>>>>>> sats are tracked, it gets underway in earnest (and by then the OCXO
>> is
>>>> warm
>>>>>>> enought to be within 0.1 Hz).  After 1 hour the box temperature has
>>>>>>> stabilized and the freq is within a couple of milli Hz.  After two
>>>> hours
>>>>>>> the oscillator has settled down to the point where the DAC curve goes
>>>> into
>>>>>>> "wandering around" instead of following  a smooth decay compensating
>>>> for
>>>>>>> the oscillator warm-up.  The attached image show the first hour of
>> the
>>>>>>> process.
>>>>>>> 
>>>>>> 
>>>>>> If you look carefully at the first 3-4 minutes, you'll see it does
>>>> exactly
>>>>>> what I described.  The DAC reference is 0.510v, and the scale is
>>>>>> 5000uV/division (=5mV/division).  According to the paramaters, the
>>>> initial
>>>>>> DAC voltage (INIT) = 0.499v.  I assume this was previously stored as
>> the
>>>>>> DAC value after the Tbolt had fully stabilized, some time in the past.
>>>>>> 
>>>>>> Sure enough, the DAC voltage starts at just about 0.499v (it looks
>> like
>>>>>> 0.494v on the graph), and when the second satellite is acquired it
>> jumps
>>>>>> very quickly to 0.529v -- an overshoot of some 55% -- before settling
>>>> back
>>>>>> to ~0.518v, at which time it appears to be on frequency within 1e-8 or
>>>> so.
>>>>>> From that point disciplining continues as the crystal warms up.
>>>>>> 
>>>>>> If one accepted my suggestion, the initial DAC voltage would be set to
>>>>>> ~0.518v for this oscillator.  In that case, it should be within a few
>>>>>> millivolts of the voltage required when the second satellite is
>> acquired
>>>>>> and the huge step with its 55% overshoot should be avoided.
>>>>>> 
>>>>>> I would be very interested to see the result of another dead cold
>> start
>>>> of
>>>>>> this same Tbolt, with INIT set to 0.518v.  Of course, the time at
>> which
>>>> the
>>>>>> second satellite is acquired (hence, the temperature of the crystal
>> when
>>>>>> discipline begins, and thus, the exact DAC voltage required for a
>>>> stepless
>>>>>> transition, will be a bit different from one start to the next, so it
>>>> won't
>>>>>> be perfect.  But it will be a hell of a lot better than starting from
>>>>>> 0.499v).
>>>>>> 
>>>>>> Now -- does what happens during the first five minutes really make any
>>>>>> difference, given that no time-nut is going to do serious work with a
>>>> GPSDO
>>>>>> for at least several hours after a cold start?  No, probably not.  But
>>>> we
>>>>>> are time-nuts, after all, aren't we?
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Charles
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> time-nuts mailing list -- time-nuts at febo.com <javascript:;>
>>>>>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>>>>>> ailman/listinfo/time-nuts
>>>>>> and follow the instructions there.
>>>>>> 
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts at febo.com <javascript:;>
>>>>> 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 <javascript:;>
>>>> 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/m
>> ailman/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/m
>> ailman/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