Re: [time-nuts] New wrist Watch
It won't be state of the art (I think tvb's cesium wrist watch does that.. but it doesn't have the non-digital display you want) One would think wristwatches based on the Symmetricom CSAC would be on the market by now. http://leapsecond.com/images/tvb-csac.jpg /tvb ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantization error
In message 1225454799-1347767280-cardhu_decombobulator_blackberry.rim.net-1901 834519-@b27.c1.bise6.blackberry, li...@lazygranch.com writes: The PWM DAC should have perfect differential linearity, which I believe is all that matters in this application. (That and no missing codes.) Not so when you try to combine two DACs to make one higher resolution DAC. The main problem with two staggered DAC's is actually that all OCXO's drift and eventually you will have to step the major DAC which will give a glitch in the lower bits, almost no matter how much you calibrate beforehand. The PRS10 uses a staggered DAC internally and the steps on the major DAC are measurable in the output signal. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 5C1BBD844F6145969FE8A4785FEE490A@pc52, Tom Van Baak writes: Has anyone on the list done work optimizing the timing accuracy rather than the frequency stability? Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? /tvb ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi If your definition of timing accuracy is within 100 ns of GPS time ten minutes after lock then a faster crossover is a better idea. A faster loop will track GPS better. If your GPS noise is on the order of 10 ns, your time error will be pretty low. An example: 100s loop and 10 ns GPS, = 1x10^-10 noise. If your definition of timing accuracy is best short term stability plot then picking a long crossover is the way to do it. You want the PLL to only kick in once it's going to do no harm to the noise signature. An example: 10,000s loop and 10 ns GPS = 1x10^-12 noise. If your GPS noise is lower / higher, the numbers obviously will change accordingly. If your GPS noise is dimensioned in one set of units and your OCXO noise in another set of units, that's going to require a units conversion (pk-pk != rms != 3 sigma etc). Bob On Sep 16, 2012, at 12:40 AM, Tom Van Baak t...@leapsecond.com wrote: I worry in your example about the long cross-over time. This may be ideal for frequency stability, but probably is not good for time accuracy. If one is using the GPSDO as a timing reference, I would think a shorter time constant will keep the rms time error down. Has anyone on the list done work optimizing the timing accuracy rather than the frequency stability? /tvb - Original Message - From: Bob Camp li...@rtty.us To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Saturday, September 15, 2012 9:46 AM Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror Hi If the objective is to build a GPSDO that *needs* a 32 bit D/A as opposed to a 16 to 20 bit part, there are some things you have to consider. The output of your GPS has jitter on it. How much jitter is a that depends sort of thing, but there's always more jitter than on the output of a good OCXO or Rb. The idea is to get the short term stability of the OCXO or Rb and the long term stability of the GPS. To do that, you are going to set the cross over between the GPS and OCXO at some magic point. Exactly where depends on the actual noise plots of your OCXO and your GPS. With a good DOCXO you can easily have a cross over out in the 1,000 to 5,000 second range. With a Rb the cross over is likely to be in the 100,000 to 200,000 second range. If it's closer in you degrade the short term stability of the OCXO or Rb. If the cross over is at 100,000 seconds, everything that happens quicker than 100,000 seconds is ignored by the PLL. Stuff that happens more slowly than 100,000 seconds is corrected by the PLL. No, it's not exactly a brick wall, but it does fundamentally work that way. What ever happens with the DAC quicker than the cross over, passes straight through to the OCXO or Rb. In the case of a 100,000 second cross over, daily temperature cycling in the lab winds up as short term instability and is not corrected by the PLL. Hourly cycles (think HVAC cycles) very much will show up as short term issues that are not corrected. If indeed 32 bits matters, then instability at the 32 bit level will show up. Indeed temperature is not the only issue, noise on the DAC output is also a concern. Johnson noise is one source, there are others. No free lunch… Bob ___ 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. ___ 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.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
On 9/15/2012 2:11 PM, paul swed wrote: Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? It's more than just the init command. The z3801a also sends @@Ca, @@Cg, @@Ab, @@Ah, @@Aj, @@Ak, @@Al, @@An, @@Ar, @@Av, @@Ax, @@Ay, @@AB, @@AC, @@AD, @@Ba, @@Bc, @@Bk, @@Cg, @@At, and @@Bn, none of which are available on an M12 (which would be the logical target if you're going to the trouble of an adapter), so would need to be converted to other commands, and the correct response returned. In addition, the response to the @@Bb command (Visible sat status) would need modification. ___ 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.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
Anyway, are you sure that the GPS unit is faulty? Can you test it alone? The unit is responsive on the serial port? Is the Z3801A sending commands? Can you verify with a 'scope on the serial line if there is any signal? On Sun, Sep 16, 2012 at 2:54 PM, Mike S mi...@flatsurface.com wrote: On 9/15/2012 2:11 PM, paul swed wrote: Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? It's more than just the init command. The z3801a also sends @@Ca, @@Cg, @@Ab, @@Ah, @@Aj, @@Ak, @@Al, @@An, @@Ar, @@Av, @@Ax, @@Ay, @@AB, @@AC, @@AD, @@Ba, @@Bc, @@Bk, @@Cg, @@At, and @@Bn, none of which are available on an M12 (which would be the logical target if you're going to the trouble of an adapter), so would need to be converted to other commands, and the correct response returned. In addition, the response to the @@Bb command (Visible sat status) would need modification. ___ 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. ___ 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.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
I just bought a second-hand Z3801A, it also had a error message when self test - GPS Rcv error, and I saw a red LED on main board on. I want test it alone but I don't know GPS board's pin define, can someone tell me? Thanks. Hui At 2012-09-16 21:20:26,Azelio Boriani azelio.bori...@screen.it wrote: Anyway, are you sure that the GPS unit is faulty? Can you test it alone? The unit is responsive on the serial port? Is the Z3801A sending commands? Can you verify with a 'scope on the serial line if there is any signal? On Sun, Sep 16, 2012 at 2:54 PM, Mike S mi...@flatsurface.com wrote: On 9/15/2012 2:11 PM, paul swed wrote: Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? It's more than just the init command. The z3801a also sends @@Ca, @@Cg, @@Ab, @@Ah, @@Aj, @@Ak, @@Al, @@An, @@Ar, @@Av, @@Ax, @@Ay, @@AB, @@AC, @@AD, @@Ba, @@Bc, @@Bk, @@Cg, @@At, and @@Bn, none of which are available on an M12 (which would be the logical target if you're going to the trouble of an adapter), so would need to be converted to other commands, and the correct response returned. In addition, the response to the @@Bb command (Visible sat status) would need modification. ___ 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. ___ 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. ___ 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.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
Hi It's probably easier to just make up an emulator for the UT rather than doing it on a string by string basis. Only one of the strings needs to synch up with the PPS. The rest can all be generated as needed. I'm not saying it would be easy, only easier. Maybe put something like an LEA-6T and a PIC on a drop in board to fit in the 3801. Let the GPS work with lots of sats and use the emulator to hide the extras from the 3801. Initialize the gps from the PIC and more or less ignore the init commands from the 3801. Sounds like a pretty involved project. Bob On Sep 16, 2012, at 8:54 AM, Mike S mi...@flatsurface.com wrote: On 9/15/2012 2:11 PM, paul swed wrote: Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? It's more than just the init command. The z3801a also sends @@Ca, @@Cg, @@Ab, @@Ah, @@Aj, @@Ak, @@Al, @@An, @@Ar, @@Av, @@Ax, @@Ay, @@AB, @@AC, @@AD, @@Ba, @@Bc, @@Bk, @@Cg, @@At, and @@Bn, none of which are available on an M12 (which would be the logical target if you're going to the trouble of an adapter), so would need to be converted to other commands, and the correct response returned. In addition, the response to the @@Bb command (Visible sat status) would need modification. ___ 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. ___ 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.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
HI This is a pretty good start: http://www.febo.com/pages/hardware/VPCommands.pdf http://gpsd.berlios.de/vendor-docs/motorola/toc.pdf There are lots of other references out there. Bob On Sep 16, 2012, at 9:38 AM, Hui Zhang ba...@163.com wrote: I just bought a second-hand Z3801A, it also had a error message when self test - GPS Rcv error, and I saw a red LED on main board on. I want test it alone but I don't know GPS board's pin define, can someone tell me? Thanks. Hui At 2012-09-16 21:20:26,Azelio Boriani azelio.bori...@screen.it wrote: Anyway, are you sure that the GPS unit is faulty? Can you test it alone? The unit is responsive on the serial port? Is the Z3801A sending commands? Can you verify with a 'scope on the serial line if there is any signal? On Sun, Sep 16, 2012 at 2:54 PM, Mike S mi...@flatsurface.com wrote: On 9/15/2012 2:11 PM, paul swed wrote: Then respond back with whatever the response might be and then simply pass through in both direction whatever comes next. Could an updated rcvr be used. Is this init command really the only gotcha? It's more than just the init command. The z3801a also sends @@Ca, @@Cg, @@Ab, @@Ah, @@Aj, @@Ak, @@Al, @@An, @@Ar, @@Av, @@Ax, @@Ay, @@AB, @@AC, @@AD, @@Ba, @@Bc, @@Bk, @@Cg, @@At, and @@Bn, none of which are available on an M12 (which would be the logical target if you're going to the trouble of an adapter), so would need to be converted to other commands, and the correct response returned. In addition, the response to the @@Bb command (Visible sat status) would need modification. ___ 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. ___ 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. ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message ce93652a-1da6-48e3-9883-d7616ac24...@rtty.us, Bob Camp writes: Bob, There's one thing makes me scratch my head here: Why do you keep arguing like the timeconstant cannot be changed dynamically ? I use a very aggresive timeconstants initially, to quickly get the phase offset under control, and then I ramp up the timeconstant in order to reduce phase noise of the GPS, until I hit something which looks like the Allan-intercept (as Dave Mills calls it). It' won't take long time for us to agree that the timeconstant is a tradeoff between phase and frequency error, but just because it is called a timeconstant doesn't mean we cannot change it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
[time-nuts] Z3805 serial ports
I just acquired one of fluke.l's Samsung labeled z3805a units (the one with double-oven 10811A, 2 10 MHz, 2 PPS, and 2 comm ports. Bob tells me that the comm ports are configured for RS-232, but I haven't powered the thing up yet (still working on power supply) so haven't inspected what the signals really look like. I'm curious whether the PPS is on the port 1 connector (the port 2 connector only has TXD, RXD, and SG wires, so it's definitely not there). Has anyone used one of these with software that looks for PPS on the DCD line? Anything need to be done to make that work? Thanks, John ___ 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.
[time-nuts] FS: PICTIC and DMDT Boards
I've been unable to ship this summer but I am back now and have PC boards for the PICTIC II and DMDT projects for 8 USD each plus shipping. If you are interested please reply direct to me and not the list. If you have questions please check links below. Will also help with parts that are not available from other sources. http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:pictic http://www.ke5fx.com/pictic.htm http://www.n4iqt.com/picticii/ http://www.wriley.com/A%20Small%20DMTD%20System.pdf http://www.n4iqt.com/BillRiley/ Stanley ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, Tom Van Baak writes: Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? The only writings I am aware of, is what Dave Mills has written and the PLL code in NTPns, but I havn't followed this closely in the last 10 years, so do check for newer writings. Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. If you also have the allan variance between the steered source and a 3rd, better, source, the task is pretty trivial: Minimize the area below that curve. But if you do that on the curve you have, you don't optimize, you pessimize, since the lowest area, is with a timeconstant of zero. Going the other direction and maximizing the area is no good either and trying to balance the area around some pivot related to the present PLL timeconstant does not converge in my experience. What I did instead was to (badly) reinvent Shewarts ideas for testing if the phase residual is under statistical process control: I increase the timeconstant if the phase residual has too frequent zero-crossings and loosen it if they happen too seldom. Having read a lot more about statistical process control, since I built those NTP servers for the Air Traffic Control 10 years ago, I would leverage more of the theory and heuristics developed in process control. (3sigma violations, length of monotonic direction etc. etc.) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] Z3801 Replacement GPS Receiver Card
On Sat, Sep 15, 2012 at 7:04 PM, paul swed paulsw...@gmail.com wrote: As Bob mentions there may be more to it then just nailing that particular command. But worth taking a look after I deal with the wwvb psk issue. As far as the 5 to 3 V I would just use a 3 term reg like the cherry semi chip. But there are plenty of alternates. It will take 5 in and give 3.3 out at plenty of current. You can power it with a regulator chip but the slightly harder part is getting the 3V serial port level shifted to either 5V or RS232 and the same for the PPS. You can do it with a few transistors but maybe it introduces error or noise if you are not carful. I've used the 3.3 volt Oncore and really the hardest part is the new smaller connectors that you have to find. One good thing about the Oncore series is the quality of the documentation. All those commands are explained. -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote: In message5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, Tom Van Baak writes: Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? The only writings I am aware of, is what Dave Mills has written and the PLL code in NTPns, but I havn't followed this closely in the last 10 years, so do check for newer writings. Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. Well, what is being used is phase-noise intercept. Conceptually a similar intercept point will be available in Allan variance. However, as you shift between noise-variants, the Allan (and Modified Allan) variance has different scaling factor to the underlying phase noise amplitudes. The danger of using the Allan variance variant is that you get a bias in position compared to the phase-noise plots cross-overs. However, the concept is essentially the same, and the relative slopes is the same. You get in the right neighbourhood thought. The concept has been in use in the phasenoise world of things, so you would need to search the phase-noise articles to find the real source. It's been used to generate stable high-frequency signals. The analysis of PLL based splicing of ADEV curves is tricky, and I have not seen any good comprehensive analysis even if the general concept is roughly understood. The equivalent on phase-noise is however well understood and leaves no magic too it. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. You need to treat the data as loose and tight PLL measure, depending on what you look for. There is loads of calibration issues, covered in literature. If you also have the allan variance between the steered source and a 3rd, better, source, the task is pretty trivial: Minimize the area below that curve. But if you do that on the curve you have, you don't optimize, you pessimize, since the lowest area, is with a timeconstant of zero. Going the other direction and maximizing the area is no good either and trying to balance the area around some pivot related to the present PLL timeconstant does not converge in my experience. What I did instead was to (badly) reinvent Shewarts ideas for testing if the phase residual is under statistical process control: I increase the timeconstant if the phase residual has too frequent zero-crossings and loosen it if they happen too seldom. Having read a lot more about statistical process control, since I built those NTP servers for the Air Traffic Control 10 years ago, I would leverage more of the theory and heuristics developed in process control. (3sigma violations, length of monotonic direction etc. etc.) It's a complex field, and things like temperature dependencies helps to confuse you. 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi The time constant can indeed be changed dynamically, that's what is often done. The purpose of my examples was to keep things simple and look at the running condition of the loop rather than it's performance while it settles down. Bob On Sep 16, 2012, at 9:49 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message ce93652a-1da6-48e3-9883-d7616ac24...@rtty.us, Bob Camp writes: Bob, There's one thing makes me scratch my head here: Why do you keep arguing like the timeconstant cannot be changed dynamically ? I use a very aggresive timeconstants initially, to quickly get the phase offset under control, and then I ramp up the timeconstant in order to reduce phase noise of the GPS, until I hit something which looks like the Allan-intercept (as Dave Mills calls it). It' won't take long time for us to agree that the timeconstant is a tradeoff between phase and frequency error, but just because it is called a timeconstant doesn't mean we cannot change it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 50560a58.5010...@rubidium.dyndns.org, Magnus Danielson writes: What I did instead was to (badly) reinvent Shewarts ideas for testing if the phase residual is under statistical process control: I increase the timeconstant if the phase residual has too frequent zero-crossings and loosen it if they happen too seldom. Having read a lot more about statistical process control, since I built those NTP servers for the Air Traffic Control 10 years ago, I would leverage more of the theory and heuristics developed in process control. (3sigma violations, length of monotonic direction etc. etc.) It's a complex field, and things like temperature dependencies helps to confuse you. No, not really. The reason I went with the statistical control approach was exactly to not be confused or mislead by environmental or other factors: I wanted a PLL which on its own would adapt to circumstances on its own, while still maximizing the hold-over time in case of GPS loss, and all in all it has worked very well. So far I have seen it cope admirably with an OCXO which went from indoors to outdoors environment in the middle of winter, a PRS10 which gradually ran out of steam and only locked 40% of the time and various other odd-ball events, so I think I'm justified in saying that it does a pretty good job for autonomous and even unattended operation. It's certainly not perfect, but it is painfully obvious that the adaptive PLL based on statical control heuristics is much more resilient than a fixed or hand-tuned PLL. I've been trying to find an excuse for giving NTPns an overhaul, (PTP is a leading candidate for this) to get a chance to iron out the kinks I have spotted over the last 10 years, but so far life keeps me busy with other interesting stuff. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi By far the most common approach to optimizing these is the measure it and see approach. 1) measure the noise out of the GPS ( must be done no matter what) 2) measurer the noise of the specific OCXO (again must be done) 3) *guess* at a cross over 4) try it and measure the result. 5) step and repeat 3 and 4 until exhaustion sets in Indeed converting the data to phase noise rather than ADEV helps the guess process. You can go a bit crazy with math to get a better first guess. Unless you measure what you get, you won't find all the silly little things you forgot to put into your math model. If you simply try a dynamic tune approach, you never really get to an optimum point. You need a better than reference to let you know where you are. You can keep pushing out the time constant and watching with just a GPS and OCXO, but you never really know when to stop. Bob On Sep 16, 2012, at 11:47 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, Tom Van Baak writes: Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? The only writings I am aware of, is what Dave Mills has written and the PLL code in NTPns, but I havn't followed this closely in the last 10 years, so do check for newer writings. Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. If you also have the allan variance between the steered source and a 3rd, better, source, the task is pretty trivial: Minimize the area below that curve. But if you do that on the curve you have, you don't optimize, you pessimize, since the lowest area, is with a timeconstant of zero. Going the other direction and maximizing the area is no good either and trying to balance the area around some pivot related to the present PLL timeconstant does not converge in my experience. What I did instead was to (badly) reinvent Shewarts ideas for testing if the phase residual is under statistical process control: I increase the timeconstant if the phase residual has too frequent zero-crossings and loosen it if they happen too seldom. Having read a lot more about statistical process control, since I built those NTP servers for the Air Traffic Control 10 years ago, I would leverage more of the theory and heuristics developed in process control. (3sigma violations, length of monotonic direction etc. etc.) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message acd158ca-d76c-4a8b-b77d-4fa691d0b...@rtty.us, Bob Camp writes: The purpose of my examples was to keep things simple and look at the running condition of the loop rather than it's performance while it settles down. But what is running condition ? I see my PLL adjust to thermal conditions during summer (A/C) and winter (heating) and even to GPS constellation changes... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 3a001267-52de-4ee9-b6ee-6638fb270...@rtty.us, Bob Camp writes: Hi By far the most common approach to optimizing these is the measure it and see approach. 1) measure the noise out of the GPS ( must be done no matter what) 2) measurer the noise of the specific OCXO (again must be done) 3) *guess* at a cross over 4) try it and measure the result. 5) step and repeat 3 and 4 until exhaustion sets in Indeed. What I've done is to automate that, using the zero-crossing frequency of the residual as input. If you simply try a dynamic tune approach, you never really get to an optimum point. For the stuff I did, hitting the optimum point exactly from the beginning, was not nearly as important as getting close to the optimum point when circumstances changed. But with that being said: Even in the ideal scientific setting, I think my approach is not only valid, I think it is one of the most efficient ones, because you don't need a 3rd reference to measure against. If you have a 3rd ( better) reference, by all means use it, but if all you have is a GPSDO, my method delivers better results than I have seen from anything else. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Great dialog, One thing I have seen is the Allan intercept almost always has a knee. If you wanted the best possible GPS quartz reference developing a variable Allan intercept would allow this knee to be moved and then mathematically removed during a gated measurement. Allowing to effectively see behind he knee offering lower uncertainty in this important area. Thomas Knox Date: Sun, 16 Sep 2012 19:20:24 +0200 From: mag...@rubidium.dyndns.org To: time-nuts@febo.com Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote: In message5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, Tom Van Baak writes: Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? The only writings I am aware of, is what Dave Mills has written and the PLL code in NTPns, but I havn't followed this closely in the last 10 years, so do check for newer writings. Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. Well, what is being used is phase-noise intercept. Conceptually a similar intercept point will be available in Allan variance. However, as you shift between noise-variants, the Allan (and Modified Allan) variance has different scaling factor to the underlying phase noise amplitudes. The danger of using the Allan variance variant is that you get a bias in position compared to the phase-noise plots cross-overs. However, the concept is essentially the same, and the relative slopes is the same. You get in the right neighbourhood thought. The concept has been in use in the phasenoise world of things, so you would need to search the phase-noise articles to find the real source. It's been used to generate stable high-frequency signals. The analysis of PLL based splicing of ADEV curves is tricky, and I have not seen any good comprehensive analysis even if the general concept is roughly understood. The equivalent on phase-noise is however well understood and leaves no magic too it. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. You need to treat the data as loose and tight PLL measure, depending on what you look for. There is loads of calibration issues, covered in literature. If you also have the allan variance between the steered source and a 3rd, better, source, the task is pretty trivial: Minimize the area below that curve. But if you do that on the curve you have, you don't optimize, you pessimize, since the lowest area, is with a timeconstant of zero. Going the other direction and maximizing the area is no good either and trying to balance the area around some pivot related to the present PLL timeconstant does not converge in my experience. What I did instead was to (badly) reinvent Shewarts ideas for testing if the phase residual is under statistical process control: I increase the timeconstant if the phase residual has too frequent zero-crossings and loosen it if they happen too seldom. Having read a lot more about statistical process control, since I built those NTP servers for the Air Traffic Control 10 years ago, I would leverage more of the theory and heuristics developed in process control. (3sigma violations, length of monotonic direction etc. etc.) It's a complex field, and things like temperature dependencies helps to confuse you. 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. ___ 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.
Re: [time-nuts] Zero-Crossing Detector Design?
Am 20.07.2012 00:57, schrieb Richard (Rick) Karlquist: A fast comparator seems like a good idea, and it is simple, however it is actually the last thing you want to use. High thermal sensitivity and high jitter. Rick On 7/19/2012 1:35 PM, Dan Kemppainen wrote: Or use a fast comparator such as an ADCMP600 series. Much lower delays, and faster rising/falling edges. FYI, I've had good luck with this at 30Mhz. You could transformer couple this one, or simply couple it through a cap. The ADCMP580 could be an excellent choice for the output stage of a Collins type device. Running quite cool and showing only 180 ps _total_ delay is a good start. Good rise/fall times on home-etched 0.5 mm FR4 (and some semi-rigid): http://www.imagesup.de/bild-_Mgif-119362.htm regards, Gerhard, dk4xp ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi The basic assumption is that this is a lab gizmo and that there is indeed a static adev (or very low frequency phase noise) plot for the OCXO (or Rb). The other assumption is that this plot is quite good (say decreasing or flat to 10,000 seconds). IF that's all true, then the running condition is the pll loop frequency / time constant / cross over that does not degrade that adev (or phase noise) plot with noise from the GPS. Bob On Sep 16, 2012, at 1:56 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message acd158ca-d76c-4a8b-b77d-4fa691d0b...@rtty.us, Bob Camp writes: The purpose of my examples was to keep things simple and look at the running condition of the loop rather than it's performance while it settles down. But what is running condition ? I see my PLL adjust to thermal conditions during summer (A/C) and winter (heating) and even to GPS constellation changes... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi The knee is a basic artifact of the cross over in the noise of one (say the OCXO) to the noise of the other (say the GPS). It's one of those things you can reduce, but never eliminate completely. The noise of the combined pair will always be slightly worse than the best of the two when they are in the cross over region. Bob On Sep 16, 2012, at 2:58 PM, Tom Knox act...@hotmail.com wrote: Great dialog, One thing I have seen is the Allan intercept almost always has a knee. If you wanted the best possible GPS quartz reference developing a variable Allan intercept would allow this knee to be moved and then mathematically removed during a gated measurement. Allowing to effectively see behind he knee offering lower uncertainty in this important area. Thomas Knox Date: Sun, 16 Sep 2012 19:20:24 +0200 From: mag...@rubidium.dyndns.org To: time-nuts@febo.com Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote: In message5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, Tom Van Baak writes: Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? The only writings I am aware of, is what Dave Mills has written and the PLL code in NTPns, but I havn't followed this closely in the last 10 years, so do check for newer writings. Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. Well, what is being used is phase-noise intercept. Conceptually a similar intercept point will be available in Allan variance. However, as you shift between noise-variants, the Allan (and Modified Allan) variance has different scaling factor to the underlying phase noise amplitudes. The danger of using the Allan variance variant is that you get a bias in position compared to the phase-noise plots cross-overs. However, the concept is essentially the same, and the relative slopes is the same. You get in the right neighbourhood thought. The concept has been in use in the phasenoise world of things, so you would need to search the phase-noise articles to find the real source. It's been used to generate stable high-frequency signals. The analysis of PLL based splicing of ADEV curves is tricky, and I have not seen any good comprehensive analysis even if the general concept is roughly understood. The equivalent on phase-noise is however well understood and leaves no magic too it. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. You need to treat the data as loose and tight PLL measure, depending on what you look for. There is loads of calibration issues, covered in literature. If you also have the allan variance between the steered source and a 3rd, better, source, the task is pretty trivial: Minimize the area below that curve. But if you do that on the curve you have, you don't optimize, you pessimize, since the lowest area, is with a timeconstant of zero. Going the other direction and maximizing the area is no good either and trying to balance the area around some pivot related to the present PLL timeconstant does not converge in my experience. What I did instead was to (badly) reinvent Shewarts ideas for testing if the phase residual is under statistical process control: I increase the timeconstant if the phase residual has too frequent zero-crossings and loosen it if they happen too seldom. Having read a lot more about statistical process control, since I built those NTP servers for the Air Traffic Control 10 years ago, I would leverage more of the theory and heuristics developed in process control. (3sigma violations, length of monotonic direction etc. etc.) It's a complex field, and things like temperature dependencies helps to confuse you. 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message bay162-w9fff4214c4de8fd1752f3df...@phx.gbl, Tom Knox writes: Great dialog, One thing I have seen is the Allan intercept almost always has a knee. If you wanted the best possible GPS quartz reference developing a variable Allan intercept would allow this knee to be moved and then mathematically removed during a gated measurement. Allowing to effectively see behind he knee offering lower uncertainty in this important area. I did try a spectral approach before I settled on the current approach, because I foresaw the precence of 12 and 24 hour periodicities, but while good on the paper and post-factum, I never managed to get it to autoestimate reliably in real-time. If you can find the paper about the algorithm timing.com was founded on, you will find much interesting fodder therein, but my reimplementation of their algorithem only worked for Rb's I could never get it to do anything usable for OCXOs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 2dea9396-95eb-4092-a443-a72350cc1...@rtty.us, Bob Camp writes: The basic assumption is that this is a lab gizmo and that there is indeed a static adev (or very low frequency phase noise) plot for the OCXO (or Rb). Bob, I think this is where the premier-league differs from the amateurs-leagues in the time-nuts competition :-) I suspect that the majority of GPSDO's on this mailinglists do not have access to a independent frequency standard good enough to make that measurement, much less a temperature controlled environment. Yes, in a lab environment, you can measure and adjust it once and for all, or at least once for every few years. The rest of us may find it easier to have a PLL that auto-optimizes so that we don't have to waste our limited time-nut time on recalibrating our house-standard. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] Zero-Crossing Detector Design?
On 9/16/2012 12:03 PM, Gerhard Hoffmann wrote: Am 20.07.2012 00:57, schrieb Richard (Rick) Karlquist: A fast comparator seems like a good idea, and it is simple, however it is actually the last thing you want to use. High thermal sensitivity and high jitter. Rick On 7/19/2012 1:35 PM, Dan Kemppainen wrote: Or use a fast comparator such as an ADCMP600 series. Much lower delays, and faster rising/falling edges. FYI, I've had good luck with this at 30Mhz. You could transformer couple this one, or simply couple it through a cap. The ADCMP580 could be an excellent choice for the output stage of a Collins type device. Running quite cool and showing only 180 ps _total_ delay is a good start. Good rise/fall times on home-etched 0.5 mm FR4 (and some semi-rigid): http://www.imagesup.de/bild-_Mgif-119362.htm regards, Gerhard, dk4xp Again, a really high speed comparator necessarily has a really broad bandwidth, meaning its noise bandwidth is large. This means more noise and more jitter than a lower speed comparator. The comparator cited is much faster than necessary for 30 MHz, by orders of magnitude. Rick N6RK ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
Hi …but endless testing for minimal return is what being a Time Nut is all about …. Bob On Sep 16, 2012, at 3:39 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 2dea9396-95eb-4092-a443-a72350cc1...@rtty.us, Bob Camp writes: The basic assumption is that this is a lab gizmo and that there is indeed a static adev (or very low frequency phase noise) plot for the OCXO (or Rb). Bob, I think this is where the premier-league differs from the amateurs-leagues in the time-nuts competition :-) I suspect that the majority of GPSDO's on this mailinglists do not have access to a independent frequency standard good enough to make that measurement, much less a temperature controlled environment. Yes, in a lab environment, you can measure and adjust it once and for all, or at least once for every few years. The rest of us may find it easier to have a PLL that auto-optimizes so that we don't have to waste our limited time-nut time on recalibrating our house-standard. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 16 Sep, 2012, at 00:40 , Tom Van Baak wrote: I worry in your example about the long cross-over time. This may be ideal for frequency stability, but probably is not good for time accuracy. If one is using the GPSDO as a timing reference, I would think a shorter time constant will keep the rms time error down. Has anyone on the list done work optimizing the timing accuracy rather than the frequency stability? I'm not sure there could be a difference between the goals of frequency accuracy and time accuracy that would effect that time constant. The time error is the time integral of the frequency error, so anything which manages to minimize the frequency error of the oscillator (both the magnitude of the error and its duration) will also minimize the time error. The time constant is selected to be the minimum value which makes it probable that the frequency or time error you have measured (for a PLL the data are time errors) is in fact an error that the oscillator has made rather than an artifact of the noise in the measurement system. There might be a difference in the best control action to take to optimally achieve each of those goals. In particular if your goal is frequency accuracy the best control action in response to the measurement of a frequency error might be to correct that error, i.e. to minimize the frequency error once you know you have one. If your goal is time accuracy, however, then the response to a measured frequency error is going to be to intentionally make a frequency error in the other direction for a while to correct the accumulated time error. In this case, though, it seems to me that by selecting a PLL as the control discipline (rather than, say, a FLL) you've already made the decision to take control actions which ensure time accuracy. Dennis Ferguson ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 9/16/12 10:20 AM, Magnus Danielson wrote: On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote: Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. Well, what is being used is phase-noise intercept. Conceptually a similar intercept point will be available in Allan variance. However, as you shift between noise-variants, the Allan (and Modified Allan) variance has different scaling factor to the underlying phase noise amplitudes. The danger of using the Allan variance variant is that you get a bias in position compared to the phase-noise plots cross-overs. However, the concept is essentially the same, and the relative slopes is the same. You get in the right neighbourhood thought. The concept has been in use in the phasenoise world of things, so you would need to search the phase-noise articles to find the real source. It's been used to generate stable high-frequency signals. The analysis of PLL based splicing of ADEV curves is tricky, and I have not seen any good comprehensive analysis even if the general concept is roughly understood. The equivalent on phase-noise is however well understood and leaves no magic too it. I'm not sure that the theory of phase noise intercepts, in practical systems, is actually used. It seems that everyone I've talked to uses the theory to get in the ballpark and then does simulations at the design review, and ultimately, builds it and tests, and then tweaks the implementation to optimize (especially if the loop closure is implemented digitally in software/FPGA) When talking real high performance, there's so many confounding error factors that it's not like you can build what theory says and hit the mark. The *actual* noise distributions follow the Leeson model in general, but have lumps and bumps, and there's always narrow band oddities (power supply filtering, noise from switching power converters, etc.) Let's face it, real high performance source design has a lot of art and craft in it. You can't get to that point without sound engineering, but that last order of magnitude is all about suck it and see. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. It's a complex field, and things like temperature dependencies helps to confuse you. Ain't that the truth.. And then, there's proving that what you built is actually doing what you claim. State of the art sources require beyond state of the art verification methods... It's easy to write a spec for, say, incremental Allan Dev of 1E-16 at some tau. A bit harder to test at a constant frequency. Now throw in a varying frequency (say, because of temperature variation or Doppler).. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 34d5c3ce-6b3d-4944-996a-7637373b2...@gmail.com, Dennis Ferguson wr ites: I'm not sure there could be a difference between the goals of frequency accuracy and time accuracy that would effect that time constant. It does. A PLL more or less corresponds to an PI regulation, where a FLL only needs to have the I term. Because you don't have the interaction between the P and I terms, the I-timeconstant can be longer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
[time-nuts] PP2S
Some GPSDO have both a 1PPS and a PP2S (pulse per 2 second) output. I have two questions for one of you telecom experts: 1) What is the history, and the purpose of that PP2S signal? 2) What is the official spec for which second the PP2S lands on? Is it odd seconds or even seconds? Is it GPS time (easy) or UTC (problematic)? If UTC, what happens after a leap second? Thanks, /tvb ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 10:28 PM, Jim Lux wrote: On 9/16/12 10:20 AM, Magnus Danielson wrote: On 09/16/2012 05:47 PM, Poul-Henning Kamp wrote: Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. Well, what is being used is phase-noise intercept. Conceptually a similar intercept point will be available in Allan variance. However, as you shift between noise-variants, the Allan (and Modified Allan) variance has different scaling factor to the underlying phase noise amplitudes. The danger of using the Allan variance variant is that you get a bias in position compared to the phase-noise plots cross-overs. However, the concept is essentially the same, and the relative slopes is the same. You get in the right neighbourhood thought. The concept has been in use in the phasenoise world of things, so you would need to search the phase-noise articles to find the real source. It's been used to generate stable high-frequency signals. The analysis of PLL based splicing of ADEV curves is tricky, and I have not seen any good comprehensive analysis even if the general concept is roughly understood. The equivalent on phase-noise is however well understood and leaves no magic too it. I'm not sure that the theory of phase noise intercepts, in practical systems, is actually used. It seems that everyone I've talked to uses the theory to get in the ballpark and then does simulations at the design review, and ultimately, builds it and tests, and then tweaks the implementation to optimize (especially if the loop closure is implemented digitally in software/FPGA) When talking real high performance, there's so many confounding error factors that it's not like you can build what theory says and hit the mark. The *actual* noise distributions follow the Leeson model in general, but have lumps and bumps, and there's always narrow band oddities (power supply filtering, noise from switching power converters, etc.) Let's face it, real high performance source design has a lot of art and craft in it. You can't get to that point without sound engineering, but that last order of magnitude is all about suck it and see. I agree, but my point was that Allan intercept might be an attempt for the phase-noise intercept which is better understood. Then again, as always there are other things to consider. Looking single-mindedly on Allan deviation or phase-noise plots will make you loose other details, like systematic features and their tracking, the systematic errors of the loop, the hold-over properties of the loop and track-in properties etc. etc. I am also amazed when comparing the resolution to ADEV noise. They have different properties when you changes tau, and also if you want to make it work very well, lowering added noise should be important, no? Only in economic balanced designs would roughly equal noises be used. I spent a lot of time with the code in NTPns, to try to get that PLL to converge on the optimum, and while generally good, it's not perfect. The basic problem is that the data you have available for autotuning, is the allan variance between your input and your steered source. It's a complex field, and things like temperature dependencies helps to confuse you. Ain't that the truth.. And then, there's proving that what you built is actually doing what you claim. State of the art sources require beyond state of the art verification methods... True that. It's easy to write a spec for, say, incremental Allan Dev of 1E-16 at some tau. A bit harder to test at a constant frequency. Now throw in a varying frequency (say, because of temperature variation or Doppler).. ... or varying phase... It seems like much effort goes into the noise aspect, but not enough on the systematics... and how those interact for varying degrees of tau. 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 10:30 PM, Poul-Henning Kamp wrote: In message34d5c3ce-6b3d-4944-996a-7637373b2...@gmail.com, Dennis Ferguson wr ites: I'm not sure there could be a difference between the goals of frequency accuracy and time accuracy that would effect that time constant. It does. A PLL more or less corresponds to an PI regulation, where a FLL only needs to have the I term. Because you don't have the interaction between the P and I terms, the I-timeconstant can be longer. The balance between P and I is important to establish the damping of your PI regulator. A good PI-based PLL actually combines the FLL and PLL domains by differentiating the phase detector and feeding that through a scaling into the integrator, adding to the phase-detector scaled by the I factor. That way you can get very good pull-in properties which then gently goes over to PLL properties. When PLL lock is achieved the FLL scale-factor can be removed, as it only contributes noise. A strict FLL would have the differentiated phase scaled and added into the frequency steering, after the PI-regulators integrator. This D term would set the frequency right, but the integrator would not learn the frequency as quick and there would be tracking errors until it learns. This differentiated phase aided integrator solves the bad pull-in behaviour for the case when the reference signal and the oscillators signal is far apart. 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.
Re: [time-nuts] PP2S
On 16 Sep, 2012, at 17:11 , Tom Van Baak wrote: Some GPSDO have both a 1PPS and a PP2S (pulse per 2 second) output. I have two questions for one of you telecom experts: 1) What is the history, and the purpose of that PP2S signal? 2) What is the official spec for which second the PP2S lands on? Is it odd seconds or even seconds? Is it GPS time (easy) or UTC (problematic)? If UTC, what happens after a leap second? The PP2S signal is a US CDMA (i.e. CDMA2000) thing. It is aligned to the even seconds in GPS time. My memory is dim but I think that the choice relates to the fact that the CDMA spreading code LFSR rolls over every 26.666 ms (it is a 15 bit LFSR, so dividing 32767 by 26.666 ms should be the 1.228 MHz chip rate), so it rolls over 75 times every 2 seconds. The goal is to align the code sequence transmitted by every station, and a 1 PPS timing reference wouldn't guarantee that since 1 second isn't an integral multiple of the roll over time. Dennis Ferguson ___ 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.
Re: [time-nuts] PP2S
Per the 58503B brochure: An even-second (1 PP2S) output is available as an option to the 58503B. The even-second output option provides one pulse every other second, synchronized to the even seconds in GPS time. This is the reference time used in CDMA base stations. Some GPSDO have both a 1PPS and a PP2S (pulse per 2 second) output. I have two questions for one of you telecom experts: 1) What is the history, and the purpose of that PP2S signal? 2) What is the official spec for which second the PP2S lands on? Is it odd seconds or even seconds? Is it GPS time (easy) or UTC (problematic)? If UTC, what happens after a leap second? Thanks, /tvb ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message 505642f5.1000...@rubidium.dyndns.org, Magnus Danielson writes: On 09/16/2012 10:30 PM, Poul-Henning Kamp wrote: A good PI-based PLL actually combines the FLL and PLL domains [...] But it is the phase correction that doubles the (absolute) magnitude of the frequency noise, by overcompensating frequency errors in order to catch up with the integrated phase error they have caused. Optimal frequency stability will always be at the expense of phase offset. I belive this is the main rationale behind the EAL timescale. A strict FLL would have the differentiated [...] Uhm, sorry, that sounds like rubbish to me. A FLL corrects by the average of the change of phase per unit of time, and that's that: If your phase changes by one microsecond in 1000 seconds, you tweak the frequency 1e-9 in the appropriate direction. There is no (D)ifferential and no (P)roportional term in a FLL, only the (I)ntegral term used to calculate that average. With all that said, when you are doing things in software, you *can* have both: Steer the local osc by FLL to get optimal frequency (and thus hold-over), and estimate and compensate for the phase error in software. I tried that with a PRS10: I disabled it's internal PLL and instead used the serial port to apply FLL corrections, and let software deal with the random-walk phase offset. In theory that should have roughly doubled the hold-over performance but in practice I could not get a statistical significance due to more significant effects such as drift. A second order FLL might be able to solve that, but the swing-in of that was far longer than the relevant tune in spec. And that is essentially what timing.com's algorithm for clock discipline does for Cs's: Steer the individual Cs' to optimal frequency and keep track of the phase error by other means. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 16 Sep, 2012, at 16:30 , Poul-Henning Kamp wrote: In message 34d5c3ce-6b3d-4944-996a-7637373b2...@gmail.com, Dennis Ferguson wr ites: I'm not sure there could be a difference between the goals of frequency accuracy and time accuracy that would effect that time constant. Note that the that time constant referred to here, the topic of the message I was responding to, was explicitly a PLL time constant. If you have decided to use a PLL as your control discipline I think you end up with the same time constant whether your goal is accurate frequency or accurate time since, with a PLL, these end up being the same problem. It does. A PLL more or less corresponds to an PI regulation, where a FLL only needs to have the I term. Because you don't have the interaction between the P and I terms, the I-timeconstant can be longer. This sounds right. As I said, if you pick a control discipline other than a PLL, as might be advantageous to do if your concern is solely with accurate frequency, then the optimum might be different. If you are using a PLL in both cases, however, then the problems are essentially the same. Dennis Ferguson ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
In message ad054298-f656-477f-9fb1-5d48c1b07...@gmail.com, Dennis Ferguson wr ites: If you are using a PLL in both cases, however, then the problems are essentially the same. Well, not quite: Depending on the stiffness of your PLL, you can minimize phase error at the cost of frequency error or frequency error at the cost of phase error, and either is a valid engineering decision depending which of the two are more important to you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
Re: [time-nuts] Even pulse per second signals
Sorry I should have said pulse per even second. I recall the pulses are aligned with the UTC even second. --- On Sun, 9/16/12, Mark Spencer mspencer12...@yahoo.ca wrote: From: Mark Spencer mspencer12...@yahoo.ca Subject: Re: Even pulse per second signals To: time-nuts@febo.com Received: Sunday, September 16, 2012, 3:07 PM While I don't have first hand knowledge of CDMA base stations, I recall seeing a symmetricom data sheet that stated that even pulse per second signals were (or are ?) used for timing in CDMA base stations. Sorry I have no idea why the even pulse per second signal is preferable in that applcation. Regards Mark Spencer Some GPSDO have both a 1PPS and a PP2S (pulse per 2 second) output. I have two questions for one of you telecom experts: 1) What is the history, and the purpose of that PP2S signal? 2) What is the official spec for which second the PP2S lands on? Is it odd seconds or even seconds? Is it GPS time (easy) or UTC (problematic)? If UTC, what happens after a leap second? Thanks, /tvb -- ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
HI In some cases, the difference can be your definition of time accuracy. If short term GPS time is what you are worried about, then indeed that's a different beast than a 30 day plot against your direct line to USNO. Bob On Sep 16, 2012, at 4:12 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 16 Sep, 2012, at 00:40 , Tom Van Baak wrote: I worry in your example about the long cross-over time. This may be ideal for frequency stability, but probably is not good for time accuracy. If one is using the GPSDO as a timing reference, I would think a shorter time constant will keep the rms time error down. Has anyone on the list done work optimizing the timing accuracy rather than the frequency stability? I'm not sure there could be a difference between the goals of frequency accuracy and time accuracy that would effect that time constant. The time error is the time integral of the frequency error, so anything which manages to minimize the frequency error of the oscillator (both the magnitude of the error and its duration) will also minimize the time error. The time constant is selected to be the minimum value which makes it probable that the frequency or time error you have measured (for a PLL the data are time errors) is in fact an error that the oscillator has made rather than an artifact of the noise in the measurement system. There might be a difference in the best control action to take to optimally achieve each of those goals. In particular if your goal is frequency accuracy the best control action in response to the measurement of a frequency error might be to correct that error, i.e. to minimize the frequency error once you know you have one. If your goal is time accuracy, however, then the response to a measured frequency error is going to be to intentionally make a frequency error in the other direction for a while to correct the accumulated time error. In this case, though, it seems to me that by selecting a PLL as the control discipline (rather than, say, a FLL) you've already made the decision to take control actions which ensure time accuracy. Dennis Ferguson ___ 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. ___ 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 11:47 PM, Poul-Henning Kamp wrote: In message505642f5.1000...@rubidium.dyndns.org, Magnus Danielson writes: On 09/16/2012 10:30 PM, Poul-Henning Kamp wrote: A good PI-based PLL actually combines the FLL and PLL domains [...] But it is the phase correction that doubles the (absolute) magnitude of the frequency noise, by overcompensating frequency errors in order to catch up with the integrated phase error they have caused. Optimal frequency stability will always be at the expense of phase offset. I belive this is the main rationale behind the EAL timescale. EAL is a paper scale and not a locked loop thing. You get different properties as well as different abilities. A strict FLL would have the differentiated [...] Uhm, sorry, that sounds like rubbish to me. I think you misunderstood my wording in that case. A FLL corrects by the average of the change of phase per unit of time, and that's that: The FLL uses a frequency detector rather than a phase detector, if you have a phase detector response you can get your frequency error by differentiation. Does that make you disagree wildly? If your phase changes by one microsecond in 1000 seconds, you tweak the frequency 1e-9 in the appropriate direction. There is no (D)ifferential and no (P)roportional term in a FLL, only the (I)ntegral term used to calculate that average. Strange, as I have seen many FLLs having properties like this in both books and papers. It is not uncommon in GPS receivers to both produce a Phase and a frequency detection, and then use a combined FLL/PLL topology with PI properties for tracking, and then let software trim the various gains. Chapter 5.3, 5.4 and 5.5 of Elliott Kaplan Understanding GPS principles and applications (second edition, I can look up the chapters for first edition if needed) illustrates what I mean. You can naturally do FLLs in first-degree (proportional scaling), second degree (PI or smoothing filter) or higher. With all that said, when you are doing things in software, you *can* have both: Steer the local osc by FLL to get optimal frequency (and thus hold-over), and estimate and compensate for the phase error in software. Many users of the (in)famous 4046 has been using both since its inception, and the concept was not new at the time. Not saying it is anywhere close to optimum performance, but PLL and FLL in analogue hardware have been done with slide-ruler level of design. I tried that with a PRS10: I disabled it's internal PLL and instead used the serial port to apply FLL corrections, and let software deal with the random-walk phase offset. In theory that should have roughly doubled the hold-over performance but in practice I could not get a statistical significance due to more significant effects such as drift. A second order FLL might be able to solve that, but the swing-in of that was far longer than the relevant tune in spec. And that is essentially what timing.com's algorithm for clock discipline does for Cs's: Steer the individual Cs' to optimal frequency and keep track of the phase error by other means. There are many ways to steer things. BIPM does EAL and then TAI for many reasons, among other that many clocks is just stable but not very accurate. Only a handful of clocks contribute to the phase of TAI, but around 350 contribute to the stability of EAL. 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.
Re: [time-nuts] GPSDO control loops and correcting quantizationerror
On 09/16/2012 11:51 PM, Poul-Henning Kamp wrote: In messagead054298-f656-477f-9fb1-5d48c1b07...@gmail.com, Dennis Ferguson wr ites: If you are using a PLL in both cases, however, then the problems are essentially the same. Well, not quite: Depending on the stiffness of your PLL, you can minimize phase error at the cost of frequency error or frequency error at the cost of phase error, and either is a valid engineering decision depending which of the two are more important to you. Sometimes such compromises is the only way to go, but sometimes you may consider to raise your system complexity. One such thing is to increase the PLL degree. There are many tools in the toolbox. Another example is the OCXO oven control. A typical OCXO oven tries to quickly steer back the temperature. During the little temperature trip, the oscillator will have the wrong frequency, but as the oven settles again, it will be more or less back where you started. Trouble is, often you have only gone above or below frequency, so the integral of that frequency error is a phase-shift. oups. Hope your application wasn't phase-stability sensitive... I have seen only one vendor address this issue, complete with graphs showing the phase-creep over several temperature cycles, and yes... a typical oven shifts phase with a residual error after a full temperature cycle of ambient temperature, since the errors doesn't cancel completely. While this example may not be spot on to the point Poul-Henning is making, it can be used as a good illustration that frequency stability goal and phase stability goals isn't necessarily the same. Going back to the PLL, with a tight PLL, you track in errors quickly. This looks good as you then track in phase errors and the time error as it accumulates doesn't become large. On the other hand, when doing this you need to steer your frequency wider in order to more quickly track in that phase error. A looser PLL will track in errors more sluggishly, and hence will use less frequency deviations for track-in, but with the downside that the frequency errors will remain longer and the time error will become larger. These are the systematic reactions to phase and frequency steps and ramps. The degree of the system will also change these parameters. It is also important to remember that changes in the reference and changes within the loop gets low-passed and high-passed (respectively) by the loop bandwidth. A temperature shift on the locked oscillator will be a typical in-loop effect which gets high-passed. Then there is the background noise processes to consider, but we spend so much time on them already. Cheers, Magnsu ___ 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.
[time-nuts] Reducing lab noise with LED lighting.
In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy so I have started researching cost effective LED lighting and was amazed at what is available. On eBay there are 10 to 100 watt raw chips for $2-25.00 but that is equal to about 5 times the lumen of incandescent lighting. I was going to try building the heat sinks and supply into my existing bench fixtures. I will post more info soon. Thomas Knox ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
Hi The thing that makes the CFL's nasty for lab use are the cheap little switchers built into them. Conventional LED lights also have cheap little switchers in them. Doing them with a 30% efficient linear regulator gets you back to halogen type lumens per watt... Bob On Sep 16, 2012, at 8:09 PM, Tom Knox act...@hotmail.com wrote: In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy so I have started researching cost effective LED lighting and was amazed at what is available. On eBay there are 10 to 100 watt raw chips for $2-25.00 but that is equal to about 5 times the lumen of incandescent lighting. I was going to try building the heat sinks and supply into my existing bench fixtures. I will post more info soon. Thomas Knox ___ 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. ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
Another good source of low-noise lighting is marine hardware stores. I owned a sailboat for a while. Sailboats are floating radio stations. I had Marine HF and VHF and Radar all running off banks of lead acid batteries. You have the same noise issues on the water as in ham radio stations.So many of the lighting products are designed to be radio-quiet and will say they are quiet on the box. The LEDs are good, if the power supply is clean but like all power supplies you have to check. Actually the CFLs are radio quiet too it is the little power supply built into the base that makes the noise. -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
I've seen lots of halogen power supplies which use cheap switchers too! On 9/16/2012 8:55 PM, Bob Camp wrote: Hi The thing that makes the CFL's nasty for lab use are the cheap little switchers built into them. Conventional LED lights also have cheap little switchers in them. Doing them with a 30% efficient linear regulator gets you back to halogen type lumens per watt... Bob On Sep 16, 2012, at 8:09 PM, Tom Knox act...@hotmail.com wrote: In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy so I have started researching cost effective LED lighting and was amazed at what is available. On eBay there are 10 to 100 watt raw chips for $2-25.00 but that is equal to about 5 times the lumen of incandescent lighting. I was going to try building the heat sinks and supply into my existing bench fixtures. I will post more info soon. Thomas Knox ___ 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. ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1424 / Virus Database: 2437/5271 - Release Date: 09/16/12 ___ 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.
[time-nuts] Z3805 serial ports
The Z3805A has two serial ports: * An I/O Port (Port 1) 25-pin female DB series connector which provides a serial interface under RS-232 control. * A second Output Port (Port 2) which provides a continuous (broadcast) time and date serial output once every two seconds (even second) at 9600, N, 8, 1. From: time-nuts-requ...@febo.com time-nuts-requ...@febo.com To: time-nuts@febo.com Sent: Sunday, September 16, 2012 11:48 AM Subject: time-nuts Digest, Vol 98, Issue 64 Send time-nuts mailing list submissions to time-nuts@febo.com To subscribe or unsubscribe via the World Wide Web, visit https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts or, via email, send a message with subject or body 'help' to time-nuts-requ...@febo.com You can reach the person managing the list at time-nuts-ow...@febo.com When replying, please edit your Subject line so it is more specific than Re: Contents of time-nuts digest... Today's Topics: 1. Z3805 serial ports (John Ackermann N8UR) 2. FS: PICTIC and DMDT Boards (Stanley) 3. Re: GPSDO control loops and correcting quantizationerror (Poul-Henning Kamp) 4. Re: Z3801 Replacement GPS Receiver Card (mike cook) 5. Re: Z3801 Replacement GPS Receiver Card (Chris Albertson) 6. Re: GPSDO control loops and correcting quantizationerror (Magnus Danielson) 7. Re: GPSDO control loops and correcting quantizationerror (Bob Camp) 8. Re: GPSDO control loops and correcting quantizationerror (Poul-Henning Kamp) -- Message: 1 Date: Sun, 16 Sep 2012 11:16:59 -0400 From: John Ackermann N8UR j...@febo.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: [time-nuts] Z3805 serial ports Message-ID: 5055ed6b.7070...@febo.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed I just acquired one of fluke.l's Samsung labeled z3805a units (the one with double-oven 10811A, 2 10 MHz, 2 PPS, and 2 comm ports. Bob tells me that the comm ports are configured for RS-232, but I haven't powered the thing up yet (still working on power supply) so haven't inspected what the signals really look like. I'm curious whether the PPS is on the port 1 connector (the port 2 connector only has TXD, RXD, and SG wires, so it's definitely not there). Has anyone used one of these with software that looks for PPS on the DCD line? Anything need to be done to make that work? Thanks, John -- Message: 2 Date: Sun, 16 Sep 2012 10:45:10 -0500 From: Stanley timen...@n4iqt.com To: time nuts list time-nuts@febo.com Subject: [time-nuts] FS: PICTIC and DMDT Boards Message-ID: E2CBB0B758A14119A83F3C7560B28DF9@StanleyPC Content-Type: text/plain; charset=iso-8859-1 I've been unable to ship this summer but I am back now and have PC boards for the PICTIC II and DMDT projects for 8 USD each plus shipping. If you are interested please reply direct to me and not the list. If you have questions please check links below. Will also help with parts that are not available from other sources. http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:pictic http://www.ke5fx.com/pictic.htm http://www.n4iqt.com/picticii/ http://www.wriley.com/A%20Small%20DMTD%20System.pdf http://www.n4iqt.com/BillRiley/ Stanley -- Message: 3 Date: Sun, 16 Sep 2012 15:47:17 + From: Poul-Henning Kamp p...@phk.freebsd.dk To: Tom Van Baak t...@leapsecond.com Cc: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] GPSDO control loops and correcting quantizationerror Message-ID: 82536.1347810...@critter.freebsd.dk Content-Type: text/plain; charset=ISO-8859-1 In message 5C52FBDBA5084AD4A36300FBA73BEF5E@pc52, Tom Van Baak writes: Yes, timing accuracy has been my main focus and in general I have been using integration times on the low side of 1 seconds for that, but it depends a lot on the OCXO/Rb and environment. The PLL in NTPns is a (by now) old attempt to make a self-tuning PLL for optimal time stability, and it does a surprisingly good job at it. Are there papers that talk about how to optimize for best timing or best frequency or (no free lunch) some compromise combination of the two? The only writings I am aware of, is what Dave Mills has written and the PLL code in NTPns, but I havn't followed this closely in the last 10 years, so do check for newer writings. Dave Mills coined the term allan intercept as the cross over of the two sources allan variances and it's a good google search for his relevant papers. I'm not entirely sure his rule of thumb for regulating to that point is mathematically sound precise, but the concept itself is certainly valid, even if you have to compensate for the timeconstant of the PLL you use to regulate to that point. I spent a lot of time with
Re: [time-nuts] Reducing lab noise with LED lighting.
HI Most of my little desktop cheap halogens got turned into LED's a while back. Forgot about them…. Bob On Sep 16, 2012, at 9:06 PM, Peter Gottlieb n...@verizon.net wrote: I've seen lots of halogen power supplies which use cheap switchers too! On 9/16/2012 8:55 PM, Bob Camp wrote: Hi The thing that makes the CFL's nasty for lab use are the cheap little switchers built into them. Conventional LED lights also have cheap little switchers in them. Doing them with a 30% efficient linear regulator gets you back to halogen type lumens per watt... Bob On Sep 16, 2012, at 8:09 PM, Tom Knox act...@hotmail.com wrote: In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy so I have started researching cost effective LED lighting and was amazed at what is available. On eBay there are 10 to 100 watt raw chips for $2-25.00 but that is equal to about 5 times the lumen of incandescent lighting. I was going to try building the heat sinks and supply into my existing bench fixtures. I will post more info soon. Thomas Knox ___ 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. ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1424 / Virus Database: 2437/5271 - Release Date: 09/16/12 ___ 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. ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
On 9/16/2012 8:09 PM, Tom Knox wrote: In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy Run 12 VDC lighting, or hydrocarbon (NG/propane/naptha, which is noisy in a different way. ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
12 volt Halogen from a big transformer run from a Variac if you want dimming. As long as the Variac brushes aren't arcing that setup will create zero noise. On 9/16/2012 9:55 PM, Mike S wrote: On 9/16/2012 8:09 PM, Tom Knox wrote: In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy Run 12 VDC lighting, or hydrocarbon (NG/propane/naptha, which is noisy in a different way. ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1424 / Virus Database: 2437/5271 - Release Date: 09/16/12 ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
If you dim the halogens, you will be operating them outside of the temperature required for the Halogen Cycle to operate. http://en.wikipedia.org/wiki/Halogen_lamp Shorter filament life and bulb darkening. That being said, I have a couple of halogen lights on dimmers and love them -- I like the quality of the light. DaveH -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Peter Gottlieb Sent: Sunday, September 16, 2012 19:26 To: time-nuts@febo.com Subject: Re: [time-nuts] Reducing lab noise with LED lighting. 12 volt Halogen from a big transformer run from a Variac if you want dimming. As long as the Variac brushes aren't arcing that setup will create zero noise. On 9/16/2012 9:55 PM, Mike S wrote: On 9/16/2012 8:09 PM, Tom Knox wrote: In this green era here in the USA there is a big push toward CFL lighting. Problem is I can see my CFL lighting on my PN measurements and other equipment. I am finding it is very noisy Run 12 VDC lighting, or hydrocarbon (NG/propane/naptha, which is noisy in a different way. ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1424 / Virus Database: 2437/5271 - Release Date: 09/16/12 ___ 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. ___ 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.
Re: [time-nuts] Reducing lab noise with LED lighting.
In message 9ae0e07a-568c-43d1-8cb6-0d0e21ee6...@rtty.us, Bob Camp writes: The thing that makes the CFL's nasty for lab use are the cheap little switchers built into them. Conventional LED lights also have cheap little switchers in them. Doing them with a 30% efficient linear regulator gets you back to halogen type lumens per watt... I run my led-lights directly off my 12V battery backed supply without any regulation, just find the right number of LEDS to connect in series for the maximum charge voltage, and live with a little less light in hold-over mode... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
