Re: [time-nuts] Subject: Re: GPS 1PPS, phase lock vs frequency lock, design
Hi In a GPSDO, an FLL can be done with no “cycle slips” between readings. In that case, the I term will indeed correct for long term errors. The net result will be effectively the same as a PLL for long term error. That is by no means to say that *all* FLL’s are done this way. Only that it is one possible implementation. Bob > On Jun 24, 2019, at 9:16 PM, Glen English VK1XX > wrote: > > Leo is right > > Depends on the application. Phase lock for 1pps to trigger say, simultaneous > capture of many radio telescopes around the globe is a good need for phase > lock to a source. Frequency lock might suit many . change of phase between > two sources might indicate frequency change, or duty cycle change. > > For all my digital PLL and digital FLL implementations, the method of > capturing the data is identical... just the transfer function of the filter > is different. So they are nearly indistinguishable. > > A choice might depend on the control loop bandwidth, and whether the initial > error (acquisition) is beyond the BW. In those cases depending on the type of > comparison, it might make sense to measure the frequency error, and then > move the (controlled) source within phase lock without cycle slip range in > one step. Useful for very long time constants and large initial errors. > > ...and then what do you do when including relativistic effects ... > > glen. > > > On 25/06/2019 3:42 AM, Leo Bodnar wrote: >> Hi Dana, >> >> I am just saying that, properly implemented, PLL and FLL are >> indistinguishable as long as output signal is concerned while lock is >> present and that the phase slew at regaining lock in PLL loop is >> counterproductive for one but necessary evil for others. I have a feeling >> that FLL is looked down upon by general public ever since PLL became a >> household term. >> >> In a well designed PID loop "I" term makes sure that you don't have >> "permanent but varying error." >> >> All my messing about with loops, holdovers and recovery was pretty much with >> your application in mind. >> >> Cheers! >> Leo >> >>> Are you saying that you want to abandon phase lock altogether in favor of >>> freq >>> lock? Or just during the reacquisition following loss of and restoration >>> of the >>> reference? >>> >>> By me definition of pure freq lock, there will generally be some permanent >>> (but varying) >>> frequency error, so that phase error could accumulate without limit; >>> clearly an undesirable >>> thing in most applications. >>> >>> My interest lies in having a stable LO for receiving, without accumulating >>> phase error (at least during times of missing reference). When the >>> reference goes away, I'll >>> accept some phase error accumulation. So for me, I think the best approach >>> is phase lock >>> under normal circumstances, but switch to freq lock during reacquisition of >>> phase lock. >>> >>> DanaK8YUM >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. >> > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Subject: Re: GPS 1PPS, phase lock vs frequency lock, design
Leo is right Depends on the application. Phase lock for 1pps to trigger say, simultaneous capture of many radio telescopes around the globe is a good need for phase lock to a source. Frequency lock might suit many . change of phase between two sources might indicate frequency change, or duty cycle change. For all my digital PLL and digital FLL implementations, the method of capturing the data is identical... just the transfer function of the filter is different. So they are nearly indistinguishable. A choice might depend on the control loop bandwidth, and whether the initial error (acquisition) is beyond the BW. In those cases depending on the type of comparison, it might make sense to measure the frequency error, and then move the (controlled) source within phase lock without cycle slip range in one step. Useful for very long time constants and large initial errors. ...and then what do you do when including relativistic effects ... glen. On 25/06/2019 3:42 AM, Leo Bodnar wrote: Hi Dana, I am just saying that, properly implemented, PLL and FLL are indistinguishable as long as output signal is concerned while lock is present and that the phase slew at regaining lock in PLL loop is counterproductive for one but necessary evil for others. I have a feeling that FLL is looked down upon by general public ever since PLL became a household term. In a well designed PID loop "I" term makes sure that you don't have "permanent but varying error." All my messing about with loops, holdovers and recovery was pretty much with your application in mind. Cheers! Leo Are you saying that you want to abandon phase lock altogether in favor of freq lock? Or just during the reacquisition following loss of and restoration of the reference? By me definition of pure freq lock, there will generally be some permanent (but varying) frequency error, so that phase error could accumulate without limit; clearly an undesirable thing in most applications. My interest lies in having a stable LO for receiving, without accumulating phase error (at least during times of missing reference). When the reference goes away, I'll accept some phase error accumulation. So for me, I think the best approach is phase lock under normal circumstances, but switch to freq lock during reacquisition of phase lock. DanaK8YUM ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Cloudflare
Tim Shoppa writes: > I have been observing time.cloudflare.com latency and accuracy the past 3 > days. >From my home network it is actually pretty bad compared to some other servers. It's likely the network and not the server, though. > It is a stratum 3 server, so folks might think that it's not as good as a > Stratum 1 or Stratum 2. > > BUT... it has exceptionally low latency and it seems very likely it's > Stratum 3 because it is fed by a well-maintained set of highly redundant > sources. The NTP stratum hierarchy is not a bad idea but really no end-user > has any actual need to hook up to a real Stratum 1 and would almost always > be better suited to choose a lower stratum server fed with a highly curated > list of good Stratum 1/2's. The thing is that you can't really know that, since getting permission to use a particular NTP server by writing an email or even a snail mail has been falling out of favor. And even if you do know there's an awful lot of stuff going on with the routing these days that neither you nor the other end has any control over. > It seems possible given cloudflare's diverse geographic servers, that folks > will get directed to a nearby low-latency server every time they resolve > the name. That's the idea, yes. I actually get a pretty short route (in number of network hops), but latency should be about half what I'm getting considering the geographical distance. It's one particular intermediate link that adds most of that latency. Also there is extra asymmetry on top of what my VDSL line produces normally. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Cloudflare
I have been observing time.cloudflare.com latency and accuracy the past 3
days.
It is a stratum 3 server, so folks might think that it's not as good as a
Stratum 1 or Stratum 2.
BUT... it has exceptionally low latency and it seems very likely it's
Stratum 3 because it is fed by a well-maintained set of highly redundant
sources. The NTP stratum hierarchy is not a bad idea but really no end-user
has any actual need to hook up to a real Stratum 1 and would almost always
be better suited to choose a lower stratum server fed with a highly curated
list of good Stratum 1/2's.
It seems possible given cloudflare's diverse geographic servers, that folks
will get directed to a nearby low-latency server every time they resolve
the name.
Tim N3QE
On Fri, Jun 21, 2019 at 4:03 PM Marco Davids via time-nuts <
time-nuts@lists.febo.com> wrote:
> Opinions, anyone?
>
> https://blog.cloudflare.com/secure-time/amp/
>
> ("Introducing time.cloudflare.com")
>
> --
> Marco
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Re: [time-nuts] Subject: Re: GPS 1PPS, phase lock vs frequency lock, design
Hi Dana, I am just saying that, properly implemented, PLL and FLL are indistinguishable as long as output signal is concerned while lock is present and that the phase slew at regaining lock in PLL loop is counterproductive for one but necessary evil for others. I have a feeling that FLL is looked down upon by general public ever since PLL became a household term. In a well designed PID loop "I" term makes sure that you don't have "permanent but varying error." All my messing about with loops, holdovers and recovery was pretty much with your application in mind. Cheers! Leo > Are you saying that you want to abandon phase lock altogether in favor of freq > lock? Or just during the reacquisition following loss of and restoration of > the > reference? > > By me definition of pure freq lock, there will generally be some permanent > (but varying) > frequency error, so that phase error could accumulate without limit; > clearly an undesirable > thing in most applications. > > My interest lies in having a stable LO for receiving, without accumulating > phase error (at least during times of missing reference). When the reference > goes away, I'll > accept some phase error accumulation. So for me, I think the best approach > is phase lock > under normal circumstances, but switch to freq lock during reacquisition of > phase lock. > > DanaK8YUM ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] New timekeeping book (Time in Tokugawa Japan)
On 6/24/19 9:39 AM, Mark Kahrs wrote: http://weai.columbia.edu/weai-author-qa-yulia-frumers-making-time/ ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. "Think of it: what we call “noon” today rarely coincides with the astronomical solar noon (when the sun is at its zenith). Not only do most of us not live precisely in the right place on the time zone, but also only four days a year do solar days last exactly 24 hours. Most of the people do not really care about these inconsistencies because they do not really matter for our functioning." "Most of the people" is not time-nuts.. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] DSAC launches tonight
https://www.jpl.nasa.gov/news/news.php?feature=7430 and, as well, COSMIC-2 is being deployed - 6 satellites each carrying a fancy GPS receiver that does two things: Precision Orbit Determination (POD) using a choke ring antenna; Occultation measurements of the atmosphere using a directive array of helical antennas facing the limb. https://twitter.com/AF_SMC/status/1141099481628364808 has a nice view of the COSMIC-2 satellites - they're in the middle and you can see the 12 element array. Yes, I suspect that the dimensions of the form for the helix are very close to that of a standard small Solo drink cup, but these are a fancy 3D printed material that can stand up to radiation and atomic oxygen. These spacecraft fly with the array antennas pointed at the limb ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] New timekeeping book (Time in Tokugawa Japan)
http://weai.columbia.edu/weai-author-qa-yulia-frumers-making-time/ ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Subject: Re: GPS 1PPS, phase lock vs frequency lock, design
Hi Welll … ummm ….. e …. With things like time re-synch going on, the only thing you should drive a clock with is the PPS output. You can go on pretty much forever and ever with a FLL and still have a good PPS out. Bob > On Jun 23, 2019, at 10:44 PM, Hal Murray wrote: > > > t...@leapsecond.com said: >> Can you explain more what you use a GPSDO for? For most people a GPSDO is >> merely a replacement for a stand-alone XO or TCXO or OCXO or even rubidium. >> As such, the more stable and accurate the frequency the better. Which is why >> a FLL-based GPSDO, as Leo describes, is a perfectly fine solution. > > The obvious case where a PLL wins is using it to drive a clock. > > Consider using it to drive a picPET watching the PPS from a GPS. > > > -- > These are my opinions. I hate spam. > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Logging and correlating NMEA messages with TICC timestamp
Just a note about possible spurious pulses with the TICC. The input circuit is a 3.3v logic gate that's 5v-safe. Some PPS signals have much greater peak amplitude than that (e.g., the HP atomic clocks). Experience has shown that these pulses don't know have enough energy to damage the input, but the voltage can cause ringing that results in occasional double pulses. So use a scope to look at the pulse and if its peak is more than about 5v, use an attenuator to knock it down. Also, make sure the pulse is terminated in a 50 ohm load at the TICC input. John On Jun 24, 2019, 2:00 AM, at 2:00 AM, "Forrest Christian (List Account)" wrote: >I have a couple of GPS receivers I'm experimenting with that I've been >using a TICC to gather timestamps of the 1PPS output to ascertain >their relative quality. > >In the process of doing this, I've discovered that some of the 1PPS >outputs are not as stable as I'd like them to be. For instance, the >one currently on my bench emits stuff like this every once in a while: > >330364.902989667231 chA >330365.582893064933 chA >330365.584094826326 chA >330365.902989679840 chA > >Note the 2 inserted pulses between the two correct ones. > >I'd like to be able to look at a log of the GPS NMEA output at the >appropriate time for this and other events to determine if they >correspond to some sort of GPS event.In addition, I'd like to >gather the phase correction data (aka quantization error) from the GPS >(and which is spit out in a NMEA sentence as well) in a way that is >correlated to the TICC timestamp it goes with. > >I know I can hack together something in python or similar to open both >ports and log them together using a common timestamp. But this also >seems like something which is probably being done regularly in time >labs around the globe so there's likely some tool to do this that I'm >unaware of. > >So I guess I'm asking what everyone else is using to gather both >timestamp data and NMEA data in a correlated way > >Thanks for any input. > >-- >- Forrest > >___ >time-nuts mailing list -- time-nuts@lists.febo.com >To unsubscribe, go to >http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Logging and correlating NMEA messages with TICC timestamp
li...@packetflux.com said: > So I guess I'm asking what everyone else is using to gather both timestamp > data and NMEA data in a correlated way I have a hack that grabs everything and writes each line and a time stamp to a file per day. http://users.megapathdsl.net/~hmurray/time-nuts/Arctic/code/AAA-README http://users.megapathdsl.net/~hmurray/time-nuts/Arctic/code/grab-nmea.py I'd use two copies of it - one for the TICC and another for the NMEA. You can merge them on post processing. The time stamp is the end of line. If you know the baud rate and number of stop bits, you can calculate the start time. Again, post processing. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] announcing NTPsec 1.1.4, with NTS
The NTPsec Project is pleased to announce the tagging of version 1.1.4 As always, you can clone the git repo from https://gitlab.com/NTPsec/ntpsec.git and you can download the release tarballs with sums and signatures from ftp://ftp.ntpsec.org/pub/releases/ This release is signed with the GPG key id 0x5A22E330161C3978. The release was done on the day of summer solstice in the Northern Hemisphere. See https://blog.ntpsec.org/2019/06/21/version-1.1.4.html NTS is now implemented. See …/devel/nts.adoc in the repo. We thank Cisco for sponsoring the NTS development. Lots of fixes and cleanups to PPS, both implementation and documentation. As always, lots of minor fixups and cleanups everywhere. See the git log. ..m Mark Atwood Project Manager of the NTPsec Project +1-206-604-2198 = Where is the Windows version, please, and does it support the PPS and loopback PPS drivers? Thanks, David -- SatSignal Software - Quality software for you Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
