Azelio wrote:

No, not at all.  I was suggesting that the XOR PLL you were
commenting on had problems.

First, an XOR with or without an RC is not an FLL at all, of any
sort.  Second, the XOR gate is a time-honored phase detector for
PLLs, and if its limitations are understood and accounted for, it
makes a perfectly serviceable PD for a PLL.  There are other phase
detectors that are more popular these days, for a variety of reasons,
but the XOR works just fine in a proper design.

See, e.g.:
Best, Phase-Locked Loops (2007), pp. 16-18
Gardner, Phaselock Techniques (3rd ed) (2005), pp. 245-46
Wolaver, Phase-Locked Loop Circuit Design (1991) pp. 55-59
https://en.wikipedia.org/wiki/Phase_detector
https://jaunty-electronics.com/blog/2012/09/exclusive-or-xor-gate-based-phase-detector/
http://memo.cgu.edu.tw/jtkuo/files/eelab%202014(iii)/1230_lab12_expxx_phaselockedloop.pdf
and many, many, many others.

Best regards,

Charles

If FLL: something that links frequencies,
PLL: something that links phases,
frequency detector: output proportional to frequency error,
phase detector: output proportional to phase error (XOR),
and the original question (about FLL) was how to implement a simple FLL,
can an FLL be made by a phase detector? Can a PLL be made by a
frequency detector?
Phase_detector_XOR + RC + VCO-> FLL: equal frequencies, phase linked
to VCO odds,
in this case the frequency error is 0.

On Fri, Aug 28, 2015 at 7:14 PM, Charles Steinmetz
csteinmetz@yandex.com wrote:

Hi again,

A frequency detector uses a phase-memory one way or another.
Digital FLL detectors recall the sequence of events, see 4046
Phase-Frequency Detector.

Using a phase detector, just differentiate the phase data to get a
frequency difference estimate, however phase-wrapping usually upset the
result. In digital processing avoiding the wrapping upsetting the result
is relatively trivial.

The combined form of phase and frequency detector can take the form of a
+/- 180 degree phase detector range, but as the phase tries to wrap
over, you "lock" to the upper or lower limit to force the integrator to
integrate the frequency compensation in the right direction and
eventually be close enough to hand over to the phase-detector part. This
is for instance what the 4046 detector does, but it has been used elsewhere.

The 4046 has a charge-pump. Hailed by many. Frankly, it's a bad solution
in my mind. The dead-band can be a killer, as I've seen first hand.
There is the 7046 and 9046 naturally.

Doing a phase-detector PI look, a quick FLL type of lock can be achieved
by letting the damping be very high, that is a very high P factor. This
is the AC-path, letting the side-band modulation be high (too high is
however counter-acting) through the Bessel polynomials.

There is so many ways to do this.

In the end, I only consider FLL in context of locking up my PLL fast,
unless I lock to an atomic standard.

Cheers,
Magnus

On 08/29/2015 12:37 AM, Azelio Boriani wrote:

Hi

There are many ways to implement just about anything. There are lots of features
that can be added into any design. Multi-lock loops are something that goes back at
least into the 1940’s.

No it can not with a real phase detector. The advantage of an FLL is that it can tolerate
a frequency error and still be locked. That’s it’s advantage. If you have a phase detector,
it will run into a limit and crash with a frequency error. If you have a system that needs
tolerate a long term frequency offset, that’s one of many reasons to use an FLL.

Again, not with a real world part. Any real detector will have a zero error. That error
will be fatal if you are trying to do phase with a frequency detector.

Bob

Hi

Interesting question ….

At the most basic level, no. Phase is already commonly looked at in units
of time. Yes that’s a bit odd at first. ADEV (for example) is a phase based
measure that uses units of time.

Which creates all sorts of issues in the loop. GPS time rather than UTC (with leap seconds )
is used in every GPSDO system I’ve seen for this reason.

Because you always get into application specific details, sure. As a more
general concept:

Time locked loop -> has a static time error in a gain only loop.

In your example of leap seconds, that’s going to require something a bit different
than a classic PLL. In the non-leap second case (GPS time) it’s effectively what
is done in a GPSDO. There it is commonly referred to as phase lock. Since some
of the details there are a bit weird, maybe a new term is called for.

Bob

Hi,

On 08/29/2015 11:24 AM, Neville Michie wrote:

Yes and now. In a signal conveying time, rather than letting a rising
edge denote "0 degrees of phase" you have some even time measure
occuring, of some known nominal rate. You know what "time" it was on the
time-scale, so that you know how much your local replica time-scale is
off when compared. This time difference does go beyond the nearest
cycle, but typically for locked situations is the nearest cycle.

Don't ask how I know, I just know.

No, as GPS time in itself does not have leap-seconds, it's nominally the
TAI time-scale offset. GPS signal conveys the difference between GPS
time and UTC, and thuse the UTC can be conveyed.

Yes, whenever the enumeration of cycles to some time-scale is relevant.

Cheers,
Magnus

Ah, Magnus, source of so much solid and useful information, I don't see
a time loop as valid.

Frequency, yes, social time, no.

A clock (purveyor of time) consists of an oscillator and a counter. In
olden times the oscillator was a pendulum and the counter was a set of
gears driven by the tick-tock of the escapement. Today we have
electronic local oscillators providing one pulse per second (or whatever
is needed) to electronic counters and displays. As an old timer, I
prefer neon Nixie tubes.

The problem we struggle to solve is to relate our local oscillator to
some widely recognized standard frequency, preferably derived from an
inordinately expensive generator based on the bouncing of atoms under
controlled conditions. The very best way to transfer the standard (not
"At the tone, the time is ...") is to use an electronic phase
comparator, error amplifier, and filter time constant that will cause
the local oscillator to track the standard frequency usually
propagated by GPS.

The remaining problem is to get the counter to agree with our preferred
version of time display (UTC, TAI, etc.). If the display electronics
permit adjustments such as adding a second at a predetermined time, or
adjusting by an hour for summer or winter time, then our needs for
social time can be satisfied.

I don't see the need to yank the oscillator around for social time with
a "time loop."

Best regards,
Bill Hawkins

P.S. We're moving to a life care community that has no room for a time
lab. The Junk Genius truck arrives at 10300 Colorado Road, Bloomington,
MN 55438, at 11 AM on 1 September. If you can get here before that you
can have anything you see. There are only antiques, except possibly the
HP 3335A synthesizers and Racal Dana 1882 counters. I've tried to sell a
few times but have had no takers. I won't ship (no time) but you can
hire someone to pick it up.

-----Original Message-----
From: time-nuts [mailto:time-nuts-bounces@febo.com] On Behalf Of Magnus
Danielson
Sent: Saturday, August 29, 2015 9:47 PM
To: Discussion of precise time and frequency measurement
Cc: magnus@rubidium.se
Subject: Re: [time-nuts] FLL errors

Hi,

On 08/29/2015 11:24 AM, Neville Michie wrote:

Yes and now. In a signal conveying time, rather than letting a rising
edge denote "0 degrees of phase" you have some even time measure
occuring, of some known nominal rate. You know what "time" it was on the
time-scale, so that you know how much your local replica time-scale is
off when compared. This time difference does go beyond the nearest
cycle, but typically for locked situations is the nearest cycle.

Don't ask how I know, I just know.

No, as GPS time in itself does not have leap-seconds, it's nominally the
TAI time-scale offset. GPS signal conveys the difference between GPS
time and UTC, and thuse the UTC can be conveyed.

Yes, whenever the enumeration of cycles to some time-scale is relevant.

Cheers,
Magnus

time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Bill,

On 08/30/2015 07:45 AM, Bill Hawkins wrote:

You say social time, but I didn't, you extrapolated my words.
The main point of a Time Locked Loop is to use a enumeration beyond the
cycles, so that you lock to the right cycle. This enumeration may be the
code-phase of a GPS for instance. Some call this Delay Locked Loop while
others call it a Time Locked Loop.
You can also have a time-scale such as TAI or GPS time if you like, and
there it makes sense.
It's essentially a PLL, but aware of the enumeration so that the
phase-detector has a much wider range such that false-lock cannot occur.
Making the distinction from a normal PLL makes sense, and that's why
both DLL and TLL is used.

If you don't need it to, then don't do it. It doesn't mean others don't
feel it being an adequate solution. I'm ot forcing anyone to any
solution, I'm only want to show that there is cases where it does make
sense to use one.

Cheers,
Magnus