[time-nuts] Re: "software TCXO" on commodity computers
On Mon, Apr 04, 2022 at 10:07:26PM +, Greg Maxwell wrote: > Odd that they don't seem to mention the tempcomp in chrony: > > https://chrony.tuxfamily.org/doc/2.4/chrony.conf.html#tempcomp FWIW, they do mention chrony (without a reference) in Section 2.5 Software Temperature Compensation (PDF page 5): 'In computers, chrony can correct for temperature errors given the temperature-frequency relationship and a temperature sensor.' Best regards, Georg -- 'Linux is open source and can be modified by anyone, as such we do not support the OS.' (Samsung SSD Customer support, 2015-06-13, https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005/comments/56 ) ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: GPSDO Control loop autotuning
For isolating noise, (for the purpose of off line analysis) , using ICA (Independent Component Analysis) , a kind of blind source separation , can assist parting out the various noises to assist understanding the system better . There are some Python primers around for it. fantastic discussion going on here. love it. glen On 12/04/2022 6:42 pm, Markus Kleinhenz via time-nuts wrote: Hi Tobias, Am 11.04.2022 um 13:33 schrieb Pluess, Tobias via tim ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Looking for info on Scientific Atlanta 4647 IF noise test rig
All this 1/f noise talk got me to thinking about some of my noise measurement and generation projects over the years. One project that I want to revisit is one for making "nearly-true" random white noise all the way down to DC, for comparing and testing things in the very low frequency 1/f realm. I have several different noise generator build/repair projects in the works that I haven't even looked at in years. One in particular is something I had pictured a while back, using this Scientific Atlanta 4647 IF tester thing that I got long ago, but could not find any info at all. I dug it out from under a pile and looked it over. Today I did find a little info on it (a brochure), that at least gives some idea of how it's supposed to work. I checked it out and it seems to do about what it says. The brochure is here: https://www.atecorp.com/atecorp/media/pdfs/data-sheets/scientific-atlanta-4647_brochure.pdf It's just a few pages, and every other so-called "manual" that shows on the downloading sites seems to be that same thing or less. I'm wondering if anyone is familiar with this or knows of any documentation - the ideal of course, being a pdf service manual with schematics. A paper manual (supposedly) popped up on ebay, but the picture is of an HP binder with unknown contents. I'd prefer to find a pdf somewhere rather than spend fifty bucks for something dubious, or the hassle of figuring it out. What's nice about this unit is that it has "calibrated" and settable noise and carrier levels, and better yet, it seems to be in working order as it is. It makes pretty good (15 dB crest factor) white noise in a flat band about 50-90 MHz, that normally gets added to a 70 MHz IF carrier, in various proportions and modes for testing. It also makes its own 70 MHz carrier, if needed. What I've been thinking is to simply mix the 70 MHz out with the noise-only (mode) out, then LPF to say 20 MHz or less, and there you go - a nice DC to whatever white noise source. I'll start with some experiments with external stuff, then probably build it into the box as another feature. The added items may include an amplifier to get the 70 MHz up to 7-10 dBm for mixer drive, and the LPF(s), maybe a DC-coupled post amp, and some miscellaneous for routing and control. The main thing is that the basic box already takes care of most of what's needed, including space and power. The available 50-90 MHz noise is quite stout, specified up to -73 dBm/Hz. I looked at it on the 8566B, and the noise envelope with 3 MHz RBW can almost bury the 0 dBm carrier. Likewise on a scope, the nice 70 MHz sinewave disappears into a cloud of noise as the power goes up. The flatness, crest factor, and leveling won't be as good as the original signals, but I think still pretty decent. One complication is that this thing is all 75 ohm, so I'll probably need to do some mods here and there to make it 50. Ed ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: GPSDO Control loop autotuning
Hi Tobias, Am 11.04.2022 um 13:33 schrieb Pluess, Tobias via time-nuts: > Hi Markus, > > Thanks for your hints. That's actually what I meant. One could use the > Kalman filter to "improve" the noise of the 1PPS signal being measured, and > then use the observed output from the Kalman filter as input to a > controller, which still might be a PI controller. Right? That is true, but I think you would be wasting the Kalman filters potential. > > Also thanks for your valuable links, I will look through these. > When I look at examples of Kalman filters, they often deal with position > and velocity control and the state variables are often the position, speed > and sometimes even acceleration. > In the case of a GPSDO, what should the states be? > I was thinking a lot about this topic, and I believe there are several > possibilities. What I found in literature are two or three state clock models. The Two-state clockmodel, which is also part of the Galleani Paper I mentioned. It is composed of the phase deviation and the frequency deviation. This allows you to model the typical types of clock noise present/dominant in atomic clocks (the field where these type of filters and controllers are typically used it seems) One could also use a three state clock model but then you get problems with the observability and controllability of the system because you only get measurements of the phase error. > For instance, one could use only the phase as state. In that case, the > Kalman filter would be 1D and this would be the simplest case. > On the other hand, we could also have the phase and the frequency as > states, because the frequency is the derivative of the phase, and this > would be analogous to the position-velocity example. I am not sure which > one of these models shall be used, is there a "right" one and a "wrong" > one, i.e. with the wrong one it won't work at all? > > I believe, but am not 100% sure, the state space model with just one state > would work, with the phase being used as the only state. > > phi[k] = phi[k-1] + K_VCO * u > > where u is the control input. Further, the Kalman filter needs to know the > process noise and measurement noise. I would guess that the process noise > in our case is very small, as the OCXO is very stable. On the other hand, > the measurement noise is large, because the 1PPS coming from the GPS module > has some jitter which affects the measurement. However, and this is > probably an interesting idea, the GPS module outputs an estimate of the > timing accuracy, so couldn't we use this information to estimate our > measurement noise? the timing accuracy squared would directly yield the > measurement variance. And the above state equation could be used for the > Kalman filter, together with the estimated timing accuracy information > which we get from the GPS module. The Kalman filter (not extended, unscented etc) is ideal for white noise so things like sawtooth noise should be removed. The whole setup of disciplining a local clock with a GPS-Receiver can be viewed as follows: You have two Clocks, your local one and the GPS-ensemble clock. Since one can only measure time differences what you are modeling for your kalman filter is the phase deviation and the frequency deviation between the two, where the clock noise Matrix is the sum of both clocks Matrices (as their noises are independent). The measurement process is the observation of the 1PPS Signal. The measurement noise could be derived from the ADEV of the GPS PPS approximated as WPN generated by quantization error. Theres a great write up by John Ackerman N8UR of the Performances of current ublox GPS receivers, which suggests that the 1pps of a sawtooth corrected f9t is still in good approximation a WPN reference. I can't say how the GPS modules accuracy estimate would play into this process, because if you derive a LQG-controller from the designed kalman filter the measurement noise determines the controller gains and should be fixed I think. Another interessting point about an LQG-controller or other state-space controllers: If you use a two-state model for your kalman filter you get estimates for the phase deviation and the frequency deviation and the controller can use the information from both. The design process of LQG controllers allows the use of weights for the different dimensions of the state vector, meaning you can assign priorities to them. Since these methods are mostly used for atomic clocks and atomic clock ensembles where frequency stability is more important than 0 phase deviation, most papers suggest keeping the frequency stable first and correcting phase offsets second. https://github.com/konstantin-gm/Steering Has a practical implementation in Python as used in the "a Practical Approach..." Paper. > But I am unsure whether this will work, at first it almost sounds too > simple :-) > > Then, once per second, the Kalman equations are calculated and the Kalman > filter yields an estimat
[time-nuts] Re: GPSDO Control loop autotuning
Tobias, On 2022-04-09 18:13, Pluess, Tobias via time-nuts wrote: Hi all, My reply to this topic is a bit late because I have been busy with other topics in the meantime. To Erik Kaashoek, You mentioned my prefilter. You are absolutely right, I looked again at my prefilter code and decided it was garbage. I have removed the prefilter. Thanks to your hint I also found another mistake in my PI controller code, which led to wrong integration times being used. I corrected that and the controller is now even more stable. I made some tests and the DAC output changes less than before, so I guess the stability is even better! To all others. I discussed the topic of improving my GPSDO control loop with a colleague off-list and he pointed out that, on this list, there was a while ago a post about Kalman filters. I totally forgot about this, I have looked at them at university a couple years ago, but never used it and therefore forgot most of it. But I think it would be interesting to try to implement the Kalman filter and compare its performance with the PI controller I currently have. I guess the first step before thinking about any Kalman filters is to find the state space model of the system. I am familiar with the state space, but one topic I was always a bit struggling with is the question which variables I should take into account for my state. In the case of the GPSDO, all I can observe is the phase difference between the locally generated 1PPS and the 1PPS that comes from the GPS module. On the other hand, I am not only interested in the phase, but also in the frequency, or, probably, in the frequency error, so I think my state vector needs to use the phase difference (in seconds) and the frequency error (?). So my attempt for a GPSDO state space model is: phi[k+1] = phi[k] - T * Delta_f[k] Delta_f[k+1] = Delta_f[k] + K_VCO * u y[k] = phi[k] I see you already got some help, but hopefully this adds some different angles. A trivial state-space Kalman would have phase and frequency. Assuming you can estimate the phase and frequency noise of both the incoming signal and the steered oscillator, it's a trivial exercise. It's recommended to befriend oneself with Kalman filters as a student exercise. It can do fairly well in various applications. This simple system ends up being a PI-loop which is self-steered in bandwidth. Care needs to be taken to ensure that the damping constant is right. The longer one measures, the narrower bandwidth the filter has as it weighs in the next sample, and the next. However, we know from other sources that we not only have white phase and white frequency noise in sources, both reference and steered oscillator. We also have flicker noise. That won't fit very well into the model world of a normal Kalman filter. If we know the tau of a filter, we can approximate the values from TDEV and ADEV plots, but the Kalman filter will self-tune it's time-constant to optimize it's knowledge of the state, thus sweeping over the tau plots. Now, we can make approximations to where we expect them to end up and take out suffering in a somewhat suboptimal path to that balance points. So, you can go the Kalman path, or choose pseudo-Kalman and have separate heuristics that does coarser tuning of bandwidth on a straight PI loop. Pick and choose what fits you best. It can vary from application to application. Keep damping high or else the Q will cause an ADEV bump. Increasing the degree to include linear drift has the benefit of tracking in frequency drift. Regardless if this is done as a PII^2 or 3-state Kalman, care should be taken to ensure stability as it is not guaranteed that root-loci stays on the stable path. Worth doing thought. I seem to recall a few papers in the NIST T&F archive as well as in PTTI archive on Kalman filter models for oscillator locking. The HP "SmartClock" paper should also be a good read. A downside to Kalman filter is numerical precision issue, as core parameters is rescaled. There is a certain amount of precision loss there. I see the same problem occurring in more or less all least square and linear regression approaches I've seen. As I have been working on a different approach to least square estimation, it turns out that it is beneficial also on the numerical precision issue if you want, since the accumulation part can be made loss-less (by tossing bits on it) and only the estimation phase has issues, but since the estimation equations does not alter core accumulation it does not polute that state. Turns out there is multiple way of doing the same thing, and the classical school-book approach is not always the wisest approach. Some time back there was some referene to papers relating to verifying performance by monitoring the noise out of the phase detector. It is applicable to a number of lock-up PLL/FLLs. I found it an interesting read. I've also looked at that state stabilize many hours in the lab. Be awa
