[time-nuts] Thunderbolt oven / non-stable operating temperature

[WarrenS]

tvb posted>
>Were you able to test how quickly, or how well, the filter learned the tempco of the OCXO?

    Only at a couple of very general data points. 
Using a very Bad unit, the Kalman filter had an effect, although not very good in under 1/2 day.
After a week or so on a good unit, it helped maybe 3 to1 with ageing and Temperature TC.


>Yes (although please define "much"; are you talking 1% better or 10% better or 2x better). 
    "Much" is a 2 to 10 times improvement in the errors cause the undesirable compensated effects.
As an example, say your unit gives a 1e-10 freq ripple error when you turn on the over head Air condition, then that would go down by a factor of 3 or so.
Of course you could also just move your unit away for the AC and get a similar improvement. For the best performance improvement, you do both.


>Would it be possible to implement this advanced PID in LH? 
> Or as a first step, and to verify your conclusions, 
>would it be possible for LH to control the DAC during TBolt hold-over mode?

    Yes, There is already a very flexible, but very user unfriendly 'prove of concept' version, in LH.
It does have some of the feed-forward capability already there, along with lots of other things, as part of the many undocumented features of the external advanced PID controller now in LH.
but I do not see a reason for using it during hold over, Because the Tbolt S/W already does a good job with that now. but the external PID does help the non holdover mode.
LH's external PID even works remotely over the internet. So I have, in the past, controlled someone's Tbolt from my computer, getting better results than where available from the Tbolt's internal PID.  (Works until the connection is lost).
The terms I think that are available in the latest  LH's internal PID controller are Phase error, Freq error, time, Dac offset, and maybe temperature.

    Basically for the feed-forward in hold-over mode,  just need to add the sum of  K1 x temp_change (since start of holdover)  with  K2 x lapse_time (since start of hold over) to the Dac value (since start of hold over)
The hard part is to automatically find the best value for K1 and K2 during run time. In LH all the various variable K values are manually set.
Last count I think the Advanced PID had 7 or 8 K's that could be tuned.

>I agree this is true in theory (where epsilon != zero), but it's hard for me to believe true in practice. 
>I would guess the error term is totally dominated by short-term GPS noise, and anything else, like tempco or frequency drift, is secondary. 
>That's why it makes sense to apply these 2nd or 3rd order corrections during hold-over mode (where there is no GPS noise) but not for normal operation.

    The reason it works even during normal operation is that the GPS noise is mostly plus and minus (basically AC), 
where as the time drift and temperature drift errors are in one polarity. 
When these AC errors are filtered thru the LP integrator of the PID, the GPS noise cancels but the DC time and offset errors, even though smaller than the GPS noise, tend to dominate short term.  Short term being less than the PID's Time constant.
  
ws

************************
Tom Van Baak tvb at LeapSecond.com Posted

Hi Warren,

> Starting from a factory reset, it has something it will use in under 1/2 day. 

And that would explain my and Charles' null results. Nice.

> If the temperature has not been thru a few cycles and /or the Ageing is still at a high initial cold start rate and still changing, 
> the Kalman filter can give very poor results and actually make things worse.
> It gets better as time goes on, and after a few days with a predicable Osc, the Klaman filter will improve enough to help.

Were you able to test how quickly, or how well, the filter learned the tempco of the OCXO?

> It is a shame the Kalman filter is not also used during normal non holdover run time. 
> With a more advanced PID control loop it could be made to work much better.

Yes (although please define "much"; are you talking 1% better or 10% better or 2x better). Would it be possible to implement this advanced PID in LH? Or as a first step, and to veryify your conclusions, would it be possible for LH to control the DAC during TBolt hold-over mode?

> As it is, because the known systematic error information is not used as a feed-forward
> term to help the PID loop, any temperature change or ageing that does take place during
> control has to be totally corrected by an error signal. In short this means there will be
> unnecessary errors caused by both changing temperature or time if the Oscillator is not perfect.

I agree this is true in theory (where epsilon != zero), but it's hard for me to believe true in practice. I would guess the error term is totally dominated by short-term GPS noise, and anything else, like tempco or frequency drift, is secondary. That's why it makes sense to apply these 2nd or 3rd order corrections during hold-over mode (where there is no GPS noise) but not for normal operation.

> So what does this mean for the average Nut's Tbolt?   Mostly nothing. 
> The only time the temperature sensor has any effect is during holdover.

Thanks for stating both these facts so clearly. I cringe every time I hear someone replacing a 1C DS1620 sensor in their TBolt. The TAPR TBolts I tested years ago worked equally well regardless if they were 1C TBolts or ten milli-C TBolts.

/tvb