Re: [ntp:questions] Making ntpd tweak a TCXO
Thanks everyone for the replies. It was suggested off-list that I hack the Linux adjtime implementation to do what I want (tweak the TCXO instead of changing the kernel tick increment), so NTP would work as normal. That may be the simplest solution. Someone over at time-nuts suggested that the TCXO would be a good candidate for a "precision hardware clock" driver, part of the Linux PTP infrastructure. That is designed for the IEEE time-sync standard running over a network, but the PHC support is designed specifically for disciplining local clocks from a userspace program. Which is what I need to do. The TCXO clock would not even need to be used as the Linux system clock. But I still need to find a way of accurately stamping the ADC samples in wall-clock time. A few comments: Hal Murray [hmur...@megapathdsl.net] wrote: > I don't think servoing out the drift will do what you want. Suppose your > TCXO slows down a bit. After a while, ntpd notices, tweaks the drift, then > you notice, and adjust it to go the right speed. But during that time, the > clock was running a tiny bit slow so you lost a fraction of a cycle. Fair enough... I have been assuming that the frequency deviation is a zero-mean process, the integral of which will converge to zero over long periods. That does ignore the initial error. > I'm assuming your TCXO is driving your A/D. Yes. It spits out samples at a rate f_osc / 24 = 60 Hz. My ultimate task is to timestamp these samples in such a way that there are compressions and dilations in the time scale, but no discontinuities. --- About PWM to trim the TCXO: This is a fairly sophisticated processor (AM355x) with a lot more complexity than a typical microcontroller. I am sure that any of the clocks one gets out of the chip, including the PWM signals, will have troublesome jitter from a time-nut perspective. It seems unlikely to me, though, that this noise would exceed (or approach) one LSB of the PWM duty-cycle adjustment. That adjustment gives me 10 or 11 bits already, which theoretically gets into the single-digits ppb range on the TCXO. This is vast overkill for a $3 oscillator whose short-term instability will dwarf such tiny deviations. Mark ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Making ntpd tweak a TCXO
> I would like the data stream from my A/D to be long-term accurate. That is, > if the sampling rate is 60 Hz, I would like 60*86400*365 +/- 1 samples in a > [non leap] year. > To that end, I'd like to discipline the TCXO using ntpd. I would like it to > *not* change the virtual clock frequency in software as it usually does, via > adjtime or whatever hooks are provided by the OS. Instead, I want the > frequency corrections to go through my own driver to adjust the hardware > oscillator directly. > Does the NTP software provide any hooks that could be used to accomplish > this? I thought of a crude approach, simply writing a program to examine > the drift file periodically, and using that information to adjust the TCXO. > But that (a) fails to stop ntpd from adjusting the virtual clock frequency > within the OS, and (b) isn't really a proper control loop. I guess it would > work, sort of, as a last resort. I don't think servoing out the drift will do what you want. Suppose your TCXO slows down a bit. After a while, ntpd notices, tweaks the drift, then you notice, and adjust it to go the right speed. But during that time, the clock was running a tiny bit slow so you lost a fraction of a cycle. I'm assuming your TCXO is driving your A/D. I think what you want to do is monitor the times when your D/A gives you data. Suppose you set things up so that each buffer holds 1 second of data. When the buffer fills, grab the time. Compare that with the expected time. ... -- These are my opinions. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
