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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
