Re: [time-nuts] Help me make some sense of adev measurements of SR620'sown clock
David, Looking at the ADEV plot, I see the ripple that I expect from some oscillatory property. Looking at the phase, I see some of it, and picking it up in fityk (to view the phase info) I see a sawtooth like pattern, seeing typ around 4 cycles in 2000 s or so, which is typical of heating/AC type of behaviour. Hence, I may be looking at a temp-sensor. Shielding from temperature-variations can be tricky, as the SR620 produces a lot of heat. Putting thermal mass all around it (waterbottles) might be a fun experiment, but for most part, I think the performance you get is good and you should not be bothered with it. The ADEV measure you got that was higher had only one degree of freedom, so the confidence interval was very wide, so you should just ignore that. You should look at the oadev list instead. Cheers, Magnus On 01/25/2015 11:21 PM, Tom Van Baak wrote: http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip The format should be pretty self-explanatory. Note the counter sample Well done, nicely self-documenting. I then used Tom's "adev1" http://www.leapsecond.com/tools/adev1.htm http://www.leapsecond.com/tools/adev1.c to analyze the data. That will work, but adev5 is a more recent version that I now use instead. C:\tmp>skip 17 < ref-out-to-A-3.6m-cable-to-B.txt | fld 1 | adev5 /a 0 10 .5 ** log(tau) from 0 to 10 step 0.5, that is, tau from 1 to 1e+010 with 2 steps/decade 0. 1 a -11.997131 1.006628e-012 56163 0.5000 3 a -12.432202 3.696563e-013 56159 1. 10 a -12.818504 1.518784e-013 56145 1.5000 32 a -13.123597 7.523206e-014 56101 2. 100 a -13.370151 4.264311e-014 55965 2.5000 316 a -13.787569 1.630914e-014 55533 3.1000 a -14.280998 5.236028e-015 54165 3.50003162 a -14.694447 2.020940e-015 49841 4. 1 a -15.061822 8.673176e-016 36165 Better yet, use John's TimeLab, import with 'L' and see nice phase, frequency, adev, tdev plots within seconds. Here are the plots you will get: http://leapsecond.com/tmp/dave1-phase.gif http://leapsecond.com/tmp/dave1-freq.gif http://leapsecond.com/tmp/dave1-adev.gif http://leapsecond.com/tmp/dave1-tdev.gif http://leapsecond.com/tmp/dave1-tdev10.gif I'm puzzled about, is how to interpret this, and if interpretation is correct, my counter might not be in spec. Your interpretation is correct. You can also get TDEV numbers using adev5 /t The SR620 counter's display has resolution of 1 ps, and supposedly a 25 ps rms single short resolution. Would I be right in assuming that after 1 second (1000 samples), I would expect to see an adev of 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps? You're getting 1e-12 at 1 second. Sounds fine to me. Don't sweat the 10 vs 9 vs 8e-13 thing; the counter is working fine. The TDEV gets down to 4e-13 at 4 seconds if you want nice numbers. You're partly limited by 1 ps LSDigit quantization as well. Also, why would the adev rise at 2 tau, when this is only measuring the time between its own reference, and a version delayed by about 17.5 ns due to a few metres of cable? But maybe there's not really enough data at 2 seconds. There are many things hidden inside the word "measuring itself". Internal and external enviromental effects will start to play a role in this time frame. Also, when you plot phase with TimeLab you'll notice a jump around T+23600 seconds. This is likely you breathing near the instrument, or touching a cable, or closing a door. We're talking ps here, so you can't even look at it while it's running. Do most people save time information as I have done there, or phase information? I'm guessing the two are easily related, but I'm wondering what will work with most peoples software. What I like about Tom's is it compiles easily on my Unix box, without me having to use Windows. But I note some of Tom's software wants phase, and the other time. Always save phase. Not sure what you mean by time. Even better is to save both phase and elapsed time or real time; the latter can be used as a check that your sample rates are what you expect. Personally, I prefix every ascii line received with a MJD timestamp. That way all my log files, everything from counters to temperature sensors to GPS NMEA lines can all be correlated against themselves and with other people. Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year format) Always use leading zeros for hours, minutes, and seconds. The preferred way to write this is simply 2015-01-24 23:02:55 (see ISO 8601). /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.co
Re: [time-nuts] Questions regarding tuning Thunderbolt with Lady Heather --> GPSDO's
Hi > On Jan 25, 2015, at 10:59 AM, Didier Juges wrote: > > "This operation is very typical of all of the cell site GPSDO’s. The only > part that is unique to the TBolt is the ability to fiddle the loop > characteristics a bit." > > And the fact that the GPS's CPU clock is derived from the 10MHz and > therefore aligned to the PPS so there is no hanging bridge and sawtooth > correction is not required. > > I am not aware of any other GPSDO implementing that scheme, which is very > elegant in its simplicity. It is indeed an elegant solution. Based on looking at 1 pps outputs on a group of them over a year or more, It’s actual impact on the control loop function is pretty minor compared to a properly executed sawtooth correction process. It would have a significant advantage if compared to a GPSDO that does not use sawtooth correction. Bob > > Didier KO4BB > > > On Sat, Jan 24, 2015 at 8:18 AM, Bob Camp wrote: > >> Hi >> >> Maybe a bit more information, much of it applies to all GPSDO’s : >> >> The TBolt first goes through a process to get the OCXO roughly on >> frequency and to get the PPS approximately aligned. That process is not >> impacted by the time constant and damping. The OCXO goes a bit crazy during >> this process. >> >> It then starts the phase lock process with a short time constant. As the >> OCXO settles in, it will step out to a progressively longer time constant. >> It does this based on it’s internal estimates of lock quality. Unless you >> are already at maximum time constant and have a good internal estimate, >> changing the time constant has no immediate impact. On most GPSDO’s and >> with most OCXO’s under most conditions, the step out process takes days or >> weeks. >> >> The damping number does impact the performance in the maximum time >> constant mode. It may be scaled as the time constant is changed. >> >> There does appear to be a D in the TBolt loop. For what ever reason, >> that’s not a changeable value. The D does scale with the time constant. >> >> When in lock mode, the TBolt is a PLL and not a FLL. As the “phase in” >> (the pps from the gps) moves, the frequency of the OCXO will change to keep >> the “phase out” (PPS output) aligned. As the unit is running, it keeps >> track of the average DAC value that puts the OCXO on frequency. Since it’s >> a PLL, that number may or may not be the last instantaneous value of the >> DAC when it goes into holdover. Since it’s running a PLL, the PPS output >> will indeed be the best value, so no correction is needed there when it >> goes into holdover (not quite true, but that is the assumption made). >> >> This operation is very typical of all of the cell site GPSDO’s. The only >> part that is unique to the TBolt is the ability to fiddle the loop >> characteristics a bit. >> >> Bob >> >>> On Jan 23, 2015, at 10:58 PM, Skip Withrow >> wrote: >>> >>> Hello Nuts, >>> I have been playing a bit tuning a Thunderbolt with Lady Heather and now >>> have more questions than answers. The collective time-nut brain would be >>> appreciated. >>> >>> 1. Using the '&' command I can change the damping and time constant in >> LH. >>> Are these values immediately transferred to the TB? >>> >>> 2. Do I have to use the LH 'e' command to permenantly save new damping >> and >>> time constant values to the TB? >>> >>> 3. After using the '&' and 'e' command the lock-in behaviour of the TB >> does >>> not seem to change. Is this normal behaviour? Is one set of values used >>> when locking and the adjusted values used once it is phase locked? >>> >>> 4.Is there some way to read out the values stored in the TB? When I use >>> the 'e' command on the TB, change values in LH, then restart LH and the >> TB >>> I see the last values given to LH, and not what I thought was saved with >>> the 'e' command. >>> >>> 5. If the TB is placed in hold mode and the DAC set to 0.0 volts it >>> actually goes to 0.2 volts (min is at -5, max is at +5, and iv is 0.0 >> which >>> it actually starts at on power up). Anyone know why? >>> >>> Thanks in advance for any guidance! >>> Regards, >>> Skip Withrow >>> ___ >>> 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 inst
Re: [time-nuts] LTE Lite time error
Hi Paul, Odd, my LTE-Lite appears spot on. Let's take this off-list and see what's going on. If anyone else has been logging SkyTraq NMEA or binary from the LTE-Lite let us know. Thanks, /tvb $SkyTraq,Venus8 $Kernel,v2.0.2,1C92,1426,6005,I,16.367667MHz $ver,010827,rev,130221 - Original Message - From: "Paul" To: "Discussion of precise time and frequency measurement" Sent: Friday, January 23, 2015 8:58 PM Subject: [time-nuts] LTE Lite time error > I see a one second error in the NMEA string from my LTE Lite. > It lost a second between 23:33:34 and 23:33:42 21-Jan-2015 UTC. > I happened to check because a report of a one second error in some NTP pool > servers. > > Just a heads up -- I'll be following up with JL directly. > > -- > Paul ___ 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] D term (was no subject)
I second Poul-Henning Kamp's comments concerning D-terms, (mostly) as done in the TBolt and likely other GPSDOs. A 'D-term' helps fast loops like a TPLL where you want a high bandwidth with the P gain as high as possible. For slow noisy loops like a cleanup osc or a GPSDO, what helps is a pre-filter. A D-term and a pre-filter do the opposite of each other and are therefore generally not used together because they tend to cancel each other. The Tbolt control loop has neither! What it does is: The P-gain in the Tbolt is set by the time-constant (& EFC-Gain) which sets the freq error recovery time constant. The Integrator gain is set with the Damping, which controls the Phase error recovery time-constant. If the damping is set high >> 10, the TBolt's loop becomes a P only controller, AKA a Freq-Lock-Loop (FLL) instead of a PLL. That is with a very high damping setting, The Tbolt then corrects for any freq error offsets but does not correct for any phase errors. The Tbolt is indeed very flexible, allowing usable time-constant settings from 1 sec to days in either a PLL or FLL mode. What it is missing is a pre-filter, and to get the best performance that must be added externally. ws * I have seen no evidence that the Thunderbolt, in particular, uses a D term. ... Charles Before anybody gets any ideas that causes them to waste a lot of time: D terms are themselves very temperamental because they, by definition, amplify measurement jitter noise. In the precision time/frequency domain, D-terms are almost never realistic. Poul-Henning Kamp * Without a D term, PI loops can be unstable when the gain (P) is increased. If you will, with a large error, the correction will itself be large and as the system corrects itself, it may overshoot the target value, going into a low (or high if you really blew it) level oscillation around the target value. The D term slows it down just enough and minimizes that overshoot while maintaining a high gain (low steady state error) and a fast response. Didier KO4BB On January 24, 2015 8:05:38 PM CST, Bob Camp wrote: Hi A classic control loop in it's simplest form has only one term. That is often referred to as a proportional term. When the control signal (or error) changes by A the output changes by A times that term. Often in shorthand notation this term is refereed to as a P term. The next thing that some people add to a control loop is an integrator. It looks at the control signal (or error) has a constant offset of A, the integrator sums up the A's. The output of an integrator would eventually go to infinity with a constant control input (or error) into it. This term is often referred to as an I term. Lastly people add a term to the control loop that responds to the rate of change in the control signal (or error). The faster the change, the bigger this signal gets. This is commonly refereed to as a Derivative term. In shorthand it's talked about as the D term. The net result is a three element control loop running what's called a PID algorithm . The P and I can also be described by a time constant and a damping. That's what the Trimble software lets you do. The implication is that it's just a PI loop. In fact it appears to be a PID loop and you can't get at the D term. For a much more clearly worded explanation of all this, there's http://en.wikipedia.org/wiki/PID_controller >... There does appear to be a D in the TBolt loop. For what ever reason, that's not a changeable value. The D does scale with the time constant. . 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.
Re: [time-nuts] Help me make some sense of adev measurements of SR620'sown clock
> http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip > > The format should be pretty self-explanatory. Note the counter sample Well done, nicely self-documenting. > I then used Tom's "adev1" > > http://www.leapsecond.com/tools/adev1.htm > http://www.leapsecond.com/tools/adev1.c > > to analyze the data. That will work, but adev5 is a more recent version that I now use instead. C:\tmp>skip 17 < ref-out-to-A-3.6m-cable-to-B.txt | fld 1 | adev5 /a 0 10 .5 ** log(tau) from 0 to 10 step 0.5, that is, tau from 1 to 1e+010 with 2 steps/decade 0. 1 a -11.997131 1.006628e-012 56163 0.5000 3 a -12.432202 3.696563e-013 56159 1. 10 a -12.818504 1.518784e-013 56145 1.5000 32 a -13.123597 7.523206e-014 56101 2. 100 a -13.370151 4.264311e-014 55965 2.5000 316 a -13.787569 1.630914e-014 55533 3.1000 a -14.280998 5.236028e-015 54165 3.50003162 a -14.694447 2.020940e-015 49841 4. 1 a -15.061822 8.673176e-016 36165 Better yet, use John's TimeLab, import with 'L' and see nice phase, frequency, adev, tdev plots within seconds. Here are the plots you will get: http://leapsecond.com/tmp/dave1-phase.gif http://leapsecond.com/tmp/dave1-freq.gif http://leapsecond.com/tmp/dave1-adev.gif http://leapsecond.com/tmp/dave1-tdev.gif http://leapsecond.com/tmp/dave1-tdev10.gif > I'm puzzled about, is how to interpret this, and if interpretation is > correct, my counter might not be in spec. Your interpretation is correct. You can also get TDEV numbers using adev5 /t > The SR620 counter's display has resolution of 1 ps, and supposedly a > 25 ps rms single short resolution. Would I be right in assuming that > after 1 second (1000 samples), I would expect to see an adev of > 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the > 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps? You're getting 1e-12 at 1 second. Sounds fine to me. Don't sweat the 10 vs 9 vs 8e-13 thing; the counter is working fine. The TDEV gets down to 4e-13 at 4 seconds if you want nice numbers. You're partly limited by 1 ps LSDigit quantization as well. > Also, why would the adev rise at 2 tau, when this is only > measuring the time between its own reference, and a version delayed by > about 17.5 ns due to a few metres of cable? But maybe there's not > really enough data at 2 seconds. There are many things hidden inside the word "measuring itself". Internal and external enviromental effects will start to play a role in this time frame. Also, when you plot phase with TimeLab you'll notice a jump around T+23600 seconds. This is likely you breathing near the instrument, or touching a cable, or closing a door. We're talking ps here, so you can't even look at it while it's running. > Do most people save time information as I have done there, or phase > information? I'm guessing the two are easily related, but I'm > wondering what will work with most peoples software. What I like about > Tom's is it compiles easily on my Unix box, without me having to use > Windows. But I note some of Tom's software wants phase, and the other > time. Always save phase. Not sure what you mean by time. Even better is to save both phase and elapsed time or real time; the latter can be used as a check that your sample rates are what you expect. Personally, I prefix every ascii line received with a MJD timestamp. That way all my log files, everything from counters to temperature sensors to GPS NMEA lines can all be correlated against themselves and with other people. > Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year format) Always use leading zeros for hours, minutes, and seconds. The preferred way to write this is simply 2015-01-24 23:02:55 (see ISO 8601). /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] Help me make some sense of adev measurements of SR620's own clock
HI If you want to check your counter, simply look at the standard deviation of the readings you are getting. When I put them in to Excel here, they come up at 6.944 ps. That’s well within the counter’s specs. It’s not at all uncommon with the SR620 to get “to good to be true” readings using the internal standard. The reason is that the noise on the standard cancels out to some degree when you use it as your test source. To get a more realistic number, feed it with a 10 MHz source that is not the same as it’s internal reference. Bob > On Jan 25, 2015, at 10:43 AM, Dr. David Kirkby (Kirkby Microwave Ltd) > wrote: > > After sorting out some GPIB issues, I finally got to be able to make > some measurements on my Stanford Research SR620 time-interval counter. > I thought it sensible to first try to determine the performance of the > counter, which is using its own high stability clock (option 001). So > no external reference, such as one derived from GPS, is used. > > I took the 10 MHz reference output from the SR620 via a cable about > 0.5 m to the A input of the counter, which also had a BNC T on the > counter. From the A input to the B input is a cable about 3.6 m long > (longer than I would have liked with hindsight). I then measured the > time-interval every second for 55488 seconds - it is actually still > collecting data. The data file is here. > > http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip > > The format should be pretty self-explanatory. Note the counter sample > size is 1000, so it takes 1 sec. Note A is an high impedance input, > and B 50 Ohms, which seems a logical choice if tapping off a bit from > a 50 Ohm cable for the A input. > > # Data collected with ./tic version 0.01 > # GPIB address 17 on host 'buzzard' > # Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year > format) > # Instrument settings are as follows: > # Sample size: 1E3 > # Trigger level (external): -0.21 V > # Trigger level (A): -0.01 V > # Trigger level (B): -0.01 V > # Coupling (A): AC > # Coupling (B): AC > # Termination (external): 100 Ohm > # Termination (A): 100 Ohm > # Termination (B): 50 Ohm > # Mode = Time > # Column 1 is the time from the SR620 in seconds > # Column 2 is a hash(#) character, used to denote a comment > # Column 3 is the delay in seconds since data was first collected > 1.7540E-8 # 0.00 s > 1.7538E-8 # 0.988158 s > 1.7538E-8 # 1.976571 s > 1.7538E-8 # 2.964327 s > > The times recorded, about 17.5 ns, are consistent with what one would > expect with a cable about the length I have. > > I then used Tom's "adev1" > > http://www.leapsecond.com/tools/adev1.htm > http://www.leapsecond.com/tools/adev1.c > > to analyze the data. > > drkirkby@buzzard:/tmp$ adev1 1 < ref-out-to-A-3.6m-cable-to-B.txt > > ** Sampling period: 1 s > ** Phase data scale factor: 1.000e+00 > ** Total phase samples: 56165 > ** Normal and Overlapping Allan deviation: > > 1 tau, 1.0066e-12 adev(n=56163), 1.0066e-12 oadev(n=56163) > 2 tau, 5.2611e-13 adev(n=28081), 5.2820e-13 oadev(n=56161) > 5 tau, 2.4461e-13 adev(n=11231), 2.4397e-13 oadev(n=56155) > 10 tau, 1.5235e-13 adev(n=5615), 1.5188e-13 oadev(n=56145) > 20 tau, 9.8477e-14 adev(n=2807), 9.9323e-14 oadev(n=56125) > 50 tau, 5.7764e-14 adev(n=1122), 5.9520e-14 oadev(n=56065) > 100 tau, 4.1609e-14 adev(n=560), 4.2643e-14 oadev(n=55965) > 200 tau, 2.7712e-14 adev(n=279), 2.8362e-14 oadev(n=55765) > 500 tau, 8.1848e-15 adev(n=111), 9.3519e-15 oadev(n=55165) >1000 tau, 4.9553e-15 adev(n=55),5.2360e-15 oadev(n=54165) >2000 tau, 3.3500e-15 adev(n=27),3.0661e-15 oadev(n=52165) >5000 tau, 1.8873e-15 adev(n=10),1.4325e-15 oadev(n=46165) > 1 tau, 8.6819e-16 adev(n=4), 8.6732e-16 oadev(n=36165) > 2 tau, 1.4849e-15 adev(n=1), 6.3165e-16 oadev(n=16165) > > I'm puzzled about, is how to interpret this, and if interpretation is > correct, my counter might not be in spec. > > I thought from reading Wikipedia and > > en.wikipedia.org/wiki/Allan_variance > > that at 1 tau, the Allen Deviation represents the RMS deviation > between two observations 1 second apart. So that is 1.0066 ps. > > The SR620 counter's display has resolution of 1 ps, and supposedly a > 25 ps rms single short resolution. Would I be right in assuming that > after 1 second (1000 samples), I would expect to see an adev of > 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the > 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps? I've > run Autocal on this counter, and put the oscillator on frequency with > one of the calbytes, but have not done any other adjustments. Needless > to say its an eBay purchase, and I doubt has been near a cal lab in > years. > > Again based on a 25 ps rms resolution, would I expect after 500 > seconds (50,000 counts), to see an adev
Re: [time-nuts] GPS leap second pending (Fury/Z38XX)
Hi Hans, Actually, it is quite common to name the leap second by the July / January date instead of the June / December date. As you read papers on the web, use automated leap second services, or interact with instruments be prepared for both styles. As an example, note that the most official of all leap second web pages is IERS announcement itself: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat Here they use both "UTC TIME STEP on the 1st of July 2015" and "A positive leap second will be introduced at the end of June 2015". Here are several more highly reputable examples, all of which use "July 1" instead of "June 30". http://maia.usno.navy.mil/ser7/tai-utc.dat https://www.eecis.udel.edu/~mills/leap.html http://hpiers.obspm.fr/eop-pc/index.php?index=UTC-offsets_tab http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab NIST, on the other hand, uses the more familiar June/December format here: http://www.nist.gov/pml/div688/grp50/leapsecond.cfm And of course there are many more examples everywhere. Just accept either format; they mean the same thing. Here are some personal thoughts on the use of 1 July instead of 30 June: 1) For most of the world's population the leap second happens in July, local time. 2) Using the words "adding a second" incorrectly favors positive leap seconds over negative leap seconds. Labeling a leap second as 23:59:60 (at the end of June) does not translate for negative leap seconds (are you going to call them 23:59:58? or 23:59:59?). In fact, there is no convenient label for a negative leap second. Note HP cleverly uses 59, 60, 61 to distinguish the three types of minutes at the end of a month. 3) Ideally any leap second table should make it clear if the leap is positive or negative, and treat both equally fair. There is no need to use the words positive/negative, or insert/delete, or +1/-1 if the table includes the TAI-UTC offset. Because of this, the most succinct tables are those that use the July/January style instead of June/December. 4) You don't even have to remember how many days June has if you use the July 1 style. ;-) 5) In computer code using a July 1 (or MJD equivalent) comparison date means you don't have to worry if the leap second was positive or negative and having special cases for 23:59:58/00:00:00 and 23:59:60/00:00:00. And while I'm at it, here's a few reminders: 1) As currently defined, leap seconds are only ever applied at the end of a month. 2) In general, it can be *any* of the 12 months. That is, never hard-code June or December, or March or September into any document or program or data table. As the rotation rate continues to drift over decades and centuries there will be a need to activate the 4 slots a year or 12 slots a year rather than just the current 2 slots. 3) That's why use of the word "pending" can be confusing. Some use "pending" to describe only the month in which the leap second occurs avoids this ambiguity. Maybe use "announcement" when you know which month the leap second is pending. Maybe best to specify the leap date and not use words at all. 4) Lastly, although everyone talks about the "earth slowing down" this is not really why we have leap seconds. Since 1972 leap seconds have been needed because the earth is slow (vs. atomic clocks). Note "slow" (frequency) and "slowing" (frequency drift) are very different. 5) In fact, if you look at plots of earth rotation rates, the general trend over hundreds or thousands of years is a slow down of rate, but the general trend for the past 40 years is clearly a speed up of rate. As a result I predict the earth second will be back on track by 2020 to 2025, and if that continues, we will have our first negative leap second before 2030. See http://leapsecond.com/pages/lod/earth-lod-10.gif which I need to update from last year, but you get the idea. /tvb - Original Message - From: "Hans Holzach" To: Sent: Sunday, January 25, 2015 8:03 AM Subject: Re: [time-nuts] GPS leap second pending (Fury/Z38XX) > true, this depends on the definition of "pending". however, i found it a > bit odd that the software reports a scheduled (but not pending this > month) leap second on july 1st. it's june 30 that is 86401 seconds long, > not the day after. in my opinion there is nothing between june 30 and > july 1 that lasts 1 second. > > but in the meantime it dawned on me that maybe the leap second date > respects my time zone (CET; UTC + 1). and indeed, as soon as i change > ptim:tzone from 1 to 0, the reported leap second date is june 30! ___ 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] GPS leap second pending (Fury/Z38XX)
Hans, For POSIX type clocks, 1 July 2015 will have two seconds denoted 00:00:00, but for real UTC clocks it will be 30 June that has 23:59:59 and 23:59:60. You will be at UTC+2h since it will be summer-time. Cheers, Magnus On 01/25/2015 05:03 PM, Hans Holzach wrote: true, this depends on the definition of "pending". however, i found it a bit odd that the software reports a scheduled (but not pending this month) leap second on july 1st. it's june 30 that is 86401 seconds long, not the day after. in my opinion there is nothing between june 30 and july 1 that lasts 1 second. but in the meantime it dawned on me that maybe the leap second date respects my time zone (CET; UTC + 1). and indeed, as soon as i change ptim:tzone from 1 to 0, the reported leap second date is june 30! hans Well, Said can tell us for sure (since he owns the firmware in the Fury) but you could call this is correct, because: 1) a leap second is not pending this month 2) the current leap second count is still 16 3) the next leap second happen between 2015-06-30 and 2015-07-01 4) the current month ends with a 60 second minute Check again after June 1st. /tvb (i5s) > On Jan 25, 2015, at 3:54 AM, Hans Holzach wrote: > > my jackson labs fury (1.22) reports: > > leapsecond pending: 0 > leapsecond accumulated: 16 > leapsecond date: 2015,7,1 > leapsecond duration: 60 > > strange... > > hans ___ 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] (no subject)
Typically a PLL loop uses a PI loop-filter, making it a PI-control system with a steered integrator in the form of the oscillator. Many other control systems prefer to use the PID controller I have seen no evidence that the Thunderbolt, in particular, uses a D term. Nor have I seen any evidence that it steps the PLL loop parameters during startup. It *is* capable of "jam setting" the oscillator phase (allowing cycle slips to reset the phase error within +/- 50 nS), which can speed up the lock time considerably. I thought it was supposed to do this automatically if you turn jam setting ON and set a phase error limit, but I have never seen one jam the phase without sending it a manual jam command, even with jamming ON and a phase error limit set. If anyone has managed to get a Tbolt to jam the oscillator phase automatically on startup, I'd be interested to know how. Best regards, Charles ___ 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] GPS leap second pending (Fury/Z38XX)
I agree, it looks kinda OK, even if a bit of unconventional format. Would be interesting to hear the motivation for not listing it at the last of June. Cheers, Magnus On 01/25/2015 03:59 PM, Tom Van Baak wrote: Well, Said can tell us for sure (since he owns the firmware in the Fury) but you could call this is correct, because: 1) a leap second is not pending this month 2) the current leap second count is still 16 3) the next leap second happen between 2015-06-30 and 2015-07-01 4) the current month ends with a 60 second minute Check again after June 1st. /tvb (i5s) On Jan 25, 2015, at 3:54 AM, Hans Holzach wrote: my jackson labs fury (1.22) reports: leapsecond pending: 0 leapsecond accumulated: 16 leapsecond date: 2015,7,1 leapsecond duration: 60 strange... hans ___ 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] question Alan deviation measured with Timelab and counters
Hi The approach in the original NIST paper below was sort of a “best guess” about how to do the limiting and filtering. When the paper was presented, a number of us questioned how that part of the circuit was arrived at. The conversation more or less ended up with “that’s something we can investigate further”. The Collins paper (and Bruce’s work based on it) is a much better way to look at the 10 Hz squaring process. At 10 MHz, that stuff is not needed. Bob > On Jan 25, 2015, at 10:44 AM, Stéphane Rey wrote: > > Hi everyone. > > Many thanks for your very useful comments. > I had already seen most of the documents you were pointing but not on the > collins and Bruce discussion around the multistage filter. However I've > already seen this approach in the document from Allan > (http://tf.nist.gov/timefreq/general/pdf/84.pdf) > > At first I had in mind to square the 10 MHz but this is the aim of the > evaluation board to evaluate various architectures. So I will implement > several squarers including the Collins Approach both at 10 MHz and 100 Hz > and all the blocks will have input and output connectors so that I will be > able to test several layouts. > > I will show you the final design. > > Cheers > Stephane > > > -Message d'origine- > De : time-nuts [mailto:time-nuts-boun...@febo.com] De la part de Charles > Steinmetz > Envoyé : dimanche 25 janvier 2015 08:08 > À : Discussion of precise time and frequency measurement > Objet : Re: [time-nuts] question Alan deviation measured with Timelab and > counters > > Stephane wrote: > >> I'm now trying to evaluate various architectures of 2-channels squarers >> and a DMDT. For that I'm designing a PCB with 4 squarers : >> simple 74ac04 gate biased at VCC/2, a LT1016 comparator, the transistor >> based differential amplifier from Winzel and the one from Charles. > > Note that squaring a 10MHz sine wave and squaring a 10 or 100Hz mixer output > are two very different tasks. If you start at baseband, a Collins-style > multi-stage limiting amp is a great benefit. That is generally not > necessary if you start at 10MHz (or if you do use a Collins-style limiter it > needs far fewer stages). All of the squarers you mention work well at > 10MHz, but not as well at baseband. > > The LT1719 is easier to apply and faster than the LT1016. You may want to > use that instead of the 1016. The LT1719 and LT1715 datasheets show the > simplest possible implementation (see below). > > The MPSH81 devices in my version are available in surface-mount > (MMBTH81) if that is more convenient. Other fast transistors will also work > (BFT92, BFT93, BFG31). > > Best regards, > > Charles > > > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le > logiciel antivirus Avast. > http://www.avast.com > > ___ > 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] (no subject)
In message , Didier Juges write s: >Without a D term, PI loops can be unstable when the gain (P) is >increased. If you will, with a large error, the correction will >itself be large and as the system corrects itself, it may overshoot >the target value, going into a low (or high if you really blew it) >level oscillation around the target value. The D term slows it >down just enough and minimizes that overshoot while maintaining a >high gain (low steady state error) and a fast response. Before anybody gets any ideas that causes them to waste a lot of time: D terms are themselves very temperamental because they, by definition, amplify measurement jitter noise. In the precision time/frequency domain, D-terms are almost never realiastic. -- 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] Help me make some sense of adev measurements of SR620's own clock
After sorting out some GPIB issues, I finally got to be able to make some measurements on my Stanford Research SR620 time-interval counter. I thought it sensible to first try to determine the performance of the counter, which is using its own high stability clock (option 001). So no external reference, such as one derived from GPS, is used. I took the 10 MHz reference output from the SR620 via a cable about 0.5 m to the A input of the counter, which also had a BNC T on the counter. From the A input to the B input is a cable about 3.6 m long (longer than I would have liked with hindsight). I then measured the time-interval every second for 55488 seconds - it is actually still collecting data. The data file is here. http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip The format should be pretty self-explanatory. Note the counter sample size is 1000, so it takes 1 sec. Note A is an high impedance input, and B 50 Ohms, which seems a logical choice if tapping off a bit from a 50 Ohm cable for the A input. # Data collected with ./tic version 0.01 # GPIB address 17 on host 'buzzard' # Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year format) # Instrument settings are as follows: # Sample size: 1E3 # Trigger level (external): -0.21 V # Trigger level (A): -0.01 V # Trigger level (B): -0.01 V # Coupling (A): AC # Coupling (B): AC # Termination (external): 100 Ohm # Termination (A): 100 Ohm # Termination (B): 50 Ohm # Mode = Time # Column 1 is the time from the SR620 in seconds # Column 2 is a hash(#) character, used to denote a comment # Column 3 is the delay in seconds since data was first collected 1.7540E-8 # 0.00 s 1.7538E-8 # 0.988158 s 1.7538E-8 # 1.976571 s 1.7538E-8 # 2.964327 s The times recorded, about 17.5 ns, are consistent with what one would expect with a cable about the length I have. I then used Tom's "adev1" http://www.leapsecond.com/tools/adev1.htm http://www.leapsecond.com/tools/adev1.c to analyze the data. drkirkby@buzzard:/tmp$ adev1 1 < ref-out-to-A-3.6m-cable-to-B.txt ** Sampling period: 1 s ** Phase data scale factor: 1.000e+00 ** Total phase samples: 56165 ** Normal and Overlapping Allan deviation: 1 tau, 1.0066e-12 adev(n=56163), 1.0066e-12 oadev(n=56163) 2 tau, 5.2611e-13 adev(n=28081), 5.2820e-13 oadev(n=56161) 5 tau, 2.4461e-13 adev(n=11231), 2.4397e-13 oadev(n=56155) 10 tau, 1.5235e-13 adev(n=5615), 1.5188e-13 oadev(n=56145) 20 tau, 9.8477e-14 adev(n=2807), 9.9323e-14 oadev(n=56125) 50 tau, 5.7764e-14 adev(n=1122), 5.9520e-14 oadev(n=56065) 100 tau, 4.1609e-14 adev(n=560), 4.2643e-14 oadev(n=55965) 200 tau, 2.7712e-14 adev(n=279), 2.8362e-14 oadev(n=55765) 500 tau, 8.1848e-15 adev(n=111), 9.3519e-15 oadev(n=55165) 1000 tau, 4.9553e-15 adev(n=55),5.2360e-15 oadev(n=54165) 2000 tau, 3.3500e-15 adev(n=27),3.0661e-15 oadev(n=52165) 5000 tau, 1.8873e-15 adev(n=10),1.4325e-15 oadev(n=46165) 1 tau, 8.6819e-16 adev(n=4), 8.6732e-16 oadev(n=36165) 2 tau, 1.4849e-15 adev(n=1), 6.3165e-16 oadev(n=16165) I'm puzzled about, is how to interpret this, and if interpretation is correct, my counter might not be in spec. I thought from reading Wikipedia and en.wikipedia.org/wiki/Allan_variance that at 1 tau, the Allen Deviation represents the RMS deviation between two observations 1 second apart. So that is 1.0066 ps. The SR620 counter's display has resolution of 1 ps, and supposedly a 25 ps rms single short resolution. Would I be right in assuming that after 1 second (1000 samples), I would expect to see an adev of 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps? I've run Autocal on this counter, and put the oscillator on frequency with one of the calbytes, but have not done any other adjustments. Needless to say its an eBay purchase, and I doubt has been near a cal lab in years. Again based on a 25 ps rms resolution, would I expect after 500 seconds (50,000 counts), to see an adev of 25e-12/sqrt(5)=1.118 x 10^-13, rather than the 8.1848e-15 the data shows? Also, why would the adev rise at 2 tau, when this is only measuring the time between its own reference, and a version delayed by about 17.5 ns due to a few metres of cable? But maybe there's not really enough data at 2 seconds. Do most people save time information as I have done there, or phase information? I'm guessing the two are easily related, but I'm wondering what will work with most peoples software. What I like about Tom's is it compiles easily on my Unix box, without me having to use Windows. But I note some of Tom's software wants phase, and the other time. I'm still collecting data, so will at some point upload a larger file to http://www.kirkbymicrowave.co.uk/time-stuff/ with more data. I'll certainly
Re: [time-nuts] GPS leap second pending (Fury/Z38XX)
true, this depends on the definition of "pending". however, i found it a bit odd that the software reports a scheduled (but not pending this month) leap second on july 1st. it's june 30 that is 86401 seconds long, not the day after. in my opinion there is nothing between june 30 and july 1 that lasts 1 second. but in the meantime it dawned on me that maybe the leap second date respects my time zone (CET; UTC + 1). and indeed, as soon as i change ptim:tzone from 1 to 0, the reported leap second date is june 30! hans Well, Said can tell us for sure (since he owns the firmware in the Fury) but you could call this is correct, because: 1) a leap second is not pending this month 2) the current leap second count is still 16 3) the next leap second happen between 2015-06-30 and 2015-07-01 4) the current month ends with a 60 second minute Check again after June 1st. /tvb (i5s) > On Jan 25, 2015, at 3:54 AM, Hans Holzach wrote: > > my jackson labs fury (1.22) reports: > > leapsecond pending: 0 > leapsecond accumulated: 16 > leapsecond date: 2015,7,1 > leapsecond duration: 60 > > strange... > > hans ___ 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] Questions regarding tuning Thunderbolt with Lady Heather --> GPSDO's
"This operation is very typical of all of the cell site GPSDO’s. The only part that is unique to the TBolt is the ability to fiddle the loop characteristics a bit." And the fact that the GPS's CPU clock is derived from the 10MHz and therefore aligned to the PPS so there is no hanging bridge and sawtooth correction is not required. I am not aware of any other GPSDO implementing that scheme, which is very elegant in its simplicity. Didier KO4BB On Sat, Jan 24, 2015 at 8:18 AM, Bob Camp wrote: > Hi > > Maybe a bit more information, much of it applies to all GPSDO’s : > > The TBolt first goes through a process to get the OCXO roughly on > frequency and to get the PPS approximately aligned. That process is not > impacted by the time constant and damping. The OCXO goes a bit crazy during > this process. > > It then starts the phase lock process with a short time constant. As the > OCXO settles in, it will step out to a progressively longer time constant. > It does this based on it’s internal estimates of lock quality. Unless you > are already at maximum time constant and have a good internal estimate, > changing the time constant has no immediate impact. On most GPSDO’s and > with most OCXO’s under most conditions, the step out process takes days or > weeks. > > The damping number does impact the performance in the maximum time > constant mode. It may be scaled as the time constant is changed. > > There does appear to be a D in the TBolt loop. For what ever reason, > that’s not a changeable value. The D does scale with the time constant. > > When in lock mode, the TBolt is a PLL and not a FLL. As the “phase in” > (the pps from the gps) moves, the frequency of the OCXO will change to keep > the “phase out” (PPS output) aligned. As the unit is running, it keeps > track of the average DAC value that puts the OCXO on frequency. Since it’s > a PLL, that number may or may not be the last instantaneous value of the > DAC when it goes into holdover. Since it’s running a PLL, the PPS output > will indeed be the best value, so no correction is needed there when it > goes into holdover (not quite true, but that is the assumption made). > > This operation is very typical of all of the cell site GPSDO’s. The only > part that is unique to the TBolt is the ability to fiddle the loop > characteristics a bit. > > Bob > > > On Jan 23, 2015, at 10:58 PM, Skip Withrow > wrote: > > > > Hello Nuts, > > I have been playing a bit tuning a Thunderbolt with Lady Heather and now > > have more questions than answers. The collective time-nut brain would be > > appreciated. > > > > 1. Using the '&' command I can change the damping and time constant in > LH. > > Are these values immediately transferred to the TB? > > > > 2. Do I have to use the LH 'e' command to permenantly save new damping > and > > time constant values to the TB? > > > > 3. After using the '&' and 'e' command the lock-in behaviour of the TB > does > > not seem to change. Is this normal behaviour? Is one set of values used > > when locking and the adjusted values used once it is phase locked? > > > > 4.Is there some way to read out the values stored in the TB? When I use > > the 'e' command on the TB, change values in LH, then restart LH and the > TB > > I see the last values given to LH, and not what I thought was saved with > > the 'e' command. > > > > 5. If the TB is placed in hold mode and the DAC set to 0.0 volts it > > actually goes to 0.2 volts (min is at -5, max is at +5, and iv is 0.0 > which > > it actually starts at on power up). Anyone know why? > > > > Thanks in advance for any guidance! > > Regards, > > Skip Withrow > > ___ > > 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] question Alan deviation measured with Timelab and counters
Hi everyone. Many thanks for your very useful comments. I had already seen most of the documents you were pointing but not on the collins and Bruce discussion around the multistage filter. However I've already seen this approach in the document from Allan (http://tf.nist.gov/timefreq/general/pdf/84.pdf) At first I had in mind to square the 10 MHz but this is the aim of the evaluation board to evaluate various architectures. So I will implement several squarers including the Collins Approach both at 10 MHz and 100 Hz and all the blocks will have input and output connectors so that I will be able to test several layouts. I will show you the final design. Cheers Stephane -Message d'origine- De : time-nuts [mailto:time-nuts-boun...@febo.com] De la part de Charles Steinmetz Envoyé : dimanche 25 janvier 2015 08:08 À : Discussion of precise time and frequency measurement Objet : Re: [time-nuts] question Alan deviation measured with Timelab and counters Stephane wrote: >I'm now trying to evaluate various architectures of 2-channels squarers >and a DMDT. For that I'm designing a PCB with 4 squarers : >simple 74ac04 gate biased at VCC/2, a LT1016 comparator, the transistor >based differential amplifier from Winzel and the one from Charles. Note that squaring a 10MHz sine wave and squaring a 10 or 100Hz mixer output are two very different tasks. If you start at baseband, a Collins-style multi-stage limiting amp is a great benefit. That is generally not necessary if you start at 10MHz (or if you do use a Collins-style limiter it needs far fewer stages). All of the squarers you mention work well at 10MHz, but not as well at baseband. The LT1719 is easier to apply and faster than the LT1016. You may want to use that instead of the 1016. The LT1719 and LT1715 datasheets show the simplest possible implementation (see below). The MPSH81 devices in my version are available in surface-mount (MMBTH81) if that is more convenient. Other fast transistors will also work (BFT92, BFT93, BFG31). Best regards, Charles --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com ___ 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] (no subject)
Without a D term, PI loops can be unstable when the gain (P) is increased. If you will, with a large error, the correction will itself be large and as the system corrects itself, it may overshoot the target value, going into a low (or high if you really blew it) level oscillation around the target value. The D term slows it down just enough and minimizes that overshoot while maintaining a high gain (low steady state error) and a fast response. Didier KO4BB On January 24, 2015 8:05:38 PM CST, Bob Camp wrote: >Hi > >A classic control loop in it’s simplest form has only one term. That is >often referred to as a proportional term. When the control signal (or >error) changes by A the output changes by A times that term. Often in >shorthand notation this term is refereed to as a P term. > >The next thing that some people add to a control loop is an integrator. >It looks at the control signal (or error) has a constant offset of A, >the integrator sums up the A’s. The output of an integrator would >eventually go to infinity with a constant control input (or error) into >it. This term is often referred to as an I term. > >Lastly people add a term to the control loop that responds to the rate >of change in the control signal (or error). The faster the change, the >bigger this signal gets. This is commonly refereed to as a Derivative >term. In shorthand it’s talked about as the D term. > >The net result is a three element control loop running what’s called a >PID algorithm . > >The P and I can also be described by a time constant and a damping. >That’s what the Trimble software lets you do. The implication is that >it’s just a PI loop. In fact it appears to be a PID loop and you can’t >get at the D term. > >For a much more clearly worded explanation of all this, there’s > >http://en.wikipedia.org/wiki/PID_controller > >Bob > >> On Jan 24, 2015, at 6:35 PM, Cash Olsen >wrote: >> >> Bob, >> >> I am relatively new to the list and still learning the jargon and >> concepts. You wrote: "There does appear to be a D in the TBolt loop. >> For what ever reason, that’s not a changeable value. The D does scale >> with the time constant." >> >> Could you or one of the other members elaborate on the what is meant >> by "D" above. Does it have anything to do with a flat spot in the >> loop? >> >> -- >> S. Cash Olsen KD5SSJ >> ARRL Technical Specialist >> >> Message: 10 >> Date: Sat, 24 Jan 2015 09:18:15 -0500 >> From: Bob Camp >> To: Discussion of precise time and frequency measurement >> >> Subject: Re: [time-nuts] Questions regarding tuning Thunderbolt with >>LadyHeather --> GPSDO's >> Message-ID: <6581eb02-9792-432f-b143-25b41fb29...@n1k.org> >> Content-Type: text/plain; charset=utf-8 >> >> >> There does appear to be a D in the TBolt loop. For what ever reason, >> that’s not a changeable value. The D does scale with the time >> constant. >> ___ >> 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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ 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] GPS leap second pending (Fury/Z38XX)
Well, Said can tell us for sure (since he owns the firmware in the Fury) but you could call this is correct, because: 1) a leap second is not pending this month 2) the current leap second count is still 16 3) the next leap second happen between 2015-06-30 and 2015-07-01 4) the current month ends with a 60 second minute Check again after June 1st. /tvb (i5s) > On Jan 25, 2015, at 3:54 AM, Hans Holzach wrote: > > my jackson labs fury (1.22) reports: > > leapsecond pending: 0 > leapsecond accumulated: 16 > leapsecond date: 2015,7,1 > leapsecond duration: 60 > > strange... > > hans > ___ > 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] GPS leap second pending (Fury/Z38XX)
my jackson labs fury (1.22) reports: leapsecond pending: 0 leapsecond accumulated: 16 leapsecond date: 2015,7,1 leapsecond duration: 60 strange... hans ___ 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] question Alan deviation measured with Timelab and counters
Stephane wrote: I'm now trying to evaluate various architectures of 2-channels squarers and a DMDT. For that I'm designing a PCB with 4 squarers : simple 74ac04 gate biased at VCC/2, a LT1016 comparator, the transistor based differential amplifier from Winzel and the one from Charles. Note that squaring a 10MHz sine wave and squaring a 10 or 100Hz mixer output are two very different tasks. If you start at baseband, a Collins-style multi-stage limiting amp is a great benefit. That is generally not necessary if you start at 10MHz (or if you do use a Collins-style limiter it needs far fewer stages). All of the squarers you mention work well at 10MHz, but not as well at baseband. The LT1719 is easier to apply and faster than the LT1016. You may want to use that instead of the 1016. The LT1719 and LT1715 datasheets show the simplest possible implementation (see below). The MPSH81 devices in my version are available in surface-mount (MMBTH81) if that is more convenient. Other fast transistors will also work (BFT92, BFT93, BFG31). Best regards, Charles ___ 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.
