NTP phase lock loop inputs and outputs? - NTP

This is a discussion on NTP phase lock loop inputs and outputs? - NTP ; I'm doing NTP exchanges to determine my clock offset. I use this to adjust my clock frequency, but there's a lot of lag so I overshoot by too much and it oscillates around the reference frequency. This is an audio ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 40

Thread: NTP phase lock loop inputs and outputs?

  1. NTP phase lock loop inputs and outputs?

    I'm doing NTP exchanges to determine my clock offset. I use this to
    adjust my clock frequency, but there's a lot of lag so I overshoot by
    too much and it oscillates around the reference frequency. This is an
    audio clock so I have to do my own NTP stuff. I think I want to use a
    phase lock loop as described in the NTP literature, but I'm confused
    by the terminology (and possibly the math) so I'm not sure what the
    inputs or outputs should be.

    If my reference clock is running at ~44100 Hz and through my NTP
    exchanges, I get an instantaneous offset of -20 Hz, I want to adjust
    my clock to 44080 Hz, but no more than 5 Hz/sec (so it's not audible)
    and that instantaneous offset will likely change as it narrows in on
    the true frequency. The formula I've seen for NTP's PLL is:

    y = (Vs*u) / (64Tc)^2

    I do NTP packet exchanges every 2 seconds so I think that resolves to:

    y = (2*Vs) / 16384

    Is Vs the actual reference frequency estimate (44080 Hz in this case)?
    I'm not sure how I use the result of the equation to adjust the clock.

    I guess my question is that if I think my frequency is 44100 Hz and
    via an NTP exchange, I calculate I'm off by -20 Hz, how should I
    calculate what I should set my frequency to, to slowly sync to the
    reference frequency (no more than 5 Hz/sec) while also factoring in
    the previous clock offset estimate?

    The current scheme I'm using to simply set my clock to 44100-5 Hz
    (capping the -20 Hz offset to 5) every 2 seconds doesn't work very
    well because it's too slow to realize that the direction of the offset
    has changed because the absolute clock offset is still negative (e.g.
    went from -20 to -5, but it's still negative so it thinks it still
    needs to reduce the clock frequency when it should probably increase
    it or leave it the same).

  2. Re: NTP phase lock loop inputs and outputs?

    skillzero@gmail.com wrote:

    > If my reference clock is running at ~44100 Hz and through my NTP
    > exchanges, I get an instantaneous offset of -20 Hz,


    .....you have broken hardware. Once you correct for systematic error, a
    crystal should be within single figure parts per million, even over a
    wide temperature range, so your maximum frequency error in the sampling
    clock should be about 0.5Hz., or at A=440, about 0.0044Hz.

    Note that the maximum correction that ntpd can apply is 500ppm, which
    corresponds to 25Hz at 44.1kHz. It will only apply that correction if
    there is a sustained and serious synchronisation error.

    Incidentally, this is an example of an application where running the
    core clock discipline algorithm at long intervales would be very disruptive.

  3. Re: NTP phase lock loop inputs and outputs?

    On May 18, 11:46*pm, David Woolley
    > > If my reference clock is running at ~44100 Hz and through my NTP
    > > exchanges, I get an instantaneous offset of -20 Hz,

    >
    > ....you have broken hardware. *Once you correct for systematic error, a
    > crystal should be within single figure parts per million, even over a
    > wide temperature range, so your maximum frequency error in the sampling
    > clock should be about 0.5Hz., or at A=440, about 0.0044Hz.


    I was just giving an example for illustrative purposes, but this
    hardware can be up to 50 Hz off in normal conditions.

    > Note that the maximum correction that ntpd can apply is 500ppm, which
    > corresponds to 25Hz at 44.1kHz. *It will only apply that correction if
    > there is a sustained and serious synchronisation error.


    I'm not using ntpd. This is a specialized application that uses the
    NTP protocol and I'm trying to adapt some of the NTP algorithms to
    discipline an audio clock.

    I'm mainly interested in understanding the NTP phase lock loop, what
    its inputs should be given my data, how to apply it to that data, and
    how to convert the results into something I can use to adjust the
    hardware frequency.

    The NTP literature I've read is very heavy on terminology I'm not
    familiar with so I was hoping for something along the lines of "if an
    NTP exchange says your clock is -20Hz off (and that's the only data I
    really have), plug that number into this equation, and the result is
    the number of Hz to add or subtract from your current frequency to
    slew it toward the reference frequency (until the next NTP exchange in
    2 seconds)".

    The simple scheme I'm using now overshoots then undershoots too much
    so I was hoping something like the NTP phase lock loop could help
    improve it.

  4. Re: NTP phase lock loop inputs and outputs?

    skillzero@gmail.com wrote:

    > I was just giving an example for illustrative purposes, but this
    > hardware can be up to 50 Hz off in normal conditions.


    You shouldn't use your phase locked loop to correct this sort of
    1,000ppm error. You should calibrate it out before you start.

    Note that, if you only let ntpd use its PLL algorithms, its response to
    this sort of error is very poor. With ntpd you would really need to
    ensure it does a frequency calibration, in which it waits about 15
    minutes without correcting frequency and looks at the total drift, then
    instantaneously applies a total correction for that drift.

    Phase lock loops are good at tracking slow variations in remote
    frequency/compensating for slow variations in local frequency, but they
    are not good at getting initial lock, unless you sample very fast. (A
    pure hardware PLL would sample at 44.1kHz, in this case, but you
    presumably have network jitter and packetisation effects that compromise
    your ability to do this.

    Even with fast true phase locking at the signal frequency, PLLs that
    have to change frequency generally have a fast acquisition mode, before
    they enter the tracking mode.

  5. Re: NTP phase lock loop inputs and outputs?

    "skillzero@gmail.com" writes:

    >I'm doing NTP exchanges to determine my clock offset. I use this to
    >adjust my clock frequency, but there's a lot of lag so I overshoot by


    What do you mean "a lot of lag"?

    >too much and it oscillates around the reference frequency. This is an


    The time constants of the reference ntp are essentially a second order
    critically damped system. Yours seems to be underdamped.

    Why don't you just use the reference implimentation.

    >audio clock so I have to do my own NTP stuff. I think I want to use a


    Why do you have to do your own ntp stuff?

    >phase lock loop as described in the NTP literature, but I'm confused
    >by the terminology (and possibly the math) so I'm not sure what the
    >inputs or outputs should be.


    >If my reference clock is running at ~44100 Hz and through my NTP


    I have no idea what you are describing here. What is your clock? A CD
    spinning? Those frequencies are nowhere near PPM accuracy.

    >exchanges, I get an instantaneous offset of -20 Hz, I want to adjust


    What in the world does this mean?

    >my clock to 44080 Hz, but no more than 5 Hz/sec (so it's not audible)
    >and that instantaneous offset will likely change as it narrows in on
    >the true frequency. The formula I've seen for NTP's PLL is:


    > y = (Vs*u) / (64Tc)^2


    >I do NTP packet exchanges every 2 seconds so I think that resolves to:


    > y = (2*Vs) / 16384


    >Is Vs the actual reference frequency estimate (44080 Hz in this case)?
    >I'm not sure how I use the result of the equation to adjust the clock.


    >I guess my question is that if I think my frequency is 44100 Hz and
    >via an NTP exchange, I calculate I'm off by -20 Hz, how should I
    >calculate what I should set my frequency to, to slowly sync to the
    >reference frequency (no more than 5 Hz/sec) while also factoring in
    >the previous clock offset estimate?


    >The current scheme I'm using to simply set my clock to 44100-5 Hz
    >(capping the -20 Hz offset to 5) every 2 seconds doesn't work very
    >well because it's too slow to realize that the direction of the offset
    >has changed because the absolute clock offset is still negative (e.g.
    >went from -20 to -5, but it's still negative so it thinks it still
    >needs to reduce the clock frequency when it should probably increase
    >it or leave it the same).


    I think maybe you need to be clearer in what it is that you are trying to
    do.
    ntp does not exchange frequencies. ntp exchanges time stamps. How do you
    generate your time stamps? What is that "reference frequency"?



  6. Re: NTP phase lock loop inputs and outputs?

    Unruh wrote:

    > I think maybe you need to be clearer in what it is that you are trying to
    > do.
    > ntp does not exchange frequencies. ntp exchanges time stamps. How do you
    > generate your time stamps? What is that "reference frequency"?
    >

    The frequency says it all.
    The OP wants to have multiple hosts synced for audio sampling.

    uwe


  7. Re: NTP phase lock loop inputs and outputs?

    In article <595deedc-4895-4502-ab12-547f149c4465@n1g2000prb.googlegroups.com>,
    "skillzero@gmail.com" writes:
    >I'm doing NTP exchanges to determine my clock offset. I use this to
    >adjust my clock frequency, but there's a lot of lag so I overshoot by
    >too much and it oscillates around the reference frequency. This is an
    >audio clock so I have to do my own NTP stuff. ...


    Are you interested in time as well as frequency, or just frequency?

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  8. Re: NTP phase lock loop inputs and outputs?

    > What do you mean "a lot of lag"?

    Just that changes I make to correct for frequency offset take a while
    to fully take effect. If I detect that my current frequency is off by
    5 Hz, I reduce my frequency by 5 Hz, but in 2 seconds when I do my
    next NTP packet exchange, I see that I'm now off by say 4 Hz. If I
    were to stop here, I might find that my current frequency is perfect,
    but because it's still off by 4 Hz at this moment, I'll try to reduce
    by another 4 Hz and so on. When it gets to 0 Hz, I'll stop correcting,
    but by then I've adjusted way too far and it's off in the other
    direction so I'll start increasing my frequency. I end up seeing
    something like this in terms of clock offsets: -5, -4, -2, 0, +2 +4,
    +5, +4, +1, 0, -2, -4, etc.

    I think my problem is that I'm always looking at the absolute
    frequency offset and making a correction based on that without
    considering the trend of the offset. From the previous example, at the
    second sample, the absolute offset is still -4, but since it was -5
    before that, it is trending toward 0 now, but my algorithm doesn't
    recognize that.

    It seems like the NTP PLL is designed to solve this kind of problem.
    I'm having trouble figuring how how to convert the data I have into
    something I can plug into it.

    > Why don't you just use the reference implimentation.
    > Why do you have to do your own ntp stuff?


    The NTP reference implementation is a huge amount of code that
    wouldn't even fit in the very small systems I'm working with. I'm also
    trying to sync an audio frequency rather than the time-of-day that NTP
    normally deals with. I'm not looking to just drop in some code. I want
    to understand it.

    > What is your clock? A CD spinning? Those frequencies are nowhere near PPM accuracy.


    The clocks driving the frequency have reasonable precision (50 PPM or
    so), but the accuracy may be initially off by up to 1000 PPM. I think
    ntpd would just step the clock initially then start using its PLL, but
    I can't step my "clock", I can only adjust the frequency that drives
    it (I wouldn't want to step it anyway because you'd be able to hear
    that).

    Rather than stepping when the offset is initially large, I want to
    aggressively adjust (up to 500 PPM) the frequency when the offset is
    large, but then factor in previous changes and their results so it
    realizes that even if the absolute frequency offset *at this moment*
    is off, it is trending toward sync and it should slow down or stop its
    adjustments so it doesn't overshoot the mark.

  9. Re: NTP phase lock loop inputs and outputs?

    A simple algorithm I have used in the pastis

    to measure phase offset.

    in short intervals starting with an interval in
    which under worst case errors phase changes
    of less than 180 deg can happen.

    correct the frequency error for that.
    lengthen the interval, rinse and repeat.
    until your phase offset is constant.

    measure phase error from there.

    then compute a frequency offset you need
    to apply to have the phase change over this
    error in a given timeframe
    or
    compute a time you have to shift frequency by
    a given amount.

    after the time has elapsed switch back to your
    previously measured offset.

    You should now have about zero frequency and phase error.
    you will now have to fix the small errors in f and p
    continuously.

    I have used this ages ago (~1989) for a positioning system
    that had to lock on the Stereo Pilot Tone or the RDS carrier of
    multiple FM Broadcast transmitter ( that ran in lockstep).

    uwe

  10. Re: NTP phase lock loop inputs and outputs?

    > Are you interested in time as well as frequency, or just frequency?

    Just frequency. This frequency controls a counter. I use a more
    traditional NTP-sync'd time (which is accurate to a few PPM) to map
    that counter value to an absolute time (e.g at counter X, the NTP time
    is Y). Then I do NTP packet exchanges using that mapped time to
    estimate my frequency offset. I then increase/reduce the counter
    frequency to try to sync with the frequency on the other side.

    That frequency adjustment is what I'd like to improve to minimize
    overshooting the true frequency.

  11. Re: NTP phase lock loop inputs and outputs?

    Uwe Klein writes:

    >Unruh wrote:


    >> I think maybe you need to be clearer in what it is that you are trying to
    >> do.
    >> ntp does not exchange frequencies. ntp exchanges time stamps. How do you
    >> generate your time stamps? What is that "reference frequency"?
    >>

    >The frequency says it all.
    >The OP wants to have multiple hosts synced for audio sampling.


    I thought that sound was driven by a crystal on the soundcard, not by the
    cpu timer.
    And again, ntp exchanges time stamps, not frequencies.



    >uwe



  12. Re: NTP phase lock loop inputs and outputs?

    Unruh wrote:
    > Uwe Klein writes:
    >
    >
    >>Unruh wrote:

    >
    >
    >>>I think maybe you need to be clearer in what it is that you are trying to
    >>>do.
    >>>ntp does not exchange frequencies. ntp exchanges time stamps. How do you
    >>>generate your time stamps? What is that "reference frequency"?
    >>>

    >>
    >>The frequency says it all.
    >>The OP wants to have multiple hosts synced for audio sampling.

    >
    >
    > I thought that sound was driven by a crystal on the soundcard, not by the
    > cpu timer.
    > And again, ntp exchanges time stamps, not frequencies.

    change horses?

    uwe

  13. Re: NTP phase lock loop inputs and outputs?

    "skillzero@gmail.com" writes:

    >> What do you mean "a lot of lag"?


    >Just that changes I make to correct for frequency offset take a while
    >to fully take effect. If I detect that my current frequency is off by
    >5 Hz, I reduce my frequency by 5 Hz, but in 2 seconds when I do my
    >next NTP packet exchange, I see that I'm now off by say 4 Hz. If I
    >were to stop here, I might find that my current frequency is perfect,
    >but because it's still off by 4 Hz at this moment, I'll try to reduce
    >by another 4 Hz and so on. When it gets to 0 Hz, I'll stop correcting,
    >but by then I've adjusted way too far and it's off in the other
    >direction so I'll start increasing my frequency. I end up seeing
    >something like this in terms of clock offsets: -5, -4, -2, 0, +2 +4,
    >+5, +4, +1, 0, -2, -4, etc.


    >I think my problem is that I'm always looking at the absolute
    >frequency offset and making a correction based on that without
    >considering the trend of the offset. From the previous example, at the
    >second sample, the absolute offset is still -4, but since it was -5
    >before that, it is trending toward 0 now, but my algorithm doesn't
    >recognize that.


    Again, I am afraid this is making no sense. How do you compare your
    frequencies? What do you do when you have made the comparison? What do you
    change to change teh frequency.


    >It seems like the NTP PLL is designed to solve this kind of problem.
    >I'm having trouble figuring how how to convert the data I have into
    >something I can plug into it.


    >> Why don't you just use the reference implimentation.
    >> Why do you have to do your own ntp stuff?


    >The NTP reference implementation is a huge amount of code that
    >wouldn't even fit in the very small systems I'm working with. I'm also
    >trying to sync an audio frequency rather than the time-of-day that NTP
    >normally deals with. I'm not looking to just drop in some code. I want
    >to understand it.


    >> What is your clock? A CD spinning? Those frequencies are nowhere near PPM accuracy.


    >The clocks driving the frequency have reasonable precision (50 PPM or
    >so), but the accuracy may be initially off by up to 1000 PPM. I think
    >ntpd would just step the clock initially then start using its PLL, but
    >I can't step my "clock", I can only adjust the frequency that drives
    >it (I wouldn't want to step it anyway because you'd be able to hear
    >that).


    >Rather than stepping when the offset is initially large, I want to
    >aggressively adjust (up to 500 PPM) the frequency when the offset is
    >large, but then factor in previous changes and their results so it
    >realizes that even if the absolute frequency offset *at this moment*
    >is off, it is trending toward sync and it should slow down or stop its
    >adjustments so it doesn't overshoot the mark.


  14. Re: NTP phase lock loop inputs and outputs?

    > Again, I am afraid this is making no sense. How do you compare your
    > frequencies? What do you do when you have made the comparison? What do you
    > change to change teh frequency.


    When I do an NTP exchange of timestamps, I take the resulting
    timestamp offset and convert it to the timescale of my audio clock
    (i.e. if at audio time X, NTP time is Y then at NTP time A, I can
    calculate audio time is B). I compare my audio time with the peer's
    audio time to come up with an audio clock offset. So if via NTP
    exchanges, I calculate an audio clock offset of 5 units, that maps to
    the frequency being off by 5 Hz. So if my clock is set to 44100 Hz and
    it's off by +5, I change my clock to 44105 Hz. I change the frequency
    by setting a hardware register to the value 44105 (in this case).

    The problem is that this change won't be reflected immediately. Even
    if I 44105 Hz is exactly in sync with the peer, when I do another NTP
    exchange in 2 seconds, it won't have enough time to compensate for the
    existing offset so I may still calculate an offset of say 4 Hz then 3
    Hz in another 2 seconds, etc. By the time I get to 0, I may have set
    my frequency to 44115 Hz and now it's too fast so it'll start getting
    negative offsets. And it cycles back and forth like that because I'm
    not taking into consideration the relative change.

    Figuring out a good way to incorporate the relative change to
    discipline the clocks is what I'm hoping the NTP algorithms can do.

  15. Re: NTP phase lock loop inputs and outputs?

    skillzero@gmail.com wrote:

    >
    > The problem is that this change won't be reflected immediately. Even
    > if I 44105 Hz is exactly in sync with the peer, when I do another NTP
    > exchange in 2 seconds, it won't have enough time to compensate for the
    > existing offset so I may still calculate an offset of say 4 Hz then 3
    > Hz in another 2 seconds, etc. By the time I get to 0, I may have set
    > my frequency to 44115 Hz and now it's too fast so it'll start getting
    > negative offsets. And it cycles back and forth like that because I'm
    > not taking into consideration the relative change.


    You have to damp the loop, the same as you have to damp the suspension
    in a car. The general form of a commodity industrial controller
    involves adding proportional, differential and integral terms, hence
    they are called PIDs.

    You stop the overshoot by adding a term based on rate at which you are
    changing the value. There is particular level of correction that
    produces the fastest convergence without any over shoot. Although I
    forget it, the actual formula is high school level mechanics.

    You don't need an integral term, because you are not trying to zero the
    phase error.

  16. Re: NTP phase lock loop inputs and outputs?

    > You have to damp the loop, the same as you have to damp the suspension
    > in a car. *The general form of a commodity industrial controller
    > involves adding proportional, differential and integral terms, hence
    > they are called PIDs.
    >
    > You stop the overshoot by adding a term based on rate at which you are
    > changing the value. *There is particular level of correction that
    > produces the fastest convergence without any over shoot. *Although I
    > forget it, the actual formula is high school level mechanics.
    >
    > You don't need an integral term, because you are not trying to zero the
    > phase error.


    I've thought about my own schemes for doing this kind of thing, but I
    was hoping to benefit from the experience of NTP to find a proven
    scheme rather than just something I hack up. Everything I read is so
    heavy on the jargon of control theory and electrical circuits that
    it's difficult for me to have confidence in the way I turn it into
    code. My ad hoc schemes sorta work, but I want a more solid
    understanding of feedback systems rather than the more statistical
    approach I've been taking.

    I'll check out PIDs. Thanks.

  17. Re: NTP phase lock loop inputs and outputs?

    "skillzero@gmail.com" writes:

    >> Again, I am afraid this is making no sense. How do you compare your
    >> frequencies? What do you do when you have made the comparison? What do you
    >> change to change teh frequency.


    >When I do an NTP exchange of timestamps, I take the resulting
    >timestamp offset and convert it to the timescale of my audio clock
    >(i.e. if at audio time X, NTP time is Y then at NTP time A, I can
    >calculate audio time is B). I compare my audio time with the peer's
    >audio time to come up with an audio clock offset. So if via NTP
    >exchanges, I calculate an audio clock offset of 5 units, that maps to
    >the frequency being off by 5 Hz. So if my clock is set to 44100 Hz and
    >it's off by +5, I change my clock to 44105 Hz. I change the frequency
    >by setting a hardware register to the value 44105 (in this case).


    I do not understand this. You seem to be measuring the offsets, not the
    frequencies. The offset is irrelevant. What you want to do is to measure
    the offset twice, and ask if the difference is constant or not. Ie, th
    eoffset does not correspond to being off by 5Hz.


    >The problem is that this change won't be reflected immediately. Even


    Sure it is.

    >if I 44105 Hz is exactly in sync with the peer, when I do another NTP
    >exchange in 2 seconds, it won't have enough time to compensate for the
    >existing offset so I may still calculate an offset of say 4 Hz then 3


    But you do not care about the offset. You just want the frequencies to be
    equal.


    >Hz in another 2 seconds, etc. By the time I get to 0, I may have set
    >my frequency to 44115 Hz and now it's too fast so it'll start getting
    >negative offsets. And it cycles back and forth like that because I'm
    >not taking into consideration the relative change.


    So, take in account relative change.


    >Figuring out a good way to incorporate the relative change to
    >discipline the clocks is what I'm hoping the NTP algorithms can do.


    ntp is designed to get rid of both the offset and the frequency
    differences. You just want to get rid of freq differences.


  18. Re: NTP phase lock loop inputs and outputs?

    Unruh wrote:

    > I do not understand this. You seem to be measuring the offsets, not the
    > frequencies. The offset is irrelevant. What you want to do is to measure


    Measuring phase error to control frequency is pretty much THE standard
    way of doing it in modern electronics. It's called a phase locked loop
    (PLL) and it is getting difficult to find any piece of electrnics that
    doesn't include one these days. E.g. the typical digitally tuned radio
    or TV has a crystal oscillator, which is divided down to the channel
    spacing or a sub-multiple, and a configurable divider on the local
    oscillator divides that down to the same frequency. The resulting two
    signals are then phase locked, by measuring the phase error on each
    cycle, low pass filtering it, and using it to control the local
    oscillator frequency, resulting in their matching in frequency, and
    having some constant phase error.

    > the offset twice, and ask if the difference is constant or not. Ie, th
    > eoffset does not correspond to being off by 5Hz.


    ntpd only uses this method on a cold start, to get the initial coarse
    calibration. Typical electronic implementations don't use it at all,
    but either do a frequency sweep or simply open up the low pass filter,
    to get initial lock.

  19. Re: NTP phase lock loop inputs and outputs?

    > The general form of a commodity industrial controller
    > involves adding proportional, differential and integral terms, hence
    > they are called PIDs.


    I implemented a PID in software and after a little experimenting with
    the gain parameters, I'm able to get and maintain sync. There is a
    little oscillation, but it's within about 20 PPM, which is within the
    noise of my system. Thanks for pointing me the right direction.

  20. Re: NTP phase lock loop inputs and outputs?

    David Woolley writes:

    >Unruh wrote:


    >> I do not understand this. You seem to be measuring the offsets, not the
    >> frequencies. The offset is irrelevant. What you want to do is to measure


    >Measuring phase error to control frequency is pretty much THE standard
    >way of doing it in modern electronics. It's called a phase locked loop


    Sure. In the case of ntp you want to have zero phase error. ntp reduces the
    phase error slowly by changing the frequency. This has the advantage that
    the frequency error also gets reduced (slowly). He wants to reduce the
    frequency error only. He does not give a damn about the phase error
    apparently. Thus you do NOT want to reduce the frequecy error by attacking
    the phase error. That is a slow way of doing it. You want to estimate the
    frequency error directly. Now in his case he is doing so by measuring the
    phase, so you need at least two phase measurements to estimate the
    frequency error. But you do NOT want to reduce the frequency error by
    reducing the phase error-- far too slow.

    One way of reducing the frequency error is to use the ntp procedure but
    applied to the frequency. But you must feed in an estimate of the frequecy
    error. Anothr way is the chrony technique. -- collect phase points, do a
    least squares fit to find the frequency, and then use that information to
    drive the frequecy to zero. To reuse past data, also correct the prior
    phase measurements by the change in frequency.
    (t_{i-j}-=(t_{i}-t_{i-j}) df

    >(PLL) and it is getting difficult to find any piece of electrnics that
    >doesn't include one these days. E.g. the typical digitally tuned radio


    A PLL is a dirt simply thing to impliment electronically. A few resistors
    and capacitors. It however is a very simply Markovian process. There is far
    more information in the data than that, and digititally it is easy to
    impliment far more complex feedback loops than that.


    >or TV has a crystal oscillator, which is divided down to the channel
    >spacing or a sub-multiple, and a configurable divider on the local
    >oscillator divides that down to the same frequency. The resulting two
    >signals are then phase locked, by measuring the phase error on each
    >cycle, low pass filtering it, and using it to control the local
    >oscillator frequency, resulting in their matching in frequency, and
    >having some constant phase error.


    >> the offset twice, and ask if the difference is constant or not. Ie, th
    >> eoffset does not correspond to being off by 5Hz.


    >ntpd only uses this method on a cold start, to get the initial coarse
    >calibration. Typical electronic implementations don't use it at all,
    >but either do a frequency sweep or simply open up the low pass filter,
    >to get initial lock.


    And? You are claiming that that is efficient or easy? I would claim the
    latter. And his requirements are NOT ntp's requirements. He does not care
    about the phase errors. He is onlyconcerned about the frequency errors.
    driving the frequency errors to zero by driving the phase errors to zero is
    not a very efficient technique-- unless of course you want the phase errors
    to be zero( as ntp does, and he does not).





+ Reply to Thread
Page 1 of 2 1 2 LastLast