Re: [time-nuts] HP10811 dual oven
Mark Posted I laid out a through-hole version of Warren's board in Eagle and had OSHPARK fab up three of them. I sent one to Warren and am using the other two. The one mod I made was to use a single darlington TO-220 instead of the two transistor stage that Warren used. They seem to work quite well. I tested Mark's through-hole PC board Dual oven controller and it worked very well and was well laid out.**(see attached)** The only changes I made to Mark's PCB where: R1(Temperature Adj) ~ 35K and R4 = 1K Dan Kemppainen also laid out a nice looking, very small surface mount dual oven control board, but I was not able to test it. This outer oven controller is able to hold the inner oven's temperature to within 0.1C over normal room temperature variations, The effect is the HP10811's frequency change due to temperature variation (aka temp coeff) is reduced by more than 60 to 1, from 6e-11/C to under 1e-12 /C http://www.mail-archive.com/time-nuts%40febo.com/msg59680.html http://www.febo.com/pipermail/time-nuts/attachments/20100223/c94d5eec/attachment-0001.gif As has pointed out in response to the above nut posting, if the osc is already being disciplined at shorter time constants, then the improvement is not nearly as great, and may not be helpful. The big improvement is seen when the osc is in holdover or running open loop or running with a very long disciplined time constants 1000 seconds. The reason I designed the linear dual oven controller to run on 15V power is that unlike the standard HP10811, the dual oven 10811's inner oven can run at 15V, So a single 15 volt PS followed by a 12V regulator makes it a single supply design. Is a outer oven needed? Yes, but only if you are a freq nut. Note that adding an outer oven is generally easier to do than burying the osc in a pool of underground mercury or most of the other nut things that have been suggested in the past to reduce the effect of temperature variation. ws * ___ 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] ADEV with very short Tau
Claude what is the simplest method to measure sub second ADEV? The answer depends on many unstated things. Among them is your definition of simple, the Frequency of the DUT, the noise floor, your budget and your available time.. After budget and frequency, the next most important thing is the noise floor or resolution that you want. Many of sub second ADEV plots you see end up showing the limitations of the tester and not the DUT. One answer If you want meaningful ADEV numbers at 0.1 sec, it is best to sample at = 20 samples per second. I find sampling at line freq or its multiple has several advantages to allow good repeatable results for 0.1 sec ADEV. For North American that means a sample rate of 60 or 120Hz. If you want to test Time-nut type oscillators with ADEV's below 1e-11 then you will need something with sub Pico second resolution. Also measuring a frequency of 5 or 10 MHz, instead of measuring say a 20 pps divided down signal has many advantages. After defining the frequency and resolution you want, it comes down to what you mean by simple.. If you need to do it just once, find a Time-nuts that already has the right capability and is willing to measure it for you. If simples does not include budget get a TimePod. If simple includes low cost and you need a low noise floor, then you're going to have to consider some custom built thing. Who is doing the building, depends on how you value your time. ws ** Hello I know how to measure ADEV with frequency method (using a 53131A counter) or time difference method (using 1 PPS of a GPSDO for example) but I would like to measure ADEV in the sub-second domain (from 0.1s to 1s for example). Do I need a Time Interval Analyzer, if so, an HP 5371A is ok for that ? Or there are simpliest method ? Thanks for your advices. Claude ___ 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] Unique TBolt GPS characteristics
Stu Thanks for the great information feedback. No, No, the ~3e-12 is Not an error in the H/W. That would of course cause a constant phase drift error to accumulate. The Tbolt has no trouble holding 1e-12 control or even better than 1e-13 when using the extended time constant mode with an external osc. The error only appears in the Osc PPT offset output (sometimes), and as far as I know the only thing that it has any effect on is LadyHeather's osc-ptt readout. The Tbolt's internal control loop normally only uses phase error data, except maybe temporarily when both the phase and freq offset are being preset to near zeros when doing an initalizilation which happens when coming out of a long holdover. The osc ppt signal is made available for use in LadyHeather's undocumented external S/W control algorithm. ws * Subject: Re: [time-nuts] Unique TBolt GPS characteristics The Tbolt computes phase error by doing a position fix. It computes frequency error by doing a velocity fix. These two fixes use almost the same algorithm, a least-squares fit that incorporates the line-of-sight vectors to each satellite. The position fix starts with the pseudorange (distance) to each satellite, and computes X, Y, Z, and T. XYZ are the position vector from the center of the earth, and T is the clock bias (phase error). The velocity fix starts with the pseudorange-rate (aka Doppler) measurement for each satellite, and computes X-dot, Y-dot, Z-dot, and T-dot. XYZ-dot are the velocity vector of the receiver (usually zero for time-nuts), and T-dot is the clock rate (frequency error). Every GPS receiver has to measure Doppler on each signal as part of the tracking loop. Since the measurements are already there, computing velocity is just an extra math step. Most receivers do this. However, that doesn't help us in a PPS/TDC system, because the resulting frequency error measurement is a measurement of the GPS receiver's clock, not the OCXO we're trying to steer. The trick with the Tbolt is that the GPS receiver clock /is/ the OCXO we're trying to steer, so the frequency error measurement from each velocity fix applies directly to the OCXO. The error on each satellite Doppler measurement is typically a small number of cm / sec. Scale by the speed of light (3E10 cm / sec) to estimate instantaneous frequency measurement errors around 100 ppt. If N satellites contribute to the velocity fix, that should reduce the resultant error by sqrt(N) at each fix. That handwaving calculation agrees fairly well with the 25 ppt that you're seeing. Cheers! --Stu PS: Are you saying that the hardware 10 MHz output from a Tbolt is 3E-12 off compared to other GPSDO (or cesium, or whatever)? That's the first I've heard of that. Is the Tbolt low or high? I can imagine an explanation involving truncation in the carrier-phase NCO, or in the carrier feed-forward to the code tracking loop. But it would be hard to prove without detailed info on the guts of the Tbolt. Hey, if it's true, that's another way we could improve on a Tbolt. On Jan 27, 2015 9:32 PM, WS wrote: Stewart The part that I do not understand is how the TBolt is able to calculate such high resolution frequency offset answers for its Osc ppt output so fast. The frequency offset answers seem to have way too high of absolute accuracy compared to what is possible using the phase data. Example: It is not unusual for the raw 1 second phase data to have some 1 ns jumps in it due to GPS signal noise. If that phase data where used to calculate the frequency offset directly, it would cause some 1 ppb (1e-9) frequency jumps to occur. More interesting is that the frequency offset output and its polarity are not a function of the slope of the displayed phase noise when viewed over a time period of a few seconds. The peak one second frequency jumps on the osc-ppt output are more like 2.5e-11 ppt, that's 25ps per second of phase noise and this is using the GPS as the reference. Note that any frequency change of the 10 MHz oscillator is measured and fully settled and displayed in the next one second readout, accurate to within the limits of its noise. If the low noise stability of the delta frequency output was achieved by using multi phase points, then any external frequency change would take multiple seconds to fully respond, and the polarity of the frequency offset would be a function of the phase slope. One experiment I did was to compare my TBolt's PP freq noise errors on it's Phase output to the reported PPT Osc output. The phase error noise, short term over say most 10 second periods was around +- 1ns relative, and 10 ns absolute. The PPT-Osc output was providing 1e-11 peak frequency error, that's absolute not relative, when using LH's display filter set for 3 second. One way the TBolt may be doing this
Re: [time-nuts] Unique TBolt GPS characteristics
Stewart The part that I do not understand is how the TBolt is able to calculate such high resolution frequency offset answers on its Osc ppt output so fast. The frequency offset answers seem to have way too high of absolute accuracy compared to what is possible using the phase data. Example: It is not unusual for the raw 1 second phase data to have some 1 ns jumps in it due to GPS signal noise. If that phase data where used to calculate the frequency offset directly, it would cause some 1 ppb (1e-9) frequency jumps to occur. More interesting is that the frequency offset output and its polarity are not a function of the slope of the displayed phase noise when viewed over a time period of a few seconds. The peak one second frequency jumps on the osc-ppt output are more like 2.5e-11 ppt, that's 25ps per second of phase noise and this is using the GPS as the reference. Note that any frequency change of the 10 MHz oscillator is measured and fully settled and displayed in the next one second readout, accurate to within the limits of its noise. If the low noise stability of the delta frequency output was achieved by using multi phase points, then any external frequency change would take multiple seconds to fully respond, and the polarity of the frequency offset would be a function of the phase slope. One experiment I did was to compare my TBolt's PP freq noise errors on it's Phase output to the reported PPT Osc output. The phase error noise, short term over say most 10 second periods was around +- 1ns relative, and 10 ns absolute. The PPT-Osc output was providing 1e-11 peak frequency error, that's absolute not relative, when using LH's display filter set for 3 second. One way the TBolt may be doing this is by somehow averaging lots of high speed and very high resolution internal delta raw Phase data points, such as using a one plus KHz sample rate with sub ps resolution, possibly as some have suggested, with the use of some sort of additional carrier phase data. One of the tradeoffs/limitation of the TBolt's Osc-Freq output is that it typical has a ~3e-12 frequency offset error. If this was better understood, it should be useful in improving the TBolt GPSDO. This is likely because of another one of the unique TBolt characteristics, which is that it is possible to do an external S/W control algorithm with inputs from various multiple new sources such as WAAS, or remote TBolts using common view. The SwiftNav, even though a bit expensive for me, sounds like a interesting and powerful GPS engine with its cm 50Hz solution updates. I wonder how good of frequency resolution/accuracy vs. time it can do? ws Stewart Cobb posted: Every GPS receiver calculates its clock offset (phase error, in time-nut terms) as part of its four-dimensional position fix. It can apply almost the same math to calculate its clock rate (frequency error) as part of a four-dimensional velocity fix. In position hold mode, the Thunderbolt calculates its timing errors (both phase and frequency) using similar one-dimensional algorithms. The accuracy of these measurements is determined by all the factors that affect GPS, but the precision (resolution) of these measurements is effectively infinite, limited only by IEEE double-precision floating-point math. Almost every other GPSDO uses a hardware time-to-digital converter (TDC, interpolator, etc) to compare the OCXO timebase to the PPS output of a separate GPS receiver. The PPS/TDC scheme has four disadvantages relative to the Trimble scheme: A) The resolution of the phase error measurement is limited by the TDC hardware. For example, the HP Z38xx units appear to have 10ns resolution. B) The accuracy of the phase error measurement may be degraded by analog effects in the PPS connection. C) The phase error measurement must be compensated by a software sawtooth correction for best accuracy, because the PPS output is quantized by the receiver clock. D) Frequency error cannot be measured directly, but must be derived from successive phase measurements. The derivative process introduces noise, so the derived frequency error must be heavily filtered. Unfortunately, the Trimble scheme is only available to GPSDO builders who have access to the internal architecture of their GPS receiver. Historically, among the major players, only Trimble and perhaps Zyfer did. Even mighty HP did not. Fortunately, SwiftNav is now selling a (mostly) open-source GPS receiver. Only the FPGA correlator chip is closed-source, and that can be ignored for timing purposes. One would need to build a VCXO-based synthesizer to create the SwiftNav receiver clock frequency from a good OCXO, add a DAC to control the OCXO, and do some software work to add timing functions to the receiver firmware. Adding WAAS corrections to this hypothetical open-source GPSDO could make it noticeably more accurate than a Thunderbolt. Cheers! --Stu ___
[time-nuts] Unique TBolt GPS characteristics
Another unique thing about the TBolt engine is how fast it can calculate a Freq change in its 10MHz osc. Over short times periods, it can be 100 times better than a standard 1PPS GPS engine. It would be interesting to compare it to a high end dual freq GPS. With the Tbolt in manual hold over mode, and using Lady Heather for the readout, It takes less than 10 seconds, to measure the freq offset to well under 1e-11. Typically about 1e-11 freq error in 3 seconds When setup to use an external freq input, it makes a fast 11 plus digit, 10 MHz freq counter. The PPT output (osc Freq offset) of the Tbolt, responds to any freq changes in the next 1 sec output. How it does this is a mystery to me, because it is not using phase error. The limit is the noise which is very low. In a well set up Tbolt, the 1 second PPT freq noise is about 10ppt RMS (50e-12 PP). 5e-12 with 5sec filter, 3.5e-12 with 10 sec filter and 2.5e-12 with a 50 second filter. Attached is an old plot showing the noise floor difference between the TBolts phase and Freq outputs. The Uncertainty of a non-sawtooth corrected 1 sec GPS can be around 10 ns plus, with sawtooth correction that can go down to near 1ns uncertainty The GPS signal its self has up to a 10 ns uncertainly, so using the 1PPS signal out of a common GPS engine you get at best a 1e-8 to 1e-9 freq uncertainty using two readings 1 second apart. ws * 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 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 ** 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 ___ 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 kb8tq at n1k.org 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] Another use for a Trimble Thunderbolt
Authur wrote: Take a look at the plot where I adjust a rubidium standard and see what you think. I think it is a great idea, and shows that LadyHeather and a modified TBolt can make a great high end, stand alone Time-Nut tester without the need of a reference osc or offset osc, or any other special counters. (your plots show a great antenna and position setup, an important first step to get the low phase noise desired) To speed up the initial frequency tuning, what I've found helps is to set LadyHeather's display filter to around 100 sec, then the freq offset plot can be used to course tune the Rb's freq to under 1e-11 in just a few minutes. After the course freq adj, if you want better than that, the phase plot can be used to measure freq, tempco, and/or aging of any 10 MHz osc with better than 1e-13 / day resolution or 1e-14 using a week long test run. That should be useful for any time nut's Oscillator, even those with Cs and Hydrogen Masers. Attached is a 13 day lady Heather test plot of a LPRO Rb that I did a few years back using a Tbolt modified to use an external Osc. The plot shows a best case undisciplined drift rate of 20 ns change over 3.5 days, 6ns /day, which equals to a 0.67e-13 freq error during days 9-11, Then right after that at day 12, 5ns /hr for a freq error of ~1e-12. ws ** Date: Thu, 25 Dec 2014 20:11:23 -0500 From: Arthur Dent Subject: [time-nuts] Another use for a Trimble Thunderbolt ’d say that the plot is telling the truth. It also seems to be giving you information fast enough that thermal drift and barometric pressure is not to big an issue. If you had to wait a day or three for the same data, drift would be a much bigger issue. Yes, when you get to the “close enough” trace, drift may be an issue. (yes close enough is indeed close enough …). Keep in mind that I'm talking about using a GPS signal from a Thunderbolt to adjust a common rubidium standard that would be used in a telco or other piece of general test equipment and thermal drift and barometric pressure effects are never an issue for me. I suspect that if you try the trick with something way far off frequency (many 10’s of ppm), the GPS may not play nice. At any normal tune range on an Rb, it should be fine. Actually it does play nice-very nice over any range I'm interested in. Keep in mind that I wanted a simple method that would work with a 10 Mhz frequency standard to give me closer readings than I could get by watching the scope or the counter. I can easily use just the counter to check the frequency of a less than stellar oscillator so what I'm describing would be used with a fairly close 10 Mhz frequency standard and not one that isn't even close. The Pendulum CNT-81 frequency counter I have can display a 10 Mhz error to 5 decimal places in 10 seconds using the math function and an external time base. Anyone who has used a WWVB comparator remembers the plot zipping back to the zero position when the plotted frequency difference would exceed the chart's maximum deflection. The Thunderbolt's display on Lady Heather works exactly the same way. If you look at the plots in the link that follows you will see that the 10 Mhz appears very stable but it is actually set by a synthesizer to be 10,000,000.025000 hz in the upper trace and so to keep it in the vertical center position on the graph I have an oscillator offset of -2500 PPT in Lady Heather. In the lower trace the synthesizer frequency is set to 10,000,000.010 hz and the offset is -1000 PPT to keep the 10 Mhz trace centered. The reference for the synthesizer and the Thunderbolt is the GPS signal from the Tbolt so the same reference is used for everything. http://s906.photobucket.com/user/rjb1998/media/tboltplots_zpsd20a083b.jpg.html -Arthur On Dec 24, 2014, at 8:28 PM, Arthur Dent golgarfrinc...@gmail.com wrote: Those of you who know I had hacked the RFTG-u REF 1 GPS years ago and had one running for 4 years before other time nuts discovered these units probably won't be too surprised that I have tried another hack that may have limited interest but works for me. Having owned a large number of Thunderbolts, I ran across a few that needed repairs of various sorts. One of these had a defective oscillator so I removed the OXCO and brought the EFC and 10Mhz connections out through the side of the case with SMA connectors so I could test various oscillators, as others have done before. Then I got to thinking that if I connected the Thunderbolt up to run and output to Lady Heather but connected a free running oscillator to the 10Mhz input, ignoring the EFC connection, it might work as a comparator to plot the drift of the free running oscillator. I have a few Efratom/Datum Rubidium standards I'm adjusting and I can watch drift on my scope at 5 ns/cm or the 10 Mhz output to the 5th decimal place on my Pendulum CNT-81 counter and try to determine which way it's drifting but that gets old
Re: [time-nuts] Changing ADEV, (was Phase, One edge or two?)
Some of the reasons that ADEV values change over time may be caused by one of these two things that I have seen cause poor plots. Either of which can cause changes in the ADEV values across a wide range of taus, and the effect can change over long run ins. Hopefully Magnus will comment if ADEV is even an appropriate tool to use if either of these noise types are present in the raw data. The first thing that can cause trouble is if a bad data point occurs every so often, aka an outlier. The other thing is popcorn noise, a sudden frequency shift that tends to hop between a few different values and happens at an unpredictable time but at a somewhat repeatable rate. I've seen Popcorn noise change over long time periods after days or weeks of run in, say from a typical 1e-10 freq hop a few times a minute to maybe 2e-11 hops a couple times every 5 minutes. Even when this happened on some of my poor oscillators the basic short tau ADEV values between hops stayed pretty much constant. . If either of these somewhat repeatable but random events are included in the raw data, ADEV plots can become pretty misleading or downright useless. For that reason Plotter allows outliers to be removed automatically. As far as I know outliers have to be manually removed when using TimeLab. ws PS, and Yes the fact that I've posted this shows that I have to be at least somewhat crazy, aren't all time nuts in one way or another?. From: Bob Camp Subject: Re: [time-nuts] Changing ADEV, (was Phase, One edge or two?) Hi Grab an OCXO that has been powered off for a long time. Turn it on and start plotting ADEV. Do it from about 10 minutes after turn on. Run 15 to 30 minute tests every so often for the first few hours. Come back the next day and run the same series for a few hours. Repeat a week later, and a month later. Curve fit out the drift and run the ADEV numbers out to 100 seconds tau. That’s true even if you compare the best of each batch. It really is getting better. Do that on enough oscillators and you will indeed find many that do get better (like 2X better for some, 10 or 20% for others) on ADEV after they have been on a while. —— Run an OCXO and watch the ADEV on the Time Pod. Look at enough of them and you will find some that drop ADEV for a while (say 10 minutes or so) and then climb by a bit (say 1.5:1). Hmmm, what’s going on? Look at the phase plot and there’s an abrupt shift in phase over some period ( which depends on the cause, there’s more than one possibility). Let’s say it’s 10 seconds. The whole ADEV plot climbs, not just the part for 10 second tau. Why - there’s energy there both at short and long tau. —— Look at a GPSDO / disciplined oscillator / temperature compensated Rb. Let it run for a good long time. If it’s got a loop that steps out to *long* time constants, it may only bump the frequency once every 15 minutes or longer. Plot the ADEV over the time segment when it steps and compare it to the time period it does not step. Short tau ADEV is worse at the step. Look at a very normal OCXO on your TimePod. After 100 seconds, the 1 second ADEV *should* be pretty well determined. After 1000 seconds it should be *very* well determined. Flip on the error bars if you want an idea of how good it should be. Watch for a while, Does it move outside the error bars? H ….. It’s not the error bars that are the problem. The math is correct. The statistics are what is the issue. The ADEV hast changed for the worse as the run has gone on. It’s a very common thing. ——— Those are just the first few off the top of my head. Bob ** ADEV most certainly does change with time, even for short tau's. Can you elaborate? ___ 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] Changing ADEV, (was Phase, One edge or two?)
Bob Camp posted (Wed Oct 22 20:38:47 EDT 2014) Re: [time-nuts] Phase, One edge or two? ADEV most certainly does change with time, even for short tau's. Can you elaborate? Such as when, why, what kind of change, how much change, at how short of tau's, over how long of time, and using what type Oscillators? Do you know what in the freq or Phase plot is causing the ADEV to change? There all kinds of Oscillator things that change over time and/or need a lot of time to properly measure, but I was under the impression that this is not the case for short tau ADEV. Of the many OCXO type Oscillators that I've tested (HP10811 MV89), seldom have I seen any significant change (say greater than 10%), in the short tau (0.01 sec to 1 sec) ADEV values, after the systematic type errors are removed. (even when starting soon after turn on) ADEV is used to measure random types of noise so there are of course the statistical uncertainty variations that are a function of the number of valid data points. I find that using a minimum of a thousand points at each tau gives good consistent results. What I have seen when measuring the ADEV on time nut type Osc, is that it generally takes only a couple of minutes to get enough samples to reliability predict what the short term tau is when using a fast (120 sps), high resolution (0.1ps) tester. Trouble shooting hint: If the 0.1 sec to 10 second ADEV tau plot is not flat on a good time nut type undisciplined OXCO, then the first places to look for problems is in the tester, or the setup, or the procedure, not the oscillator. ws ___ 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] Phase, One edge or two? (was Digital mixing with a D Flip Flop)
Poul said; If you tell me it is a sine and give me the time of two zero crossings I can tell you everything there has or ever will be to know ... just to add a bit more nut picking on comment #3. When talking about sub picosecond per second time nut type accuracy, there is no such thing as a pure analog sinewave. so the answer becomes circular in that it takes more than two samples to tell exactly where the two zero crossing points are. Even if there was a near perfect sinewave with under -120 db of bad stuff, and the perfect sine to square wave converter with an exactally known time delay and no zero offset error, and a brick wall low pass cutoff, Given just two data points, it is going to be a real challenge to calculate everything such as Freq, Phase, amplitude, Johnson noise and bandwidth. Add in the typical harmonics, sub harmonics, freq spurs, cycle to cycle changes, cross talk, line noise, ADC resolution, etc, along with a less than perfect signal to noise ratio, and the number of samples needed to get a good enough answer is increased even further. Nyquist says it takes greater than two samples per cycle to be able to even tell if there is any higher freq content present. These are some of the reasons I believe when starting with a signal in the analog world, it helps to oversample, until you can get the data into the pure digital world where one time-stamped sample per cycle can then give you the signal's freq and phase. ws Poul-Henning Kamp Posted Just to pick a nit here: That depends precisely on what and how you measure. If you measure phase, then no, you probably don't need to measure more often than one phase difference per hour or even day, as long as you can reliably predict (from the frequency including noise) exactly how many periods were in that hour or day. This is basically what timelabs do: They measure against some radio signal (GPS, Two-Way, etc. etc.) every so often, trusting their stability between measurements. If you measure frequency, you MUST measure the frequency continously at all times without any deadtime between the measurements to get the precise result. The advantage is that you make *no* assumptions about the frequency or its stability at all. 3) Every instant on a sine wave is actually a data point, not just the zero crossing(s). So in reality there is near infinite information available. Sorry, but no. If you tell me it is a sine and give me the time of two zero crossings I can tell you everything there has or ever will be to know about any point on that sine-wave. Where looking at the whole curve makes sense is if it is not a sinewave, either because it is a complex signal (Loran's 3rd crossing) or because the sinewave is distorted in a way (ie: non-harmonic) which can be averaged out by looking at the entire curveform (locking onto a received radio signal.) But for pure sine signals or good approximations, measuring the zero crossing tells you all you can ever learn. ___ 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] Phase, One edge or two? (was Digital mixing with a D Flip Flop)
Lots of interesting responses, but I did not see any posted that answered the original question: Is the CERN method described in the paper the best way to make a state of the art femtosecond DDMDT? www.ee.ucl.ac.uk/lcs/previous/LCS2011/LCS1136.pdf Restating Assuming it is kept Digital, and not taken to the next level [analog], by sampling more of the 10MHz waveforms than just the zero crossings. If making a digital sampler type of tester to measure Femto second phase differences, Is there (and should there be) a strong preference for using one or two edges on either or both the ref and signal inputs? Whether the second edge helps or hurts in the other cases brought up, depends on where the signals come from and what they are being used for. One extreme is the typical GPS timing pulse output, where the second edge can not be used for timing. On the other hand if a square wave signal is coming from a clean, high freq signal that has been divide by N, then the second edge could have very useful and needed information, such as when applied to an XOR phase detector. additional consideration: Unlike a digital sampler which tend to use a single edge, most if not all high end phase measurers I know of averages the results at both edges of both signals. Also anything that depends on a DMTD mixer for its operation, such as single mixer, dual mixer, TPLL, they are all using at least both edges of the signals, and depending on the degree of overdrive, they may be using a lot more of signal that is near the zero crossing point. ws - Phase, One edge or two? (was Digital mixing with a D Flip Flop) Bob Camp posted Looking at both zero crossings would give you a lot of information about the duty cycle of the input waveforms. If that's what you are after - there are easier ways to do it. If that's not what you are after, it's just going to mess up the readings. --- Poul-Henning Kamp Posted; The only reason to look at both zero crossings would be to double the frequency of the input signal to the loop (ie: 2Hz from a 1PPS instead of a 1Hz), at the cost of adding a whole lot of noise in the process. Don't do it. ___ 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] Phase, One edge or two? (was Digital mixing with a D Flip Flop)
The recent discussions about the simple digital mixer got me thinking about the performance vs. complexity trade offs when measuring accurate, high resolution, phase drift differences between two oscillators. It would seem to me, that using both the positive and negative slope edges of the high freq sinewave signal is a better way to go. Is using just one edge, acceptable for a 'state of the art' Phase drift measurements? I am not suggesting the KISS approach is the wrong solution for Simon. I am questioning if the paper posted, is the best way for CERN to make a state of the art femtosecond DDMDT? Here is an extreme example of throwing away useful data for the sake of simplicity: When measuring phase drift of a 10 MHz osc using just a 1PPS signal, 19,999,999 other possible data points are being discarded. Using all possible data points could decrease the noise floor considerably. (by ~5,000 to 1) ws --- Tom Posted Re: [time-nuts] Digital Mixing with a BeagleBone Black and D Flip Hi Simon, Some additional info. I first heard about the D-FF method of frequency comparison in the late 90's (from Rick Hambly, I think) on the old gps mailing list. It sounded really interesting. Since then, the subject has turned up every few years on this list. But each time, the topic seems to go away quietly with little or no data, plots or explanation. In addition, none of the commercial products I've taken apart appear to use this approach. Hmm. So that begs the question -- what's really going on, and why. I'm enjoying this thread because you've shown both technical competence and optimistic persistence. Perhaps once and for all, with your efforts, we can settle this matter. You will either find a working combination with excellent performance, or you will uncover enough uncontrolled variables that you never want to try it again. Either way, we all learn a lot. Keep the photos, data, and plots coming. Thanks, /tvb -- Re: [time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop Bruce posted http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/36903/1/01-2617.pdf among other things illustrates a modified approach to the offset generator by replacing the intermediate phase locked VCXO with a bandpass filter. -- Re: [time-nuts] Digital Mixing with a BeagleBone Black and D Flip Flop Simon posted www.ee.ucl.ac.uk/lcs/previous/LCS2011/LCS1136.pdf ... The idea is based on the following article which describes creating a digital DMTD with an FPGA for clocks @ 125mhz: ___ 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] PI Math question
Dennis Thanks for giving it some thought, I stuck your values in my spreadsheet, See Attached, Your values, like all values I've ever tried, cause all 4 code versions to come out with the same answer at all input steps, using any set of fixed K gains that I have tried. As you sort of say, as long as the math inside of these codes does not overflow or round the inputs can do anything at all, it does mater because all 4 version react to any input in the exact same way. Phase wraps, modular math, or anything else. The problem is not showing that the answers are all the same all the time on a simulator or spread sheet, that is easy, the problem is to use some simple math to proof it is true, beyond any skeptic's doubt, that the 4 outputs will always be the same no mater what values they receive as inputs or where the input values come from. I want to have an answer for the non-believers that like to say That does not prove anything, you just have not tried the right set of values yet. Chris, You are correct, I was using # as a character, I changed it to _ below. ws ** - Original Message - From: Dennis Ferguson On 16 Apr, 2014, at 09:50 , WarrenS warrensjmail-...@yahoo.com wrote: With the values of K1, K2 K3 constant, and the initial state of I#1, I#2 and Last_Input all zero assuming there is no rounding, clipping or overflow in the math and that if I've made any obvious dumb typo errors that they are corrected, If we assume that your 'Input' value is a real-valued measurement with an unlimited range then I think your algebra is correct. All those rearrangements will produce the same value of 'Output'. Note, though, that 'Input' doesn't have to be a value like that, and overflow in the math may be unavoidable. It depends on the nature of the sensor producing the value. For the particular case that might be relevant here, suppose 'Input' is the output of a phase error detector with an output limited to a range proportional to [-180, 180] degrees (i.e. is truncated to a fraction of one cycle) and the job of the controller is to try to keep that value at 0. Because the output of the sensor wraps around at +/- 180 you will want to do certain computations (in this case, differences between 'Input' values) with modular arithmetic. For an example of the difference this makes, assume that your first 8 'Input' values are 40 80 120 160 -160 -120 -80 -40 noting that (((-160) - (160)) mod 180) == 40. If you run these values through your first and last set of equations I think you'll find the value of 'Output' diverges at the wrap-around. I think the practical issue here is that if the basic PI phase-locked loop, as expressed by your last set of equations, has a long time constant it may fail to lock if the phase detector output wraps around like that and the initial frequency error is large enough to make the wrap-arounds occur frequently. The addition of the FLL term with its modular difference, as your first set of equations has it, will widen the capture bandwidth of the loop by keeping the integral term moving in the right direction until you get to a point where the frequency is close enough that the PLL becomes effective, at which point the behaviour of the loop becomes that of the PLL alone. The latter is what you've demonstrated. Dennis Ferguson Typos corrected below *** Ref) D = (Input - Last_Input)) Last_Input = Input I_1 = I_1 + (K1 * Input) I_2 = I_2 + (K2 * D) Output = I_1 + I_2 + (K3 * Input) get next Input value and Loop c) D = Input - Last_Input Last_Input = Input I_1Plus = I_1Plus + (K1 * Input) + (K2 * D) Output = (K3 * Input) + I#1 get next Input value and Loop b) D = (Input - Last_Input) Last_Input = Input Output = Output + (K1 * Input) + (K2 + K3) * D get next Input value and Loop a) I_1 = I_1 + (K1 * Input) Output = I_1 + ((K2 + K3) * Input) get next Input value and Loop Another way to look at the same code; Initialize all starting values registers(0) to zero Ref) D(i) = Input(i) - Input(i-1) I_1(i) = I_1(i-1) + K1*Input(i) I_2(i) = I_2(i-1) + K2*D(i) Output(i) = I_1(i) + I_2(i) + K3*Input(i) Increment i from 1 until i = n c) D(i) = Input(i) - Input(i-1) I_1(i) = I_1(i-1) + K1*Input(i) + K2*D(i) Output(i) = K3*Input(i) + I#1(i) Increment i from 1 until i = n b) D(i) = Input(i) - Input(i-1) Output(i) = Output(i-1) + K1*Input(i) + (K2+K3)*D(i) Increment i from 1 until i = n a) I_1(i) = I_1(i-1) + K1*Input(i) Output(i) = I_1(i) + (K2+K3)*Input(i) Increment i from 1 until i = n attachment: ws-Pid gains.gif___ 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] PI Math question
Ulrich That is correct, none of these simple code blocks form a controller. This is just a block of code that could be used for the PI gain function of a controller. In a complete controller the input to this gain block would typically come from a pre-filter, and the prefilter's input from the error difference between the setpoint and the feedback, etc. I wanted to keep the math as simple as possible by only including this section of code. My question was does the math in these four blocks of code all provide the same exact input to output function. What the code is being used for is not really relevant to the answer. simple example: Does the code X = 3Y have the same input to output function as X = 4 + 2 + (1+2) *Y - 6? Just because they look different does not mean they are different. The question was meant to be a simple math exercise like does 3y = (1+2)y? The answer does not need any high level math or depend on the value of y or what the code is being used for. ws *** - Original Message - From: Ulrich Bangert df...@ulrich-bangert.de To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Thursday, April 17, 2014 1:14 AM Subject: Re: [time-nuts] PI Math question Warren, the job of a controller, regardless of P, PI od PID, is to minimize the error between a process value and its setpoint. Since I see no setpoint value in any of your versions my 50 ct is that none of them really incorporates a controller at all and that for this reason the question whether they produce the same output is close to being irrelevant. Best regards Ulrich -Ursprungliche Nachricht- Von: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] Im Auftrag von WarrenS Gesendet: Mittwoch, 16. April 2014 18:50 An: Discussion of precise time and frequency measurement Betreff: [time-nuts] PI Math question A question to the math time-nuts With the values of K1, K2 K3 constant, and the initial state of I#1, I#2 and Last_Input all zero assuming there is no rounding, clipping or overflow in the math and that if I've made any obvious dumb typo errors, that they are corrected, Given this PID type of controller; D = (Input - Last_Input)) Last_Input = Input I#1 = I#1 + (K1 * Input) I#2 = I#2 + (K2 * D) Output = I#1 + I#2 + (K3 * Input) Is the above Input to Output's transfer function any different than any of the following more simplified versions of PI controllers? Or asked another way, if each of the four codes are given the exact same input string and same K Gains, will the difference between any of their outputs ever be non zero? a) D = Input - Last_Input Last_Input = Input I#1 = I#1 + (K1 * Input) + (K2 * D) Output = (K3 * Input) + I#1 b) D = (Input - Last_Input) Last_Input = Input Output = Output + (K1 * Input) + (K2 + K3) * D a) I#1 = I#1 + (K1 * Input) Output = I#1 + ((K2 + K3) * Input) ws ___ 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] PI Math question
Agree, not so clear. I did not expect this to be so hard to explain. See if this helps any. The code snippets are from a S/W simulator program that loops thru one of these code versions, producing a new Output each time a new Input value is made available. In most programs an index i is not used or needed because most past data need not be saved, the S/W just loops thru the code to produce a new output value on each pass, saving only what is necessary, in this case as Last_x. Inalize everything to zero in each code. D = (Input - Last_Input)) Last_Input = Input I#1 = I#1 + (K1 * Input) I#2 = I#2 + (K2 * D) Output = I#1 + I#2 + (K3 * Input) get next Input value and Loop c) D = Input - Last_Input Last_Input = Input I#1 = I#1 + (K1 * Input) + (K2 * D) Output = (K3 * Input) + I#1 get next Input value and Loop b) D = (Input - Last_Input) Last_Input = Input Output = Output + (K1 * Input) + (K2 + K3) * D get next Input value and Loop a) I#1 = I#1 + (K1 * Input) Output = I#1 + ((K2 + K3) * Input) get next Input value and Loop I thought the above format would be clearer than the index format below, which can save everything. This is another way to look at the same code; The input can be considered as a saved data stream of length n, in the form of Input(i) where i is a value from 1 to n. Initialize all starting values registers(0) to zero D(i) = Input(i) - Input(i-1) I#1(i) = I#1(i-1) + K1*Input(i) I#2(i) = I#2(i-1) + K2*D(i) Output(i) = I#1(i) + I#2(i) + K3*Input(i) Increment i from 1 until i = n a) D(i) = Input(i) - Input(i-1) I#1(i) = I#1(i-1) + K1*Input(i) + K2*D(i) Output(i) = K3*Input(i) + I#1(i) Increment i from 1 until i = n b) D(i) = Input(i) - Input(i-1) Output(i) = Output(i-1) + K1*Input(i) + (K2+K3)*D(i) Increment i from 1 until i = n c) I#1(i) = I#1(i-1) + K1*Input(i) Output(i) = Output(i-1) + (K2+k3)*Input(i) Increment i from 1 until i = n The question is, Can some math person/programer show that the outputs(1 thru n) are the same in each code version above when given the same Input(1 thru n) data stream, using simple math? I'm not asking what the code will do, Just if the codes above will produce the same outputs, when given the same set of inputs? ws Warren, I understand your message as an afterwards try to put some sense in your original question, but if you write D = (Input - Last_Input) then this clearly denotes the differential part of a PID controller (with the multiplication with the coefficient for the differential part coming later) If you add now In a complete controller the input to this gain block would typically come from a pre-filter, and the prefilter's input from the error difference between the setpoint and the feedback, etc. saying that input is something complete different then I fear that this discusion is drifting into complete nonsense because if Input denotes an entity which contains an error signal in any form then D = (Input - Last_Input) is something that is ill defined and has nothing to do with the differential part of a PID controller. I wanted to keep the math as simple as possible... Good idea but if simplification creates something wrong then the simplification has gone one step to far. Best regards Ulrich * -Ursprungliche Nachricht- Ulrich That is correct, none of these simple code blocks form a controller. This is just a block of code that could be used for the PI gain function of a controller. In a complete controller the input to this gain block would typically come from a pre-filter, and the prefilter's input from the error difference between the setpoint and the feedback, etc. I wanted to keep the math as simple as possible by only including this section of code. My question was does the math in these four blocks of code all provide the same exact input to output function. What the code is being used for is not really relevant to the answer. simple example: Does the code X = 3Y have the same input to output function as X = 4 + 2 + (1+2) *Y - 6? Just because they look different does not mean they are different. The question was meant to be a simple math exercise like does 3y = (1+2)y? The answer does not need any high level math or depend on the value of y or what the code is being used for. ws *** - Original Message - From: Ulrich Bangert df6jb at ulrich-bangert.de To: 'Discussion of precise time and frequency measurement' time-nuts at febo.com Sent: Thursday, April 17, 2014 1:14 AM Subject: Re: [time-nuts] PI Math question Warren, the job of a controller, regardless of P, PI od PID, is to minimize the error between a process value and its setpoint. Since I see no setpoint value in any of your versions my 50 ct is that none of them really incorporates a controller at all and that for this reason the question whether they produce the same output is close to being irrelevant.
[time-nuts] PI Math question
A question to the math time-nuts With the values of K1, K2 K3 constant, and the initial state of I#1, I#2 and Last_Input all zero assuming there is no rounding, clipping or overflow in the math and that if I've made any obvious dumb typo errors that they are corrected, Given this PID type of controller; D = (Input - Last_Input)) Last_Input = Input I#1 = I#1 + (K1 * Input) I#2 = I#2 + (K2 * D) Output = I#1 + I#2 + (K3 * Input) Is the above Input to Output's transfer function any different than any of the following more simplified versions of PI controllers? Or asked another way, if each of the four codes are given the exact same input string and same K Gains, will the difference between any of their outputs ever be non zero? a) D = Input - Last_Input Last_Input = Input I#1 = I#1 + (K1 * Input) + (K2 * D) Output = (K3 * Input) + I#1 b) D = (Input - Last_Input) Last_Input = Input Output = Output + (K1 * Input) + (K2 + K3) * D a) I#1 = I#1 + (K1 * Input) Output = I#1 + ((K2 + K3) * Input) ws ___ 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] First success with very simple, very low cost GPSDO
Magnus wrote: We still disagree Ok, but I do see progress because we are getting closer. If you will now allow me to initialize both code's DC offsets to zero before the code is run, then because their AC performance is the same, their outputs will remain the same if their inputs are the same, as long as there is no clipping or rounding in the math. Thanks for the long and most interesting analysis. To test the hypothesis that the P and F gains in your code example always have the same effect, I did a black box test of the two code sections below, using Excel with double floating point math I provided the same data string to both code's inputs, using various P, F, I, gains and compared their outputs to each other. Of course I can never be sure I've included all cases, But I did enough variations to satisfy me that with this black box test, the outputs of both codes where always equal under all of the variations that I tried, which included ramps, steps, sine-waves and random noise in various combinations, as long as F did not change during a data run. (note 4) If you can tell me some simulation values to use where the two black box outputs will not be equal what would be most helpful in understanding any differences that these two codes may have. If not, I must trust the simulation results, that I do understand, more than I can trust some of your analysis, that I do not fully understand. Because their outputs are always equal with any combination of inputs and gains, until I see some case where the outputs do not remain equal, I must concluded that the performance of the two codes will also be equal in any loop, under all conditions, whether locked or not, even then there are discontinuous phase wraps or when a non-linear phase detector is in the loop. In other words, the MD code as shown below, does the exact same thing as the PI code beneath it. I'd be most interested to hear if there is a flaw in this limited simple but thorough black box type of test or the conclusion that both codes always provide the exact same function MD code First initialize Vdp_pre Vi to zero and then run the loop: Vdf = Vdp - Vdp_pre Vdp_pre = Vdp Vi = Vi + I*Vdp + F*Vdf Vf = Vi + P*Vdp PI code Initialize Vi to zero before running the loop Vi = Vi + I*Vdp // PI integrator Vf = Vi + (P + F) * Vdp // PI Output notes, 1) The DC offsets, which is the only difference between these two code examples are both first set to zero at the initialization time. 2) Any time after initialization, their outputs depends on their AC response, which are exactly equal. 3) The two outputs remained equal to each other, with all of the input data streams I tried and with various gain factors when the gains remained constant during a run. 4) To insure that the outputs remain the same during any dynamic gain changes, This slightly modified code removes the possible derivative skew that can happen during a F gain change. MD+ Modified code if the F gain is dynamic. (If F gain is static, this code provided the exact same results as the MD code above.) First initialize Vdp_pre Vi to zero, F1= F, then run the loop: Vi = Vi + I*Vdp + (F*Vdp - F1*Vdp_pre) Vf = Vi + P*Vdp Vdp_pre = Vdp F1 = F ws *** Warren, On 13/04/14 19:24, WarrenS wrote: Magnus wrote You are over-focusing ... At least on that we totally agree. The same can be said of you in over-focusing on what comes before the Phase error term Vdp. The PI code we've been discussing does not care. Can we just focus to see if you can find a mistake in my understanding of your code below? Here we disagree, and it's not that I want to disagree with you, let me assure you. The thing is that one has to have a split vision, as there is different base-cases to consider. If we where only discussing the dynamics of the loop while being locked, then F and P does about the same thing. That I have already said and there we agree. If we where *only* looking at that case, then we are in full agreement that F does not really add any value over P. To do this part of the analysis, the code-snippet I provided is sufficient, even if we is cheating a little. However, as I am trying to pointing out, it's when the loop is in frequency acquisition, that's where the F contribution aids the loop by providing a FLL. In order to analyze this behaviour, you will have to analyze the complete loop. This is why I have a split vision. Just analysing the loop for frequency acquisition behaviour using the AC dynamics of the locked-in behaviour simply does lead oneself astray, me too. The output (Vf) is the sum of the integrator (Vi) and P*Vdp (line 4) The output of the integrator (Vi) is the sum of the integral of I*Vdp and the integral of F*derivative_of_Vdp (Line #3) The integral of the derivative cancel (reference below) So the above can be simplified to The output Vf is the sum of three terms: P*Vdp I * integral_of_Vdp F*Vdp
Re: [time-nuts] First success with very simple, very low cost GPSDO
Magnus wrote You are over-focusing ... At least on that we totally agree. The same can be said of you in over-focusing on what comes before the Phase error term Vdp. The PI code we've been discussing does not care. Can we just focus to see if you can find a mistake in my understanding of your code below? The output (Vf) is the sum of the integrator (Vi) and P*Vdp (line 4) The output of the integrator (Vi) is the sum of the integral of I*Vdp and the integral of F*derivative_of_Vdp (Line #3) The integral of the derivative cancel (reference below) So the above can be simplified to The output Vf is the sum of three terms: P*Vdp I * integral_of_Vdp F*Vdp The P and F gains above both have the exact same effect and can further be simplified to: The output Vf is the sum of two terms: (P+F)*Vdp I * integral_of_Vdp As far as I can tell, your code: Vdf = Vdp - Vdp_pre Vdp_pre = Vdp Vi = Vi + I*Vdp + F*Vdf Vf = Vi + P*Vdp Gives the exact same output as: Vi = Vi + I*Vdp Vf = (P + F) * Vdp + (I * Vi) Which is nothing more than a standard PI controller Do we still disagree?? If so where? reference http://www.mathmistakes.info/facts/CalculusFacts/learn/doi/doi.html that says in part; the fundamental theorem of calculus can be loosely expressed in words as: the integral of a derivative of a function is that original function, ... ws *** Warren, On 13/04/14 07:44, WarrenS wrote: Magnus wrote It may appear so, but the derivate, scale-factor F and integrate does not make the scale-factor F equalent to P, since you are forgetting that the derivate removes the DC term We don't quite agree on that point yet. I can not find anything different or special that your code example is doing at it's output, It seems to produce the exact same results as a standard PI controller. Also in your code and all PI code the FLL function you talk about is provided by the P term, Don't need to add the derivate, scale-factor F and integrate term. You are over-focusing on the derivate canceling the integrate of the loop-state, but if you want to play that game and make sense out of it, you should not cancel out the integrator in the PI operation, but the integrators of the reference (resulting in omega_0) and that of the steered oscillator (resulting in omega_0 + omega_e + Ko*Vf). As they go through the phase comparator (really a frequency comparator) you have Kd*(omega_0 - (omega_0 - omega_e)) = -Kd*omega_e -Kd*Ko*Vf. That is then scaled by the F factor into the integrator and the integrator then alters it's state to cancel this out. This is happening when frequency error (omega_e - it's angular frequency variant) is so large that the PLL part is beating and has almost no DC component to charge the integrator with. The P factor will simply not aid in building up the integrator state like this. So, that part is a FLL. I know it is confusing, but one has to see the complete loop, and see how you can aid in bulding up the frequency correction state. PLLs is really bad at this if the error is large. FLL aiding that state buildup helps a lot. Once you have started to understand the double nature of this loop, it's FLL and PLL styles you also realize that the FLL part degrades itself into a contributor to the AC-components proportional path, as the frequency error component has a zero DC component. However, if the loop is put into stress, the FLL starts aiding on the frequency again. There is thus no mode but rather dominant characteristics and depending on the frequency error of the loop either the FLL or PLL is dominant. 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] First success with very simple, very low cost GPSDO
woops, corrected typing error below Vi = Vi + I*Vdp Vf = (P + F) * Vdp + (I * Vi) to Vi = Vi + I*Vdp Vf = (P + F) * Vdp + Vi - Original Message - Magnus wrote You are over-focusing ... At least on that we totally agree. The same can be said of you in over-focusing on what comes before the Phase error term Vdp. The PI code we've been discussing does not care. Can we just focus to see if you can find a mistake in my understanding of your code below? The output (Vf) is the sum of the integrator (Vi) and P*Vdp (line 4) The output of the integrator (Vi) is the sum of the integral of I*Vdp and the integral of F*derivative_of_Vdp (Line #3) The integral of the derivative cancel (reference below) So the above can be simplified to The output Vf is the sum of three terms: P*Vdp I * integral_of_Vdp F*Vdp The P and F gains above both have the exact same effect and can further be simplified to: The output Vf is the sum of two terms: (P+F)*Vdp I * integral_of_Vdp As far as I can tell, your code: Vdf = Vdp - Vdp_pre Vdp_pre = Vdp Vi = Vi + I*Vdp + F*Vdf Vf = Vi + P*Vdp Gives the exact same output as: Vi = Vi + I*Vdp Vf = (P + F) * Vdp + Vi Which is nothing more than a standard PI controller Do we still disagree?? If so where? reference http://www.mathmistakes.info/facts/CalculusFacts/learn/doi/doi.html that says in part; the fundamental theorem of calculus can be loosely expressed in words as: the integral of a derivative of a function is that original function, ... ws *** Warren, On 13/04/14 07:44, WarrenS wrote: Magnus wrote It may appear so, but the derivate, scale-factor F and integrate does not make the scale-factor F equalent to P, since you are forgetting that the derivate removes the DC term We don't quite agree on that point yet. I can not find anything different or special that your code example is doing at it's output, It seems to produce the exact same results as a standard PI controller. Also in your code and all PI code the FLL function you talk about is provided by the P term, Don't need to add the derivate, scale-factor F and integrate term. You are over-focusing on the derivate canceling the integrate of the loop-state, but if you want to play that game and make sense out of it, you should not cancel out the integrator in the PI operation, but the integrators of the reference (resulting in omega_0) and that of the steered oscillator (resulting in omega_0 + omega_e + Ko*Vf). As they go through the phase comparator (really a frequency comparator) you have Kd*(omega_0 - (omega_0 - omega_e)) = -Kd*omega_e -Kd*Ko*Vf. That is then scaled by the F factor into the integrator and the integrator then alters it's state to cancel this out. This is happening when frequency error (omega_e - it's angular frequency variant) is so large that the PLL part is beating and has almost no DC component to charge the integrator with. The P factor will simply not aid in building up the integrator state like this. So, that part is a FLL. I know it is confusing, but one has to see the complete loop, and see how you can aid in bulding up the frequency correction state. PLLs is really bad at this if the error is large. FLL aiding that state buildup helps a lot. Once you have started to understand the double nature of this loop, it's FLL and PLL styles you also realize that the FLL part degrades itself into a contributor to the AC-components proportional path, as the frequency error component has a zero DC component. However, if the loop is put into stress, the FLL starts aiding on the frequency again. There is thus no mode but rather dominant characteristics and depending on the frequency error of the loop either the FLL or PLL is dominant. 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] First success with very simple, very low cost GPSDO
Magnus Interesting, Am I missing something or is there an error in your code or logic. Looks to me like the code is a PI controller with a added D term (Vdf) of input, and the D is then Integrated with a scale factor of F at Vi = Vi + F*Vdf ... An integrated derivative is exactly equal to a P Looks to me like the code is still just a standard PI controller where Vdp is the phase error; Vi = Vi + I*Vdp Vf = Vi + (P+F) * Vdp This can be simplified by dropping the F scale factor and increasing the P a little What am I missing? One thing for sure that the code is missing is a pre-filter, which is very helpful because of the GPS phase noise. Turning on the D term in a PID with a prefilter is mostly not recommended, They tend to just cancel each other. ws ** Magnus Danielson wrote On 10/04/14 20:28, Tom Van Baak wrote: I agree with Charles. Further, you don't even have to wait a predetermined amount of time (this would be oscillator or environment dependent). Instead simply monitor the rate of frequency change. When the drift rate drops to the level where your PID is known to be able to track, then start the PID. Realize that just 2 seconds after power-up you have your first frequency measurement. By 3 seconds you have your first drift measurement. Just wait until it falls to however few ppm/second or ppb/second you need for your loop to smoothly track. This avoids special case PID startup or wind-up code. Although you can argue it merely replaces it with special case drift rate code. I'm suspicious of fast/slow tracking loops. If you want to vary the tracking, perhaps it is best to continuously, transparently, smoothly vary loop parameters according to drift rate rather than use a hardcoded fast/slow algorithm binary switch. I'm sure there's deep theory on this, which I have not read yet. This is where many spend their time building a heuristics. My favorite solution is to derive the phase detector and let the result feed into the integrator through a scaling factor. This input to the integrator is in parallel to the I factor input. Code-wise we get something like this: Vdf = Vdp - Vdp_pre Vdp_pre = Vdp Vi = Vi + I*Vdp + F*Vdf Vf = Vi + P*Vdp For far-out frequency errors, the PI PLL is weak, due to Bessel coefficient, so the FLL dominates and the F factor steers the loop gain of the FLL. It steers the Vi state of the integrator until it becomes close, with an exponential decay into zero frequency error. When it does, the Bessel coefficient becomes stronger and stronger and then PI PLL starts to take over. When the gain of the PLL surpasses that of the decaying FLL the PLL just takes over... by design. When the PLL has locked the frequency, the FLL part just doesn't have gain, but adds a little noise. The benefit of this approach is that the frequency correction is kept in the Vi state, and depending on the Vi state either the FLL or PLL dominates, there is no hand-over, there is no external intelligence to chose mode, it is always steered by the need from frequency-error needing to be corrected and the current Vi, or if you so like, the current Vi error. Simple, relatively easy to analyse and completely linear regulation mechanisms. 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] First success with very simple, very low cost GPSDO
Magnus Thanks, even more interesting, I'll give it a try after I figger out under what conditions it should help. You are right, I did not fully take into account the DC offset that is removed. That is because it happens only once on the very first pass the code loop. Any effect that may have, goes away forever after the control loop's TC settling time has passed and the VI term has had time to add the removed DC offset back in. Assuming there is no clipping going on, a D * I is exactly the same as a P with one exception, as you pointed out. It also removes a DC offset that is equal to the very first value read. (but this only happens once at the first pass in the code) So D * I == P - offset; where Offset == the first Vdp reading. After I term has had time to replace first Vdp reading's offset that was removed, the D * I term's effect is back to the exact same effect as an P term for ever more. So does the code depend on the first Vdp error reading to contain some valid and useful value other than zero, Are you suggesting this only works once during turn on and it's effects only apply over the loops TC time period? (if so sounds unpredictable at best, If not I still don't know how it works) I can see a few possible initial conditions that could happen: Does the code depend on a specific one of these to occur? #1 the loop is started before there is any Vdp phase error, in which case the D * I term will == P, No removed offset, therefore no effect on anything but the P gain. #2 the loop is started after the VdP error is stable, valid and non zero, in which case the D * I term will == P minus a fixed offset #3 the loop is started when the Vdp error input is not yet stabilized or still invalid in which case the D x I term will ==P minus some random number (not sure that can be depended to help anything) In any case looks to me like the code is still mostly a standard PI controller , at least after the code has been running long enough to settle on the Loop's TC. After that, I can not see any further useful effect. Same long term effect, Not quite the same effect short term. Vi = Vi + (I * Vdp) ; Initial Vi value = F*First_Vdp_reading) Vf = Vi + (P+F) * Vdp ws Magnus Danielson wrote Warren, On 12/04/14 21:09, WarrenS wrote: Magnus Interesting, Am I missing something or is there an error in your code or logic. Looks to me like the code is a PI controller with a added D term (Vdf) of input, and the D is then Integrated with a scale factor of F at Vi = Vi + F*Vdf ... An integrated derivative is exactly equal to a P I may appear so, but the derivate, scale-factor F and integrate does not make the scale-factor F equalent to P, since you are forgetting that the derivate removes the DC term and the integration forms it's own DC term. This DC-term as scaled through oscillator gain and added to the oscillators offset is then subtracted from the reference frequency and thus the error frequency is input to the integrator stage. The FLL variant model can be understood if the differentiation is pushed to both inputs of the phase comparator, where the reference frequency and oscillators frequency will be subtracted rather than their phase and the only remaining integrator in the loop is that holding the Vi term. The frequency error term will exponentially decay with the time-constant as set by the F coefficient. So, F and P is not equivalents, as P will not contribute to the state of Vi, which is evident in the weak pull-in of a standard PI loop. However, F and P will for the AC behaviour of the loop be equivalents, so care must be taken into setting P with regard to F in order to get the expected damping of the loop. Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly wired PID-loop. Quite minimalistic. Looks to me like the code is still just a standard PI controller where Vdp is the phase error; Vi = Vi + I*Vdp Vf = Vi + (P+F) * Vdp This can be simplified by dropping the F scale factor and increasing the P a little What am I missing? I think I covered that above. One thing for sure that the code is missing is a pre-filter, which is very helpful because of the GPS phase noise. It is missing a whole deal, but I wanted to illustrate the core. One thing which is not covered is the un-wrapping of the phase detector in the case that it does not wrap around binary. Another thing, the frequency detector phase history may need to be unwrapped prior to subtraction in order to make sure the frequency estimate becomes correct. Turning on the D term in a PID with a prefilter is mostly not recommended, They tend to just cancel each other. I avoided the D coefficient name as it will be confusing to a normal PID naming, when it will in fact does not do the normal D. Cheers, Magnus Magnus wrote snip My favorite solution is to derive the phase detector and let the result feed
Re: [time-nuts] First success with very simple, very low cost GPSDO
Magnus I think all three below provide the exact same results. If true, That may not be doing what you wanted. ws Vi = Vi + (I * Vdp) ; Initial Vi value = - F * First_Vdp_reading) Vf = Vi + (P+F) * Vdp ? same as: Vi = Vi + (I * Vdp) Vf = Vi + (P+F) * Vdp - Offset;(where Offset = F * First_Vdp_reading) ? same as: Vdf = Vdp - Vdp_pre Vdp_pre = Vdp Vi = Vi + I*Vdp + F*Vdf Vf = Vi + P*Vdp ___ 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] First success with very simple, very low cost GPSDO
Magnus wrote It may appear so, but the derivate, scale-factor F and integrate does not make the scale-factor F equalent to P, since you are forgetting that the derivate removes the DC term We don't quite agree on that point yet. I can not find anything different or special that your code example is doing at it's output, It seems to produce the exact same results as a standard PI controller. Also in your code and all PI code the FLL function you talk about is provided by the P term, Don't need to add the derivate, scale-factor F and integrate term. The derivate integrate function could remove (or change) the signal's offset if it was coded to do so, But in your code, DC offset removal is not shown, so it would appear that **no** DC offset is being removed. The DC Offset that is removed depends on what value that Vdp_pre is initialize to, before the first cycle thru the code. If Vdp_pre and Vi are both initialized to zero then there is no offset removed, and derivate, scale-factor_F then integrate exactally equals the same as scale-factor_F only. If vdp_pre is initalized to the first input value Vdp(0) instead of zero, as is often the case, then the offset removed would be scale-factor_F x Vdp(0) either way the code (with Vdp_pre Vi pre-initialized to zero) Vdf = Vdp - Vdp_pre Vdp_pre = Vdp Vi = Vi + I*Vdp + F*Vdf Vf = Vi + P*Vdp appears to produces the exact same output as the simpler code: (when Vi is initalized to zero) Vi = Vi + (I * Vdp) ; Vf = Vi + (P+F) * Vdp (To add offset removal, Initialize Vi to - F * First_Vdp_reading ) Also get same results from: (where Dc = 0) or for offset removal set Dc to F*First_Vdp_reading Vi = Vi + (I * Vdp) Vf = Vi + (P+F) * Vdp - Dc F and P is not equivalents, as P will not contribute to the state of Vi, which is evident in the weak pull-in of a standard PI loop We're going to have to disagree on that also. The output is the sum of the P term and the I term, You end up with the exact same results if you take something away from one of then and apply it to the other. That is what my two code examples are doing. If you want faster pull in just increase the product of F*P, it does not matter which, They both give the same exact results for DC and AC. Tom, do you want to program Gpsim1 to break this standoff? ws * Warren, On 12/04/14 21:09, WarrenS wrote: Magnus Interesting, Am I missing something or is there an error in your code or logic. Looks to me like the code is a PI controller with a added D term (Vdf) of input, and the D is then Integrated with a scale factor of F at Vi = Vi + F*Vdf ... An integrated derivative is exactly equal to a P I may appear so, but the derivate, scale-factor F and integrate does not make the scale-factor F equalent to P, since you are forgetting that the derivate removes the DC term and the integration forms it's own DC term. This DC-term as scaled through oscillator gain and added to the oscillators offset is then subtracted from the reference frequency and thus the error frequency is input to the integrator stage. The FLL variant model can be understood if the differentiation is pushed to both inputs of the phase comparator, where the reference frequency and oscillators frequency will be subtracted rather than their phase and the only remaining integrator in the loop is that holding the Vi term. The frequency error term will exponentially decay with the time-constant as set by the F coefficient. So, F and P is not equivalents, as P will not contribute to the state of Vi, which is evident in the weak pull-in of a standard PI loop. However, F and P will for the AC behaviour of the loop be equivalents, so care must be taken into setting P with regard to F in order to get the expected damping of the loop. Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly wired PID-loop. Quite minimalistic. Looks to me like the code is still just a standard PI controller where Vdp is the phase error; Vi = Vi + I*Vdp Vf = Vi + (P+F) * Vdp This can be simplified by dropping the F scale factor and increasing the P a little What am I missing? I think I covered that above. One thing for sure that the code is missing is a pre-filter, which is very helpful because of the GPS phase noise. It is missing a whole deal, but I wanted to illustrate the core. One thing which is not covered is the un-wrapping of the phase detector in the case that it does not wrap around binary. Another thing, the frequency detector phase history may need to be unwrapped prior to subtraction in order to make sure the frequency estimate becomes correct. Turning on the D term in a PID with a prefilter is mostly not recommended, They tend to just cancel each other. I avoided the D coefficient name as it will be confusing to a normal PID naming, when it will in fact does not do the normal D. Cheers, Magnus ___ time-nuts mailing
Re: [time-nuts] GPSDO Crystal Aging
Ulrich Thanks for posting the reference. Very interesting and useful. The clues they give sounds like enough information to do the Smartclock loop control things that they talk about. ws *** Hi Brooke, HP had some way around SA that improved the timekeeping. HP called it the Smartclock Algorithm and you can find some very basic information about it here: http://www.hpl.hp.com/hpjournal/96dec/dec96a9.pdf I have been trying months to find a reference on how it REALLY works but it seems that this is one of the better kept secrets of HP. Best regards Ulrich ___ 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] HP 10811 - 60165 Info Request
The single oven HP10811's heater supply is spec 20 to 30V, (=18V is mostly OK, 19V is better) The Inner oven voltage spec on the Dual Oven 10811s that I have is 12 to 30Volts, (All work good down to ~11V) Internally my dual oven units use a 5V ref in their heater controller instead of a 10V reference. The thermistor bridge is 5V on both) The outer oven needs ~5V nom to operate at ~115 deg F. 10 Volt max from an outer oven linear controller works good for Lab work. For best TC, the Dual oven units that I've tested really need an outer oven controller. On a couple of units, the temp TC went from around 1e-10 / deg C without the outer oven to 1e-12 /degC. Outer oven Pin outs; 1-GREY thermistor#1 (100K ohm@ 25C) 2-GREY thermistor lead#2 3-RED Heater#1 (~12 Ohm) 4-RED Heater lead#2 5- NC 6- NC *** 1 - BRN Oscillator Return (Com) 2 - RED Oscillator Power (+12V) 3 - ORG Oven Monitor Return (Com) 4 - YEL Oven Monitor Output 5 - GRN Oven Power (+18-24V) 6 - BLU Oven Return (Com) Thomas Knox ** To: time-nuts at febo.com From: johncroos at aol.com Date: Mon, 10 Mar 2014 14:17:58 -0400 Subject: [time-nuts] HP 10811 - 60165 Info Request I have acquired one of these double oven oscillators. Seems like a useful thing. Need info on pin outs, and operating voltages. Also any other useful information or links to same would be appreciated. Please reply off list with any files of specs etc to my email - johncroos at aol.com All help appreciated. Best regards to all john c roos k6iql ___ ___ 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] Crude Survey Technique
John In answer to your original questions, No problem if you have a good setup including a good sky view, antenna, and TBolt setup. It is important to do each run at the different locations at the same time of the day and average the results for as long as you can. Best is to do a 24 Hr survey at each location. see the attached LH plot for the effect of time on location reading error. Multiple Tbolts on the same antenna don't help, unless they are on different antennas. ws *** - Original Message - From: johncr...@aol.com To: time-nuts@febo.com Sent: Thursday, November 21, 2013 10:52 AM Subject: [time-nuts] Crude Survey Technique I wish to establish a north south line on my property to an accuracy of +/- 2 degrees. Could this be done by loading a T-bolt, Antenna, Power source, and laptop into my little red wagon? The idea being to find two positions several hundred ft apart where either LH or T-bolt Mon report the same latitude? Will either of these programs report to sufficient accuracy? The base line would be 300 ft, though more is possible.I realizes that the T-bolt is not a survey device, but I can spend several hours fixing each position if required. All comments appreciated.?? -73 john k6iql Question - If I use 3 T-bolts on the same antenna, feedline, splitter etc. and run 3 instances of T-bolt mon - can the results be improved??? attachment: ws-1-3D#2.gif___ 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] DMTD: Mixer DC offset will result in time offset at zero-crossing detector out?
Stephan Did you also notice that the AC coupling is done **after** the sine wave has already been clipped by the previous stage (according to the schematic note)? This generally is not a good way to remove DC offset from a low level 'noisy' signal. I doubt that Bruce was recommending doing it that way. ws - Original Message - From: Stephan Sandenbergh ssandenbe...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, November 22, 2013 4:19 AM Subject: Re: [time-nuts] DMTD: Mixer DC offset will result in time offset at zero-crossing detector out? Hi, Thanks - mystery solved. This is one of the systems that I looked at, and missed the DC block in the second amplification stage. I guess it is possibly a large Ceramic 10uF. My bad. Thank you for putting up those web pages I find them to be very good references. I spent quite a lot of time reading through them. Something that puzzles me though is your mixer termination ( http://www.ko4bb.com/~bruce/LowNoiseMixerPreamp.html). What is the logic in having the second balun (and connected in that way)? Regards, Stephan. On 22 November 2013 13:15, Bruce Griffiths bruce.griffi...@xtra.co.nzwrote: Stephan Sandenbergh wrote: Hi, I'm playing with dual-mixer time difference stuff again. And, came across this and I find it somewhat puzzling since no one else seems to have encountered it. Possibly because I'm missing something? The doubly balanced mixers (of the type known to be used in DMTDs and phase noise measurement systems) are known to have DC offsets. So much so that the guys doing phase noise measurements employ elaborate DC removal circuits in their preamps to combat this. Here's my question: why isn't this DC offset removed in any DMTD circuits I've seen? It seems standard practice to attach the filtered mixer output directly to the zero crossing detector. I did a quick simulation (see attached): The mixer beat is a 10Hz sine 0.7Vpp. If you then use a Collins style zero crossing detector the first stage will have a small gain (I chose a gain of 2.83 from Bruce Griffiths pages ( http://www.ko4bb.com/~bruce/ZeroCrossingDetectors.html)). I then compare this ideal signal to that of a similar one that is offset by 40mV. Notice the asymmetry in the signal due to offset. 40mV result in 1.8ms offset 4mV result in 180us offset Obviously, once the time offset is there no amount of subsequent slope amplification will remove it. I've tested this in practice and bingo, I now have a very accurate way of plotting relative mixer DC offset over time. Any comments? ___ 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. One can always add AC coupling to eliminate this effect as in http://www.wriley.com/A%20Small%20DMTD%20System.pdf Bruce ___ 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] Morion MV89 and LTC6957
One thing to be aware of on the MV89 is that it is a 5 MHz osc that uses a freq doubler. On the ones I've tested, without further filtering, every other cycle's period is different by ~ 1 ns or so. For a time nut that likes to see 1ps jitter, it is a whole lot of cycle to cycle edge jitter that shows up on any signal that is divided down by a non 2 to n divider. The second thing I've seen is that the output Cap is open in a large number of them. ws ** Hello there, I'm trying to build a low phase noise signal generator with a Morion MV89 OCXO. ( http://www.morion.com.ru/catalog_pdf/MV89-OCXO.pdf ) The 10 MHz Sine coming from the MV89 shall be converted to a 10 MHz rectangle with the LTC6957-3 ( http://cds.linear.com/docs/en/datasheet/6957f.pdf ). Since the information in the MV89's data sheet is rather thin and shipping is taking a lot longer than expected/promised, I thought I'd ask if someone here has any experience with it and maybe can answer some questions I have... 1. Does anyone know if the MV89 is internally AC coupled / if the Output Sine has an Offset? 2. I'm not sure if termination is needed in this case or which way to terminate would be best for a low phase noise/low jitter application. Can anyone give me some hints to what would be important? Thanks a lot! ___ 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] The 5MHz Sweet Spot
Said Jackson posted: Crystal jumps are the biggest menace facing users of crystals/oscillators today. Are you including both phase jumps and frequency jumps together? Is one more or likely to happen than the other? Is it mostly a jump that effects just the phase or freq, or is there everything in-between, jumps that effects both phase and freq at the same instant in time also just as likely? We all know each effects the other, but that is only over time, instantaneously and over short time spans phase and freq jumps are separate things and maybe from different causes. A true phase jump causes only a one cycle freq error and a true freq offset jump does not cause an instantaneous phase jump. If the main causes of random freq jumps and random phase jumps are from different things, then with a high speed, high resolution detector, I wonder if knowing which event has really occurred, that then some correction compensation could be applied that does not effect the other. An Oversimplified example; A Phase lock loop does not care what the instantaneous freq is, and a true Freq Lock loop does not care what the phase difference is. With a DDS, one can change the freq without causing a phase step or it can cause a phase step, without causing a freq offset. With two variables (instantaneous phase and freq offset control) and two unknowns (instantaneous jumps in either), couldn't one apply a correction to the right place for any random step error that occurred? It would depend if the errors are caused by true independent random fast jumps or just slowly drifting interacting changes. ws *** Bob, et. al., Lots of opinions in this discussion, but none of it discusses the elephant in the room affecting todays' vendors: Random crystal instability versus manufacturing techniques. I can buy oscillators from multiple vendors that have -115dBc at 1Hz or better and noise floors of -182dBc. That technology is well understood and has been mature for a very long time and to me its boring. Recently Ulrich Rhode even had a great article in the Microwave Journal detailing how exactly to build one of those units. But what does it help me to have -115dBc if the darn thing jumps 50ppt every two to three days?? Crystal jumps are the biggest menace facing users of crystals/oscillators today and so far I have never been given a reasonable explanation from any of the vendors out there what causes it and how to avoid it or how they plan to address it. In fact no vendor we know tests for it to levels of sub-ppt over days which is what is necessary for any disciplined application as disciplining will clearly show even the smallest crystal jumps. Almost every vendor will do a frequency test only, where a phase test would be needed. Users of crystals/oscillators are left with doing an exhaustive yield test during burn-in to find bad crystals. We test our boards for 3 days and more to weed out jumpy crystals, and its a pain and very expensive to have to do this on finished goods as rework is in order for units that fail. The results are staggering, some vendors consistently have jumpy product, others consistently have excellent product, all have at least occasional batches that are worse to far worse than standard deviation. Some are so bad that one batch may yield 95% and the next batch of the same exact product will only yield 50% or less! I think this is the area of Quartz processing that has the least amount of research invested into it, and as anyone that has seen their Z38xx unit jump up and down in phase can attest to its a menace and can ruin one's day. I wish there were something besides yield testing that can be done to avoid manufacturing and shipping bad crystals to integrators. BVA seems to be one of those solutions, but how many BVA's have we seen in products that cost $400 retail?? Bye, Said ___ 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] Re; Req: Decent GPS Antenna Active/PassiveRecommendation
I agree with John that it is a super waste of effort and money or at the very least can be for many. But for the extreme time-nut, so what? Being an extreme TBolt nut, and having done this many times before, I have to point out where a large amount of time and effort can help Do protect the receiver from rapid temp changes This is always a good idea and easy to do for the most part, If you want to go total-nuts, and improve things even more, don't let the temp change at all. (LH temp controller) The glitches you see will always occur as the receiver switches satellites and cannot be avoided with even the most perfect antenna location If there are glitches of any kind at any level, that is an indication that something are less than optimal, because the 'glitches can be eliminated with a lot of time, effort, and money Some of the more typical causes of the big of phase jumps glitches that happen when satellites switch are due to: a) wrong antenna location saved b) multipath signals, c) Not enough signal strength d) Az set too low letting in poor signals, or too high not letting in enough satellites e) allowing satellites with too low of signal strength to be included. f) GPS not in fixed location mode. g) A non choke ring antenna that is letting in signals from below. f) others ... Set the DF to 1 and the TC to 200 seconds and leave it there. Good idea for most with a typical TBolt setup, and good enough for most applications, But it can be made more than a decade better with a lot of time, effort, and/or money don't put the thing on the tower. Total waste of effort. Unless you want to get rid of those glitches when the satellites change. Get a Rb. Good idea for most, unless you care more about the ADEV noise from 10ms to 10sec, which is decades worse in the typical small RB than even a stock TBolt. Unless you can compare the phase of the 10 MHz with a local Rb or Cs (or a good crystal) you cannot learn much more or provide better than the short term accuracy of the receiver. Improving on this will require a good local standard running open loop. While having the proper tools will make things faster and easier, they are not necessary. With an extreme amount time, effort, and experience, It can be done using only LadyHeather. LH has the options that will let you set up a TBolt good enough to be able to test most any Rb or Cs. There is no single magic bullet fix. To make a real difference, there is a long list of things that must be done and optimized, and unless you do many things, all of which takes spending a lot of time and effort on, then spending too much time or effort on just one item can be a super waste of time, effort and money even for the extreme Time-Nut. With enough time, effort and/or money, the TBolt's performance can be improved to be decade or two better than the typical stock set-up. So it all depends on now nutty you want to get and how much time to you have to spend to make it better. ws From: johncroos at aol.com Sent: Sunday, September 15, 2013 9:50 AM Subject: [time-nuts] Re; Req: Decent GPS Antenna Active/PassiveRecommendation At least for the T-bolt moving the antenna to a super-optimal location is a super waste of effort and money. I suspect this applies to most other GPS DOs. Unless you can compare the phase of the 10 MHz with a local Rb or Cs (or a good crystal) you cannot learn much more or provide better than the short term accuracy of the receiver. Improving on this will require a good local standard running open loop. The location should provide tracking of a few satellites - more than 4 if possible - but it will remain locked with as few as 1 or 2. The glitches you see will always occur as the receiver switches satellites and cannot be avoided with even the most perfect antenna location. So the short term ADEV presented by LH jumps around. Fooling around with the damping factor and time constants will not help this much. Set the DF to 1 and the TC to 200 seconds and leave it there. (or something like those values) The way to get a good standard is to open loop (using you fingers) adjust a local Rb such as the LPRO so it maintains a constant phase difference with the GPS 10 MHz for a period of hours. Using the time for the phase to change a measured number of nanoseconds, the frequency offset between the two is easily calculated. There is a HP ap note on how to do this. Use the GPS calibrated local open loop standard for all critical work - not the GPS output. Due to lightning considerations here is Kansas - my GPS antenna is in the front yard at 6 ft elevation and the N.E FOV is shielded by a 3 story house. Result is that the phase as plotted on a strip chart recorder is unchanging for hours relative to my Rb, but the flat plot shows phase jumps from time to time when the receiver shifts satellites. However the long term phase jump
Re: [time-nuts] Oscillator stability was (New NTBW50AA)
OT for the current heading, so I renamed it Oscillator stability as Tom says, it's a complicated subject. And to complicate things even further, here are a few of advanced subtleties that I've observed from the TBolt when using LadyHeather. 1) The TBolt uses the received GPS signal as the reference for the calculated OSC freq offset and the Phase offset, over a measurement time of 1 sec. Unfortunately, from second to second the GPS signal is very noisy. Fortunately, LadyHeather can display plots of the data with several helpful user options, such as gain, offset, and most important length of time averaged. 2) The Osc freq display plot of LH is so noisy that I find it mostly useless, unless I turn on LH's display filter to average the data over more than 1 second. LH allows you to manually turn-on and set the display filter to any time period desired, doing so this will greatly reduce the noise of the Osc plot. (10 samples is the display filter default, but I find 100sec to be a better place to start, for most things) A problem with the LH Osc freq plot even after filtering, is that the frequency difference data can not be counted on to be more accurate than a few parts in 1e-12 due to some offset rounding problems that often occurs. 3) On the other hand, the filtered Phase plot has no known offset error. The Tbolt accurately shows time/phase different between the 1PPS and the received GPS signal, and when disciplined, it assumes if there is a difference, then the GPS is always right. This is why the antenna placement and setup is so important. Gunk in, Gunk out. 4) The GPS signal, even on a 'perfect antenna', tends to wonders around ~10 ns PP independently of the time period averaged. So if LH is showing less than ~ 10 ns of GPS noise in the phase plot, it is because the control loop is set too fast and therefore forcing the Osc's freq to change a little so that it's phase will wonder around with the GPS's noise. Tbolt's max useable time constant is only 1000 sec, which is not nearly long enough to avoid this problem, when using a stable external osc like a good RB. To avoid tracking the noisy GPS data, the extended TC method must be used to set the Tbolt's osc to values 1000 seconds, and/or you can reduce the speed of the phase tracking using the damping setting.. 4) How well and how fast the Tbolt minimizes the PPS phase and freq offset compared to the received GPS signal all depends on tuning. The Tbolt's TC determines what the Frequency tracking time constant will be, and the TBolt's damping setting determines what the Phase tracking time multiplier is. If you set the damping factor to a large value like 100, then the Phase tracking will pretty much be turned off, making the disciplined loop more of a freq lock loop instead of a phase lock loop. This is done by lowering the gain of the loop's PID integrator. This is a way to set the phase's tracking time constant to be much slower than the freq TC setting, and if desired the phase tracking TC can be made several days long. Turning off the phase tracking has it's own set of pros and cons, but in most cases it is generally not desirerable in GPSDO. A damping setting of 0.7 to 1 will give the best overall compromise between the trade-off of not adding extra freq noise but still allowing good phase tracking. 5) What some do not realize is to correct for any phase drift error, the Oscillator must be set off frequency. When the frequency is correct there is no further change in the present phase, whatever the present phase may be or wherever it may of come from. The faster you want to correct or change the present phase difference, no mater how it got there, the larger that the present frequency error must be made. (this causes freq noise) The trade off is, if you do not correct the present phase error then the past average frequency will be in error. 6) So it is all a matter of what is more important to the application, present frequency error and noise or the average of all past frequency errors? The goal of most GPSDO is to keep the average past frequency error to zero. (a Phase Lock Loop) Where as for many transmitter things such as used by Hams, it is the present errors and noise that is more important. So no need to cause a present freq error just to fix something that happened in the past. The past is gone and what happened before does not matter anymore. (a Freq Lock Loop) ws *** - Original Message - From: Tom Van Baak To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] New NTBW50AA I get a spread of around 300ppt, that means I'm always within 300x10^-9 Hz of 10MHz or .0003Hz at 1GHz? Note 300 ppt is a fractional frequency, unit-less value, so at 10 MHz, 300e-12 * 1e7 Hz = 0.003 Hz at 1 GHz, 300e-12 * 1e9 Hz = 0.3 Hz I suppose the ppt spread is pretty much a function of how stable the osc is
Re: [time-nuts] New NTBW50AA
Dave With your GPS Antenna sitting underneath all those multipath reflectors (the other antenna's above it), That is far from optimal from a time-nut standpoint if you are trying to get the best performance possible. Should strive for no metal or reflective surfaces above the GPS antenna in any direction. ws * - Original Message - From: quartz55 To: Discussion of precise time and frequency measurement time-nuts@febo.com Subject: Re: [time-nuts] New NTBW50AA Thanks Charles, I'm not certain myself it it's the temp chip or the way LH handles the information. It doesn't matter like you say, there's no use doing any measurements with the unit unlocked. Otherwise here is a trace while I moved the antenna. Any comments on how it reacted in holdover? http://i251.photobucket.com/albums/gg287/DogTi/time/holdover_zps35d7e81b.jpg And here is where the antenna is now, this is looking straight north, so the sky behind me is nearly clear to the horizon and straight up isn't bad either. http://i251.photobucket.com/albums/gg287/DogTi/time/gpsant_zps2963365a.jpg Dave N3DT ___ 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] 10811 outer oven controller.
Charles sorry for the delayed answer, see below for why. I did my own thing for the outer oven controller. Mark C. S. was kind enough to redraw the schematic of what I made and post it on his site. http://www.vk2hmc.net/blog/?p=526 Do you know that often *your* postings do not show up on the time-nut listing I use at http://www.febo.com/pipermail/time-nuts/ Which is a shame because I find your responses interesting. I just saw your past question today by accident elsewhere. Strange enough, I've seen this a little with others, but yours has been the most noticeable. BTW your time-nut postings do show up other places. ws - Original Message - From: Charles P. Steinmetz To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, July 15, 2013 8:32 PM Subject: Re: [time-nuts] 10811 outer oven controller. Warren, Did you use an existing outer oven controller, or build your own? 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] TPLL linearity and other questions
David asked: Where does this non-linearity get corrected? What test modulation patterns could I use to verify and calibrate the [TPLL] gadget? What other tests would you recommend? Of course you could try and do some form of post data processing (before filtering), but the KISS answer for a high end TPLL tester is to just limit its lock range. I set up my TPLL circuit so that it can Phase lock only over ~ +- 2e-8 freq range and limit the analyzing range to around +- 1e-9 To calibrate, I use a 10 MHz source that can be offset by small known fixed freq amounts. First I zero the TPLL's DC output with exactly 10 MHz applied, then apply an offset of +- 1e-11, +-1e-10, +-1e-9 and finally +-2e-9. A Tbolt and LadyHeather makes a great offset reference generator for this. It is done by changing the Dac voltage while in holdover, using LH's filtered phase and freq plots to verify the amount of freq offset. To further check both DC and dynamic performance of the TPLL, I use a stable OXCO with known EFC gain at 10MHz and apply a small know attenuated signal into it's EFC at various waveforms, amplitudes, and frequencies. Only need a simple audio function generator and a TBolt to calibrate and verify that the TPLL is working correctly. TPLL advanced note: Have to be careful of anything that will roll off the response of the controlled or test oscillator's EFC input. Just the capacitance of the EFC's shielded cable of a dual oven 10811 is more than enough to screw things up if you are not careful. ws From: Tom Van Baak David, The 10811 linearity may not be that good rail to rail, but how linear is yours over the narrow EFC range you use during a stability measurement? I would expect it to be very good over any given interval of a few or tens of mV. /tvb ** From: David Hooke Subject: [time-nuts] TPLL linearity and other questions Hi All, I've built a measurement PLL along the lines of W. Riley's and Warrens's designs. It's working, but I have a hole in my understanding of them. The transfer function of the OCXO (10811-60159 in my case) is decidedly non-linear, implying that that the voltage output is also not proportional to frequency. Where does this non-linearity get corrected before analysis in either Warren's or Bill's systems? Also, without access to a 5062C as a noise source as some lucky folk do, what test modulation patterns could I use to verify and calibrate the gadget? I have an HP8662A, 3325A, 33120A and 8648C which I can rig together to generate various phase or frequency modulations. Simple FSK gives the expected square wave output (which is where I noticed the OCXO non-linearity). What other tests would you recommend? Also, I have 24bit, 192k sound cards which work down to around 1Hz. Are there any analysis packages I should look at to explore PN output, or is spectrum lab the best best? Thanks from a beginner. david ___ 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] 10811 outer oven controller.
The Tbolt LadyHeather plots in my posting are being used as a poor mans high resolution TIC tester as discussed at length in other postings, not for it's GPSDO output capability. This is a method that allows a time-nut person that does not have any of the high end equipment still the ability to do a lot of the high end state of the art time-nut testing. So in this case, it is valid to compare the results of the EFC changes with different types of ovens or even different oscillators such as for finding an oscillators tempco and ageing, as long as the plots are interpreted correctly, because the GPSDO tuning settings have very little if any effect on the long term EFC voltage plots. I have found that one of the largest variables in a GPSDO is the effect that temperature change has on the performance of the OCXO being disciplined. This makes the stability of the OXCO very much a non-constant, in fact temperature effect on the OXCO is the largest variable in many setups. That is why to achieve the best GPSDO performance, or even consistent performance between different runs when using a typical single oven GPSDO, one needs to build a brick house in the basement or put the OXCO under test in a temperature controlled environment such as a dual oven or LH temperature controlled S/W loop. All secondary temperature control devices have the same general goal which is to minimize or eliminate any fast temperature changes and therefore allow the GPSDO to take full advantages of the OCXO's then essentially constant intrinsic performance. Before doing any meaningful comparisons between single and dual oven GPSDOs or comparing the difference in optimal tuning settings, one must first define what the temperature environment is. If the temperature is not allowed to change then there is no difference. With a good dual oven set up, temperature change will have little or no effect, whereas with most time-nut available single oven oscillators including the single oven 10811, temperature variation is the first thing one needs to be consider before tuning for optimal performance. ws ** from Tom Van Baak (lab) tvb at leapsecond.com Mon Jul 15 12:22:38 EDT 2013 Ok, thanks for clarifying. In general the time constant one chooses must reflect both the intrinsic performance of the OCXO (essentially constant) and the realities of GPSDO mechanical, sky-view, and environmental conditions (possibly variable). Disabling an oven during a run is equivalent to a radical change in environment and not re-tuning the loop parameters will lead to sub-optimal or misleading results when plotted. If you have time, it would be instructive to re-run the experiment. First with double oven enabled and do your best case ws-tuning. Then disable the outer oven and again do a best-case tuning. The phase/freq/adev plots would be revealing, as well as the (major?) difference in optimal tuning values. /tvb (iPhone4) ** From: WarrenS Tom My posting and plot was only meant to show the difference in tempco between an undisciplined single and dual oven 10811 osc which in this case is clearly = 60 to 1. Your comments bring up a different subject which is who needs it and how good does a controlled GPSDO oscillator need to be when not in holdover. As you know, the purpose of a GPSDO control loop is to make the oscillator's long term stability relatively un-important. The longer the measurement time the less important the stability of the controlled osc is in a GPSDO, and as time increases past the GPSDO control loop time constant, the osc stability matters less and less What you are seeing and saying when analyzing the phase and Freq errors plots, is closed loop performance. The phase and freq plots of the dual oven osc would pretty look the same even if compared with a 'perfect' osc, because the dual osc plots is already near or at the noise floor of that TBolt setup and antenna. One can measure the longer term stability of an oscillator different ways; 1) Hold the EFC voltage constant and measure the change in frequency or phase with time. 2) Measure the scaled EFC change necessary to hold the oscillator's freq or phase output constant When done carefully and with the EFC voltage scaled correctly both ways can give the same answer. Answer1) The way I measured the two tempco's is by measuring the correlation between the EFC control voltage and the temperature plot In the case of the single oven osc, the plot gains are set so that when overlaid the EFC DAC plot looks as close as possible to the temperature plot. When the plot time is 24 hr and there is good repeatability, the TC is just the ratio of the two plot gains, i.e the effective EFC freq change divided by the delta temp. In the single oven case DAC plot gain = 1e-10 per division, temp plot gain = 1.5C per division. Tempco = 1e-10 / 1.5 == 6.7 e-11 / degC. I did the same thing for the dual
Re: [time-nuts] 10811 outer oven controller.
constant (800 s, 0.9 damping) optimized for outer oven
turned on case? Was it re-optimized for the outer oven off case?
/tvb
- Original Message -
From: WarrenS
Sent: Friday, July 12, 2013 6:04 PM
Subject: Re: [time-nuts] 10811 outer oven controller.
Bob said {the 10811 will run fine without the outer oven}
What I've seen is that a dual oven 10811 will run even **finer** and have
up
to 100 times less sensitivity to normal room temperature changes with a
simple outer oven controller and a few mods.
In 2010 I compared the performance of a TBolt using an external dual oven
10811 Osc with and without it's outer oven being controlled.
There was more than a 60 to 1 improvement in the 10811's freq sensitivity
to
small room temperature changes when the outer oven was active.
Open loop 10811 TC was 1e-12 /C with the dual oven on compared to 6e-11/C
with it off.
The green trace shows how much less EFC correction is needed to be to keep
the 10811's frequency constant when the dual oven is active.
http://www.febo.com/pipermail/time-nuts/attachments/20100223/c94d5eec/attachment-0001.gif
ws
*
- Original Message -
From: Bob Camp
Sent: Friday, July 12, 2013 10:45 AM
Subject: Re: [time-nuts] 10811 outer oven controller.
Hi
The outer oven on that version is simply a warmup heater. If it's
operating properly, it drops out in normal operation. Put another way -
the
10811 will run fine without it.
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] 10811 outer oven controller.
Bob said {the 10811 will run fine without the outer oven}
What I've seen is that a dual oven 10811 will run even **finer** and have up
to 100 times less sensitivity to normal room temperature changes with a
simple outer oven controller and a few mods.
In 2010 I compared the performance of a TBolt using an external dual oven
10811 Osc with and without it's outer oven being controlled.
There was more than a 60 to 1 improvement in the 10811's freq sensitivity to
small room temperature changes when the outer oven was active.
Open loop 10811 TC was 1e-12 /C with the dual oven on compared to 6e-11/C
with it off.
The green trace shows how much less EFC correction is needed to be to keep
the 10811's frequency constant when the dual oven is active.
http://www.febo.com/pipermail/time-nuts/attachments/20100223/c94d5eec/attachment-0001.gif
ws
*
- Original Message -
From: Bob Camp
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Sent: Friday, July 12, 2013 10:45 AM
Subject: Re: [time-nuts] 10811 outer oven controller.
Hi
The outer oven on that version is simply a warmup heater. If it's
operating properly, it drops out in normal operation. Put another way - the
10811 will run fine without it.
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] GSP clock stabilitiy, Rb vs Cs
All the data is in an adev plot... The cross overs will happen... you have to measure them. True, but then what do you do? It is not quite as simple or easy as it may sound. Although it is a good place to start, for best results in a GPSDO you can not just compare the ADEV crossover points of the two frequency sources. The problem I've seen is that long term ADEV plots generally show a turn-up, often around the 1000 sec range. The turn-up in the plot, more often than not, is caused by systematic errors, not random noise, so the turn-up may be scaled incorrectly by the ADEV plot. The things I've seen that can cause 'premature' turn-up on an ADEV plot are: Not allowing enough time for the osc to stabilize after turn on, room temperature variation, outliers and fixed rate ageing. With careful attention to many details, the turn-up can often be significantly reduced. The effect that each of these errors types have on various disciplined control loops varies greatly. The problem is when the effect that each of these errors has on a disciplined control loop such as a GPSDO is not the same as the effect that they have on the ADEV plot, you can not just use the crossover point of the two plots. The most extreme example is **fixed** ageing rate of the frequency source that is to be disciplined. A fixed ageing rate drift causes a slope of one turn-up on an ADEV plot (but has little or no effect on a Hadamard plot). On the other hand a fixed ageing rate error, which is often the major error of a good DOCXO, has no effect on frequency stability in a basic fixed time constant disciplined control loop such as used in a TBolt. It does cause a constant fixed phase error that is a function of the control loop's time constant and damping settings, but that can be removed completely if desired by just changing the control loop's cable length setting. On other types of disciplined control loops, the effect of a fixed ageing rate error may vary and depends on the type of advanced control loop used. The effect of temperature variation on a disciplined control loop is another big variation that can effect ADEV plots and disciplined control loops differently. In the case of a TBolt, delta temperature correction is only applied when the unit is in Holdover, so its effect has to be considered when setting up the GPSDO. This is why the best way to fix that error source is to not let the temperature change or to use a external DOCXO. Advanced control loops can greatly reduce the effect of changing temperature with feed-forward control, so they may not be nearly as sensitive to temperature variation. ws *** Hi All the data is in an adev plot. In this case short is 100 seconds, and long is 10,000 seconds. Those are rough numbers, since a really good Rb (like Corby's) may cross over a bit earlier. A really crummy Cs (low beam current) might not cross over for a couple of days against a well stabilized Rb or Maser. A good BVA OCXO will give the Rb a bit more of a run for it's money .. The cross overs will happen. Where is going to depend entirely on the specific individual standards you happen to have. If you are making decisions about which of your boxes to use, you have to measure them. Bob * On May 5, 2013, at 12:53 AM, Hal Murray hmurray at megapathdsl.net wrote: tvb at leapsecond.com said: Rule of thumb: quartz is best short term, Rb or H-maser mid-term, and Cs by far the best long-term. What is short, medium, and long? Radio astronomers use H-masers. Can I assume that they are mid-term and that H-masers are better than Rb (at mid-term)? Does the classic ADEV graph contain all the information, or is it making an assumption that is valid in most cases that allows it to compress/hide lots of information that is interesting for only a few obscure types of applications? ___ 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] Common-View GPS Network
is one better off just taking the simple route and tracking GPS time directly? My response is Yes, as long as you use the GPS to discipline a good Oscillator. GPS on its own is generally capable of about 10 ns of phase error, pretty much over any time period. So the longer you average the closer you know the frequency. I did some remote common view experiments a while back to see if I could find a way to improvement a GPSDO using low cost dual common view GPS. I used Tbolt GPSs, because they are capable of more than a decade better performance than the 1 ns (with correction) GPS engines (*). For monitoring I used Lady Heather so I could control and get real time data from the remote GPS. After several unsuccessful test using various remote locations, I got smarter and moved the Remote GPS under the same roof to see what the limitations where. I found the limitation was in my Antenna. (a 58532A type). That is when I used two antennas, even with everything at the same location, taking common view differences added noise. The only way I was able to improve the noise was to use the same GPS signal thru a splitter going to both GPS. Not real useful for remote Common View, so my experiment turned into a dual Tbolt DMTD. For some post I did, see Time Nuts back in Oct of 2011 from WarrenS and ws at Yahoo Common View Tbolt-Tic, DMTD using TBolts and Measuring ADEV using TBolt-Tic tester (*) The TBolt Engine is capable of 1e-11 at 3 seconds. and 1e-12 ADEV at 300 seconds using the difference between two TBolts driven with a common GPS signal, see: http://www.febo.com/pipermail/time-nuts/attachments/20111023/c84deb5b/attachment-0001.gif ws * Hello all. Having spent some time working over the last year on GPS time stability measurement, I'm keen to move onwards and upwards and have a go at common-view time transfer. While my receivers are in the post, I have thinking about my next direction. One thought that I have had is to try to write some software that can be used for real-time common-view (public if there is interest, but I am getting ahead of myself I think). My question to those in the know is whether they have found common-view to be useful over medium timescales (say, an hour or four). My understanding is that after a day or so the GPS signal itself becomes usable as a standard, so building a network is probably not tremendously useful over these sorts of time periods, but looking at such as figure 6 of [1], common-view should still be useful between a few minutes and hours. Has anyone here tried using such a method to produce their own short-term time scale, or is one better off just taking the simple route and tracking GPS time directly? Thanks, Lachlan ___ 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] Lady Heather numbers
Garren The 34 hr plot helps a lot to see what is going on. First off let me say what you have is working fine for most any real application, but if you want to be extreme time nuts, there are lots of improvements that can be made. In no special order. 1) Signal level is about 10 dBc lower than ideal, It is not much of an issue until other things have been improved. 2) The Dac Gain is still at the default of -5.0 Hz /V, Best to 'calibrate that. Again not a big deal yet. 3) The Damping is at the default 1.2, changing that to ~0.8 will reduced the Phase error considerably 4) The default TC setting (Time Constant) of 100 sec is about right for now, but later if you fix the Osc tempco issue, you'll improve things by changing that to ~ 300 sec (If you just changed the TC from 100 to 300 now it would make things worse) 5) change the ADEV data plot to a SAS antenna survey plot to make sure there are no blind spots or multipath signals The SAS plot will help tell where your EL and AMU should be set. ( they are set OK for now) 5a) The average sat count of 6 with a low of 4 shows your antenna has a good basic view of the sky. (no problem there) 6) your Holdover is still at 0 seconds, This is good, it means you never go into hold over. 7) Dac voltage at -.6xx is fine and seems to of stabilized well from your first plot that had a lot of initial turn-on drifting. 8) main problem and the first thing to improve, is the Oscillators tempco sensitivity. To better see it, manually change the gain and offset of the Temp plot, and you will see how well it lines up with the Dac plot. Trying to understand why the PPS trace is doing what it is doing. Looks like it might have something to do with the temperature. Correct, The PPS is doing what it is doing because it is tracking the slope of the DAC which in turn is directly tracking the Temp change of the sensor. Several ways to help it, how you do that with your dual temp control will be a nice learning experience. bottom line is: Don't let the temp change so much. and/or make the Osc less sensitive to the temp change other setup hints a) Helps if something goes wrong if you turn on Log so you do not loose the plot info. b) set the display Q to 30 days, so you can compare the before and after effects of any change you do, all on screen at the same time. c) turn off the ADEV plots and data display, They are not adding any useful info at this time. Have fun ws * Garren Davis posted: Warren, Thanks for the comments. I've included a 34 hour screen dump. Trying to understand why the PPS trace is doing what it is doing. Looks like it might have something to do with the temperature. I'm going to try a different GPS antenna and mount it higher this weekend. I'll do a 24 hour survey and start another run. After that I'll try a different power supply. Right now I'm using a PC power supply. It's probably a bit noisy. Garren -Original Message- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of WarrenS Sent: Tuesday, February 26, 2013 10:53 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Lady Heather numbers Can anyone comment on the picture. I don't know if what I have would be considered good as far as accuracy and stability is concerned. The screen dump is way too short to give much detail. What can be said from what is there: From a Ham standpoint it is all working fine and is much better than 1e-9. From a time nut standpoint it is very poor. It is using the default setting (for the most part) Phase error at -100ns is ~50 times high for the 100 sec TC setting used, (likely due to the high drift rate of the Osc) Frequency error is wondering around 1e-10 is about 50 times higher than what is possible. Effect on freq and phase noise with sat changes is 10 times more that what is possible with good setup. Concerning your Dac comments, Yes makes sense, but your conclusing is wrong. Can't say or sure, because the 24 Hr + screen shot is not shown, but in general The Tbolt temperature reading has no direct effect on the Dac control voltage unless the Tbolt is in hold over. The Dac voltage changes because the oscillator's freq is trying to change, not the other way around. You can disable the Dac from changing with dd. ws From: Garren Davis Subject: [time-nuts] Lady Heather numbers Hi, I have been playing with my thunderbolt and Lady Heather over the weekend. I hope it's ok that I attached a screen dump of what I have. Can anyone comment on the picture. It's been running less than a day and I don't know if what I have would be considered good as far as accuracy and stability is concerned. Thanks. Garren ** Garren Davis garren.davis at qlogic.com From looking at the graph over 24 hours it looks like the outer oven varies about +-.5C. This is from the tbolt
Re: [time-nuts] Lady Heather numbers
That should be that v360, Not dxxx to set the View Display time use space or ? for Tbolt help screens Garren posted I notice that whenever a satellite drops out it causes the oscillator white trace and the DAC green trace to jump around. I wonder why that happens when there are 6 other good satellites. The main causes of this is a poor location setting, (do a 24 + hr survey) or the TBolt is using data from some multipath satellite signals. To get more info on how your antenna is doing, can do a 24hr + signal strength plot (sas) To see more about your units performance, can change your display time from 1 min / div (17 min FS) to about 3 days full scale. ~(v360) (Not d360) I typically use 1 day / division for longer term displays (have to change the default 3days of data logging to 30 days using /qxx) ws ___ 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] Lady Heather numbers
Can anyone comment on the picture. I don't know if what I have would be considered good as far as accuracy and stability is concerned. The screen dump is way too short to give much detail. What can be said from what is there: From a Ham standpoint it is all working fine and is much better than 1e-9. From a time nut standpoint it is very poor. It is using the default setting (for the most part) Phase error at -100ns is ~50 times high for the 100 sec TC setting used, (likely due to the high drift rate of the Osc) Frequency error is wondering around 1e-10 is about 50 times higher than what is possible. Effect on freq and phase noise with sat changes is 10 times more that what is possible with good setup. Concerning your Dac comments, Yes makes sense, but your conclusing is wrong. Can't say or sure, because the 24 Hr + screen shot is not shown, but in general The Tbolt temperature reading has no direct effect on the Dac control voltage unless the Tbolt is in hold over. The Dac voltage changes because the oscillator's freq is trying to change, not the other way around. You can disable the Dac from changing with dd. ws From: Garren Davis Subject: [time-nuts] Lady Heather numbers Hi, I have been playing with my thunderbolt and Lady Heather over the weekend. I hope it's ok that I attached a screen dump of what I have. Can anyone comment on the picture. It's been running less than a day and I don't know if what I have would be considered good as far as accuracy and stability is concerned. Thanks. Garren ** Garren Davis garren.davis at qlogic.com From looking at the graph over 24 hours it looks like the outer oven varies about +-.5C. This is from the tbolt temperature sensor as the tbolt is in the outer oven. The inner oven where the oscillator is located holds at 66.4C. My concern is that it looks like the tbolt algorithm controls the DAC voltage depending on the temperature that the tbolt reads. Temperature goes up, the DAC voltage goes up. If the inner oven is holding steady then I don't want the DAC voltage changing if the temperature in the outer oven is changing. Is there any way to tell the tbolt algorithm to ignore the temperature in its DAC calculation? Wow, I hope this makes sense the way I explained it. Garren 8 ___ 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] Riley paper on Tight Phase Lock Loop
It would be nice if a real schematic and BOM was posted. it's like a big mystery ... /tvb As Adrian and Bob pointed out, W. J. Riley's site has all the information needed to make the higher cost TPLL version he did including his PCBs. The bigger mystery seems to be how easy a TPLL can be built without loosing performance. One version of the TPLL tester only needs 8 circuit parts plus + Power supplies etc, These are all clearly specified on the bottom block diagram, dated June 7, 2010 at http://www.ke5fx.com/tpll.htm And even that complete working, simple version, is good enough that the performance is still mostly limited by the HP10811 Reference Osc and not the TPLL circuit. BOM for Extra simple TPLL Nothing is critical, performance is determined by the Ref Osc. 1) Phase detector = SYPD-1 2) 100KHz LPF = two each 220 ohm in series and two 0.0047uf caps to gnd 3) Amp = OP-27 Pin 3 is input, pin 6 is output 4) Amp feedback gain = + 300 set using a 30K feedback and 100 Ohm resistor to gnd 5) 20 Hz LPF = 8K ohm series R and 1uf to gnd 6) Ref Osc = HP10811 7) A slow mv DVM and/or a 16 bit ADC sampling at 100Hz or more. 8) misc connectors, PS, S/W, etc. The configuration of the TPLL 1.0 that John tested, uses a 3dB and 5dB pad for isolation, (no real need for Osc buffers), and has a higher closed loop PLL bandwidth using an op37 with more gain, (a tighter TPLL) This can be seen by clicking on the underlined Here of John's report next to Fig 1.7 at Warren's annotated block diagram can be seen HERE. ws Hi Tom, Bill has actually published detailed schematics etc here: http://www.stable32.com/A%2010%20MHz%20OCVCXO%20and%20PLL%20Module.pdf Btw. what do you think about his small DMTD system? http://www.wriley.com/A%20Small%20DMTD%20System.pdf Adrian *** Tom Van Baak schrieb: Hi Bob, The TPLL method is described by NIST: http://tf.nist.gov/phase/Properties/one.htm A few years ago it was re-developed by WarrenS, a dedicated and frequent contributor to this list. See also John Miles excellent report: http://www.ke5fx.com/tpll.htm Or if that's dead, see http://web.archive.org/web/*/http://www.ke5fx.com/tpll.htm It's nice that W.J. Riley also tried it. If you know Bill, he makes us all look like amateurs. We know cases where TPLL works quite well; there are other cases where it doesn't. It would be nice if either Warren or John or Bill or anyone else posted a real schematic and BOM so that others could reliably duplicate, corroborate, refute, or refine their results. For some reason, it's like a big mystery; very unlike what we try to foster here on time-nuts: the free sharing of information, methods, experience, designs, results, and conclusions. /tvb * - Original Message - From: Robert Darby bobdarby at triad.rr.com To: time-nuts at febo.com Sent: Wednesday, January 30, 2013 10:32 AM Subject: [time-nuts] Riley paper on Tight Phase Lock Loop Gentlemen, I've been a lurker on this list since early in 2012. I do not possess a technical background but do have some interest in time measurement topics. I was reading some of W. J. Riley's papers and saw that after the long and contentious discussion on this list Mr Riley built and tested a tight phase lock loop system. I have failed to turn up any mention of his paper on this list and was curious if anyone has read it or perhaps duplicated it? He writes HP 10811 ovenized crystal oscillators are used as both the locked oscillator and PLL reference, and the system thus measures the combined instability of two presumed identical and uncorrelated devices. He further notes that These results agree well with other measurements for this type of crystal oscillator. The paper is found at: http://www.stable32.com/Frequency%20Stability%20Measurements%20Using%20a%20Tight%20Phase%20Lock%20Loop.pdf The construction is described in greater detail in a separate paper: http://www.stable32.com/A%2010%20MHz%20OCVCXO%20and%20PLL%20Module.pdf The OCVCXO and PLL Board described therein appears to be a very versatile piece of gear for anyone using 10811's. Riley gives an example using the module to clean-up the output of a LPRO-101 rubidium (page 9). Regards, Bob Darby ___ 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] 10 MHz - 16 MHz clock multiplier
Tom For simple, cheap, low performance and fast to build with junk box parts, hard to beat: What I made long ago for myself (before time-nut days). I still use it today for low end stuff, and it is all done with standard 74HC DIP parts. The main IC is a 74HCT4046 Phase lock loop with internal Osc. The internal osc output is divided by 16 using a 74HC93. The 10MHz ref is divide by 10 using a 74HC90 The two 1 MHz signals are feed into it's phase comparator. A couple of resistors and caps and I have a low tech 16 / 8 / 4 / 2 / 1 MHz tracking ref. With a couple of tweaks, I got the noise jitter down to a couple of ns as measured with a scope. 16 MHz is pushing the limits of the internal Osc, but I did not have any trouble getting there using less than the recommended osc cap. ws What's the simplest way to generate 16 MHz from 10 MHz? This will be for clocking a microcontroller at 16 MHz given 10 MHz (Cs/Rb/GPSDO). Low price and low parts count is a goal; jitter is not a concern but absolute long-term phase coherence is a must. The ICS525 (as in TAPR Clock-Block) is a good candidate but I was wondering if there's something cheaper, less functional, and maybe not SSOP. Any suggestions? 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] Thunderbolt oven / non-stable operating temperature
Guys, So much speculation on how the Tbolt uses it's temperature sensor data. Having spending hundreds of man hrs and thousands of Tbolt running hrs, testing all kinds of things to find ways to improve my Tbolt's performance. This is what I've found happens on My Non E TBolt with version#3 firmware, when in an indoor environment concerning it's temperature sensor. During normal operation my Tbolt uses the temperature and ADC data to in its Kalman filter that then can predict a simple linear temperature constant, and simple linear ageing rate. Starting from a factory reset, it has something it will use in under 1/2 day. If the temperature has not been thru a few cycles and /or the Ageing is still at a high initial cold start rate and still changing, the Kalman filter can give very poor results and actually make things worse. It gets better as time goes on, and after a few days with a predicable Osc, the Klaman filter will improve enough to help. But the **Only** time the Kalman filter is used is during Holdover. It does this by adjusting the EFC voltage in small steps making a simple linear ramp as a function of time, Plus a simple linear output as function of delta temperature. I've also found that if the Temperature chip is the new one that gives only about 1 deg of resolution, All still works the same, But during hold over instead of seeing small continuous DAC changes as temperature changes, you see Big EFC steps. It is a shame the Kalman filter is not also used during normal non holdover run time. With a more advanced PID control loop it could be made to work much better. As it is, because the known systematic error information is not used as a feed-forward term to help the PID loop, any temperature change or ageing that does take place during control has to be totally corrected by an error signal. In short this means there will be unnecessary errors caused by both changing temperature or time if the Oscillator is not perfect. The bottom line is, these errors then limits how good of control you get, and why the Tbolt should be in a stable, less than 0.1 deg /hr environment to get the best performance from it. (or can use LH's temperature controller or use an external double oven Oscillator) So what does this mean for the average Nut's Tbolt? Mostly nothing. The only time the temperature sensor has any effect is during holdover. If the Tbolt is going into holdover long enough for any of this to have an effect there are many worse things to be concerned about. If the Tbolt does not go into holdover, none of the aging rate or temperature data is used (except for an over temperature alarm). There is one exception that I have tested for: If the Tbolt has a high resolution temperature sensor and a good Osc where both the aging rate and the temperature TC are constant enough to be correctly modeled by the simple linear 1st order predictor used in its Kalman filter, then the open loop Kalman filter correction can improve the frequency accuracy over time by 3 to 1 or better during very long holdover periods like days. ws *** ___ 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] Thunderbolt oven / non-stable operating temperature
Another thing that could of effected the results when measuring the effect of a low resolution sensor chip during holdover, is that it is real hard for the Klaman filter to learn anything useful from it, without some careful manipulation of the variables. Mostly all it would normally record would look like seemingly random freq changes with no temperature change and then large temperature changes but with very little frequency change. ws Charles P. Steinmetz charles_steinmetz at lavabit.com posted Warren wrote: During normal operation my Tbolt uses the temperature and ADC data to in its Kalman filter that then can predict a simple linear temperature constant, and simple linear ageing rate. * * * But the **Only** time the Kalman filter is used is during Holdover. It does this by adjusting the EFC voltage in small steps making a simple linear ramp as a function of time, Plus a simple linear output as function of delta temperature. I've also found that if the Temperature chip is the new one that gives only about 1 deg of resolution, All still works the same, But during hold over instead of seeing small continuous DAC changes as temperature changes, you see Big EFC steps. That all sounds like the way it should work, if the temp sensor data is used internally by the Tbolt. My notes indicate that I tried cooling and warming the isolated sensor during holdover and observed no effect. However, the Kalman filter may not have been operating because I tested the unit immediately after it reached basic stability, before it had time to learn anything. So what does this mean for the average Nut's Tbolt? Mostly nothing. I agree. I presume that most time nuts would not ordinarily rely on a GPSDO during holdover -- particularly, a long holdover. 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] Thunderbolt oven / non-stable operating temperature
tvb posted Were you able to test how quickly, or how well, the filter learned the tempco of the OCXO? Only at a couple of very general data points. Using a very Bad unit, the Kalman filter had an effect, although not very good in under 1/2 day. After a week or so on a good unit, it helped maybe 3 to1 with ageing and Temperature TC. Yes (although please define much; are you talking 1% better or 10% better or 2x better). Much is a 2 to 10 times improvement in the errors cause the undesirable compensated effects. As an example, say your unit gives a 1e-10 freq ripple error when you turn on the over head Air condition, then that would go down by a factor of 3 or so. Of course you could also just move your unit away for the AC and get a similar improvement. For the best performance improvement, you do both. Would it be possible to implement this advanced PID in LH? Or as a first step, and to verify your conclusions, would it be possible for LH to control the DAC during TBolt hold-over mode? Yes, There is already a very flexible, but very user unfriendly 'prove of concept' version, in LH. It does have some of the feed-forward capability already there, along with lots of other things, as part of the many undocumented features of the external advanced PID controller now in LH. but I do not see a reason for using it during hold over, Because the Tbolt S/W already does a good job with that now. but the external PID does help the non holdover mode. LH's external PID even works remotely over the internet. So I have, in the past, controlled someone's Tbolt from my computer, getting better results than where available from the Tbolt's internal PID. (Works until the connection is lost). The terms I think that are available in the latest LH's internal PID controller are Phase error, Freq error, time, Dac offset, and maybe temperature. Basically for the feed-forward in hold-over mode, just need to add the sum of K1 x temp_change (since start of holdover) with K2 x lapse_time (since start of hold over) to the Dac value (since start of hold over) The hard part is to automatically find the best value for K1 and K2 during run time. In LH all the various variable K values are manually set. Last count I think the Advanced PID had 7 or 8 K's that could be tuned. I agree this is true in theory (where epsilon != zero), but it's hard for me to believe true in practice. I would guess the error term is totally dominated by short-term GPS noise, and anything else, like tempco or frequency drift, is secondary. That's why it makes sense to apply these 2nd or 3rd order corrections during hold-over mode (where there is no GPS noise) but not for normal operation. The reason it works even during normal operation is that the GPS noise is mostly plus and minus (basically AC), where as the time drift and temperature drift errors are in one polarity. When these AC errors are filtered thru the LP integrator of the PID, the GPS noise cancels but the DC time and offset errors, even though smaller than the GPS noise, tend to dominate short term. Short term being less than the PID's Time constant. ws Tom Van Baak tvb at LeapSecond.com Posted Hi Warren, Starting from a factory reset, it has something it will use in under 1/2 day. And that would explain my and Charles' null results. Nice. If the temperature has not been thru a few cycles and /or the Ageing is still at a high initial cold start rate and still changing, the Kalman filter can give very poor results and actually make things worse. It gets better as time goes on, and after a few days with a predicable Osc, the Klaman filter will improve enough to help. Were you able to test how quickly, or how well, the filter learned the tempco of the OCXO? It is a shame the Kalman filter is not also used during normal non holdover run time. With a more advanced PID control loop it could be made to work much better. Yes (although please define much; are you talking 1% better or 10% better or 2x better). Would it be possible to implement this advanced PID in LH? Or as a first step, and to veryify your conclusions, would it be possible for LH to control the DAC during TBolt hold-over mode? As it is, because the known systematic error information is not used as a feed-forward term to help the PID loop, any temperature change or ageing that does take place during control has to be totally corrected by an error signal. In short this means there will be unnecessary errors caused by both changing temperature or time if the Oscillator is not perfect. I agree this is true in theory (where epsilon != zero), but it's hard for me to believe true in practice. I would guess the error term is totally dominated by short-term GPS noise, and anything else, like tempco or frequency drift, is secondary. That's why it makes sense to apply these 2nd or 3rd order corrections during
Re: [time-nuts] getting a grip on 10811 drift (trying to read my instruments)
Hold the Up arrow down for 3 sec and put your counter into the 10 sec range. That will give you another digit of resolution. Now the LS Digit will be 1e-10 / count enough to test short term delta stability of many things. ws - Original Message - From: Chris Howard ch...@elfpen.com To: WarrenS warrensjmail-...@yahoo.com Cc: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Thursday, November 15, 2012 6:57 PM Subject: Re: [time-nuts] getting a grip on 10811 drift (trying to read my instruments) You all were right, my targeting of the 50 ohm resistor across the oscillator output does not seem to have solved the problem. A good thing to do, probably, but not the answer. While I was all excited about the resistor change I also mapped out the control voltage (EFC) vs frequency change. I wrote it out but didn't pay much attention. Now I've been pondering over that a bit. My next theory is that my EFC maybe isn't really doing very much. First I need to know if I am reading this right. My frequency counter is a Racal 1992 It reads 9.9997^6 as I write. A total of 9 digits with a smaller 6 to the right. If I read this correctly, I'm looking at 9,999,999.97 Hz ? If so, then I've got an EFC problem. My EFC mapping looks like this (this was done before I adjusted the coarse control) -4.94 VDC 9,999,999.95 -3.70 9,999,999.95 -1.24 9.999.999.93 0 VDC 9,999,999.93 +1.21 9,999,999.92 +2.44 9,999,999.92 +3.67 9,999,999.91 +4.90 VDC 9,999,999.90 It doesn't look to me like I am getting anything like 1/2 hertz range using the EFC. If that's the case than my controller card is frantically steering but not getting the desired result. Or, if I'm reading it wrong, maybe that last digit is 0-5 meaning 1/2 a hertz and I am all wet (again). This particular oscillator came out of an old HP counter and I believe the EFC was wired to ground. So maybe the thing has never been exercised. Are there versions of the 10811 that don't have EFC guts inside? Hope I'm not boring you all to death. Chris w0ep On 11/9/2012 11:26 PM, WarrenS wrote: Chris HP 10811 can't drift that much that fast unless something is near broken, or being connected wrong like gnds or PS voltage. Check the operation of the oven. ___ 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] getting a grip on 10811 drift (beginner-ishquestion)
Chris HP 10811 can't drift that much that fast unless something is near broken, or being connected wrong like gnds or PS voltage. Check the operation of the oven. It must be close and sort of working otherwise it would not be on freq as close as it is, but maybe it is drifting. The other thing to check is what it is being compared to. Are you sure it is the 10811 drifting and not your comparison reference? Also Triple check to make sure the input to the EFC is not causing a problem the way you are using it by grounding the EFC and count the cycle time for a beat freq. If the freq is close to your reference, Adjust the 10811 to get a beat freq between the two 10 MHz signals or use a scope and Sync on the reference osc and time the drift rate of the 10811 osc a few times a day to see if the drift rate is changing. A position change on the scope of 1ns /sec = 1e-9 freq offset, 1ns /10 sec is 1e-10, etc. If all you have for comparison is a 1 pps from an unknown if working GPS's 1pps, then sounds like it is time to get something else to break the tie to see which is really broken. With the high freq drift rate of 1Hz that you are seeing, you could use a wwv receiver. ws * [time-nuts] getting a grip on 10811 drift (beginner-ishquestion) Chris Howard Fri Nov 9 21:53:39 UTC 2012 My perpetually drifting 10811 pretty quickly made it to the negative voltage rail on the control voltage. I was looking at the oscillator output with an O-scope and it looked pretty nasty. My equipment is not so hot, so I first chalked that up to bad probes. But I did some google work on that and found an old time-nuts message thread about the 10811 looking bad if the output impedance is bad. The VE2ZAZ board has provision for a 50 ohm resistor on the oscillator output. I have one on the board but it is a little-bitty thing, maybe 1/8th of a watt? Something I probably got from the guts of a VCR or whatnot. Hmm. So I put in a 1/4 watt 50 ohm resistor (like the parts list called for). My working hypothesis is that the small resistor was changing impedance due to heat. I have reset the control voltage to center value and got the coarse trimmer all beautifully centered. It's been running for about a day and I am hopeful that I've made a difference. So far so good. While I was interrupting the flow of 10 Mhz, I also mapped out the control voltage and corresponding digital control value and an approximate frequency. You EE guys are probably snickering and will want to tear the epaulettes off my time-nuts coat and break my sword. What can I say. ___ 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] getting a grip on 10811 drift (beginner-ish question)
Chris QI can measure the control voltage change over time and convert that into a frequency drift? Yes, no problem as long as the discipline loop is working OK. It is very easy to plot the oscillator's long term drift per day, by just plotting the filtered analog EFC control voltage. Typical 10811 EFC sensitivity I've seen is 0.25Hz / volt QIs this type of behavior an indication of dire problems with my 10811 oscillator? Depends how long it has been runing. A high ageing rate per day is typical for a Oscillator that has not been used for a while. Depending on the size of the step, If you still have the same problem after running continuously a few weeks, The dire problems may have more to do with your control loop tuning method than the 10811. If the 3 hr integrating time is also the update cycle time, then no wonder there are 'large' steps at each update. 10K sec is too long of an update rate to get the best performance from a HP10811. As an example, good settings for a TBolt when disciplining an external HP10811 is about 1000 sec integration time with an update rate of once per second. Generally it is better to use small steps and update the EFC voltage more often, maybe more like one per minute, and then reduce the overall feedback gain to increase the control loop time constant until it is around ~1000 seconds One of the easy ways to improve most everything, is to limit how much EFC voltage change you allow. After the oscillator has been running a few weeks continuously, a total change of well under 1 volt at the EFC input is plenty, when there is a manual course frequency adjustment, like in the HP108111, that can be used to set the EFC control voltage to the center of it's range . ws [time-nuts] getting a grip on 10811 drift (beginner-ish question) Chris Howard chris at elfpen.com I built a GPSDO using my own power supply, a VE2ZAZ board, a Trimble Resolution T GPS and a surplus HP 10811 oscillator. I'm having a bit of trouble with it. I have it set up and it locks ok and stays in lock so far. But the recommended long-term integration setting is not working for me. I think it is about 3 hours. At the end of every cycle it does a control voltage adjustment, always in one direction. If I understand it right, the oscillator is slowing and needs an incremental bump downward of control voltage every time. That seems like it is more than just long term drift. But I don't have my head around the quantities I'm looking at. I can measure the control voltage change over time. Can I convert that into a frequency drift? Or do I need to stop the voltage adjustments and allow the drift to occur then do a measurement of that directly somehow? Is this type of behavior an indication of dire problems with my 10811 oscillator? Chris Howard w0ep ___ 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] getting a grip on 10811 drift (beginner-ish
Maybe need to define Correctly True, It sure helps if one has lots of nice test equipment around to start with, but Then again if one already has the better test equipment needed to be able to quickly test a new GPS, then there would not be much reason to be building a home built thing. because none of test equipment stated is actually needed to make and test your own home built GPS disciplined oscillator. With a little care and a lot of time, It can be done without anything very special by just Bootstrapping up with home built things. ws Azelio Boriani wrote: Guys, be aware, first of all, that to correctly test your new GPSDO you need an already running GPSDO as a reference (and a 10 digits-per-second interpolating counter). Don't forget/overlook the reference: start always with a known, good reference. *** On Mon, Nov 5, 2012 at 9:12 PM, WarrenS wrote: Chris QI can measure the control voltage change over time and convert that into a frequency drift? Yes, no problem as long as the discipline loop is working OK. It is very easy to plot the oscillator's long term drift per day, by just plotting the filtered analog EFC control voltage. Typical 10811 EFC sensitivity I've seen is 0.25Hz / volt QIs this type of behavior an indication of dire problems with my 10811 oscillator? Depends how long it has been running. A high ageing rate per day is typical for a Oscillator that has not been used for a while. Depending on the size of the step, If you still have the same problem after running continuously a few weeks, The dire problems may have more to do with your control loop tuning method than the 10811. If the 3 hr integrating time is also the update cycle time, then no wonder there are 'large' steps at each update. 10K sec is too long of an update rate to get the best performance from a HP10811. As an example, good settings for a TBolt when disciplining an external HP10811 is about 1000 sec integration time with an update rate of once per second. Generally it is better to use small steps and update the EFC voltage more often, maybe more like one per minute, and then reduce the overall feedback gain to increase the control loop time constant until it is around ~1000 seconds One of the easy ways to improve most everything, is to limit how much EFC voltage change you allow. After the oscillator has been running a few weeks continuously, a total change of well under 1 volt at the EFC input is plenty, when there is a manual course frequency adjustment, like in the HP108111, that can be used to set the EFC control voltage to the center of it's range . ws [time-nuts] getting a grip on 10811 drift (beginner-ish question) Chris Howard chris at elfpen.com I built a GPSDO using my own power supply, a VE2ZAZ board, a Trimble Resolution T GPS and a surplus HP 10811 oscillator. I'm having a bit of trouble with it. I have it set up and it locks ok and stays in lock so far. But the recommended long-term integration setting is not working for me. I think it is about 3 hours. At the end of every cycle it does a control voltage adjustment, always in one direction. If I understand it right, the oscillator is slowing and needs an incremental bump downward of control voltage every time. That seems like it is more than just long term drift. But I don't have my head around the quantities I'm looking at. I can measure the control voltage change over time. Can I convert that into a frequency drift? Or do I need to stop the voltage adjustments and allow the drift to occur then do a measurement of that directly somehow? Is this type of behavior an indication of dire problems with my 10811 oscillator? Chris Howard w0ep ___ 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] HP 10811A failure
Sounds like another source of this confusion is that there is more than one version of the HP10811 inner heater circuit. Where as most 10811's start loosing performance at around 15 volts on their inner oven. I have one 10811, that was taken out of a dual oven version, that maintains full temperature regulation with under 10 volts on its inner oven circuit. When I opened them up, the main difference I saw was: On the unit that needs the higher heater voltage, the circuit is as shown in the manual's schematic, U2 = 10 V and R17 = 10K. R17 is used to reduce the bridge voltage to ~ 5V. On the unit that works at lower heater voltages, R17 = 0 Ohms, and U2 has a 5V output. Both circuits give the same 5 volts across the bridge, and both where set to operate at approximately the same temperature and both had similar factory temperature trim resistors in them. BTW the 10811's outer oven will work fine with under 10 Volts on it. I drive mine from a simple home built linear temperature controller. ws ** On 10/14/2012 1:19 PM 8:30 AM, Richard (Rick) Karlquist wrote: 12V for the oven because inside the outer oven lives a 10811-60158 ( see http://www.realhamradio.com/GPS-oven-journey.htm ) that, as by the specs sheet, is specified 12 to 30 V DC, 11 W max. at turn on (mine draws some 9 W), and Steady state power drops to approximately 2 W at 25°C in still air at 20 V (mine draws some 1.9 W at 12 V without powering the outer oven). This is surprising to me. Can you give us a citation to this spec? AFAIK, all 10811 ovens are the same, and the ones I have looked at sort of work at 15V, but they don't really work properly on 12V. One source of confusion is the case of the 5334A counter. The power supply IMHO is poorly designed and the voltage sags down to 12V during 10811 warm up. (All 10811's and 10544's are guaranteed not to draw more current than a 47 ohm resistor). It turns out that you can count on the 10811 oven to function sufficiently at 12V to turn on the heater transistors and get the oven warmed up. After the oven warms up, the current drops back and the 5334A power supply voltage gets back up over 20V. This is different than saying that it is OK to just connect a 10811 heater to a constant 12V supply. ... ___ 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] ADEV drop
The basic problem is that one can not meet Allan's requirement of the integral of the instantaneous frequencies over tau0 time and Nyquist-Shannon sampling theorem requirement if taking just one raw phase sample per displayed ADEV tau0. The two requirements are then mutually exclusive. This is especially true when that sample is coming from a DTMD zero crossing detector. The way I get ADEV tau answers that do not droop at all near tau0, and that are independent of the displayed tau0, the oversample rate and the NEQ.BW filter (if BW 2* tau0) without having to throw away the low tau answers or save data files with more than tau0 number of samples, is by oversampling the raw data and then reducing it in an appropriate way before saving it as tau0. With high speed oversampling it is also very simple to avoid any aliasing problems. Using an external DC coupled sound card, oversampling at 48KHz for any tau0, both the TPLL2.0 and the XOR-LPD give non-drooping tau0 answers that are not a function of the oversample rate or the tau0 reduction rate. That is, get the same ADEV tau 1sec answer if the tau0 is 1KHz, 1Hz or anywhere in-between. ws Fellow time-nuts, As David insisted that I get and then read the ITU Handbook Selection and Use of Precise Frequency and Time Systems (1997) and in particular Chapter 3 I took the time to get it and start reading it. In there I found clause 3.3.2.4.4 Truncation effects, which addresses this issue, which also aligns up with my own writing on Allan Deviation, and the Measurement bandwidth limit (I will have to update that one). The key point is that the main lobe of the kernel function (the way that the sin(pi*tau*f)^4/x^n look), will be affected by the system bandwidth and values will be not matching up to the brick-wall analysis of the traditional system. The result will be that the ADEV measure will be lower than it should. This situation was analysed by Bernier in 1987 as part of analysing the modified Allan deviation, which has a software bandwidth filter in the form of the n*tau_0 average filter. So, the first low n values is even expected to give systematic low values, which is the reason for the ITU-T to put minimum requirements on the tau_0 to lowest tau to ensure that repeatability is achieved. This is also the same effect that Sam Steiner mentioned in his presentation during this years NIST seminars. Sam also went on to discuss the effect of aliasing, which helps to bring even more false values in that region. Conclusion: Just don't look all that hard on the lower tau values, as they can be systematically off. Make sure that you have a tau_0 well below the taus you are interested in to ensure that your values is reasonably valid. 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] Active antennas for a Thunderbolt...
Have you used Lady Heather to automatically set the Default settings? To allow the Tbolt to work with weak signals from any antenna that I've tried, even when indoors, I start by setting the TBolt's AMU level from the default of 4 down to 0. This can be done with the Tbolt S/W or LH. My general AMU setting goal is to make it low enough so that the TB is always using a minimum of three satellites. If the TB ever does goes into holdover, that should be fixed, because that will cause some serious freq offset noise at the TBolt's output, The usual holdover fix is to give the antenna a better view of the sky and/or lower the TBolts AMU setting. It is better to set the AMU too low which will allow it to use weak signals all the time than it is to set it too high and have No signals even for a short time. After lowering the AMU value, if you want to optimize the setting, LH has all kinds of tools to help, such as the sat signal strength plot. ws ** cfharris at erols.com said: I suspect that I have just had the bad luck to buy two bad antennas, but I am naturally curious what happens when the sample set gets larger. I have 2 TBolts using the small Motorola antenna from TAPR in a not-good location. The sheet says 24 dB of gain. I have 6 or 9 or ?? feet of RG-6. They work as expected, that is they work, but not well. The holdover logic gets tested frequently and surveys take a long time. But they do work. ___ 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] Trimble T Lassen 2
And here it goes again for about the umpteenth time, how to detect the presents of a short low rep rate pulse. This can be done with ANY analog scope by using the normal trigger mode and setting the trigger correctly. An analog scope can detect the presents of any short pulse no matter how low it's rep rate is, so long as the pulse is wide enough that it is in the scope's (trigger) bandwidth. Under 5ns for a 100 MHz scope. So detecting if there is a very short pulse even once every 10 or 100 seconds sec is NO problem. Now measuring how wide the pulse really is, that is a problem for an analog scope. ** Wow, that is indeed narrow. Only 1us out of a 1 second rep rate. That is one millionth of the rep rate. No wonder analog scopes will not catch it. I'll have to try it some time. Regards The pulse from my T-Bolt is on the order of 1uS wide. I captured it on the digital scope for posterity and future reference. *** I was fooled by this too. My analog scope does not sync on the 1Hz pulse. You have to breadboard something that will detect it, maybe a flip flop and then look at the FF's output. * ...And don't forget that the PPS pulse is very narrow so you have to use a 'scope with memory, a digital 'scope or turn the brightness at max. ___ 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] Trimble T Lassen 2
That works when there is a trigger LED, OR Just need to slow down the sweep rate to say 10ms / div or slower and then there will be a nice clear, easy to see, can't miss, white line, across ANY scope with each pulse when the scope is triggered by a short low rep input pulse. * My old '465 will trigger on the 1pps, but it's far easier to see the trigger LED flash than finesse the brightness/sweep to make it visible - something possible only on a 'scope with a decently bright tube. ... * Most scopes that I've used have some sort of indication if they are/aren't getting triggered, so even if you can't see the pulse you can tell if there is a pulse there. ... it helps to run in Triggered mode rather than Auto. Works fine in Triggered mode as long as you are happy without seeing anything when the trigger doesn't happen. * This can be done with ANY analog scope by using the normal trigger mode and setting the trigger correctly. An analog scope can detect the presents of any short pulse no matter how low it's rep rate is, so long as the pulse is wide enough that it is in the scope's (trigger) bandwidth. Under 5ns for a 100 MHz scope. So detecting if there is a very short pulse even once every 10 or 100 seconds sec is NO problem. Now measuring how wide the pulse really is, that is a problem for an analog scope. ** Wow, that is indeed narrow. Only 1us out of a 1 second rep rate. That is one millionth of the rep rate. No wonder analog scopes will not catch it. I'll have to try it some time. Regards The pulse from my T-Bolt is on the order of 1uS wide. I captured it on the digital scope for posterity and future reference. *** I was fooled by this too. My analog scope does not sync on the 1Hz pulse. You have to breadboard something that will detect it, maybe a flip flop and then look at the FF's output. * ...And don't forget that the PPS pulse is very narrow so you have to use a 'scope with memory, a digital 'scope or turn the brightness at max. ___ 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?
Only for the Nuts, ZCD have been discussed at great length this time and before, and bandwidth can be a major issue, but still much is being left out. With a little care, one can easily get to 1ns type accuracy, with the various suggestions, but that only gives 1e-9 / sec of accuracy, not even close to what is needed so as not to degrade the short term accuracy of a basic OCXO like a HP10811. For that it takes sub-picosecond type phase / time stability and repeatability, and to get to that level, it takes a whole lot more considerations. If you want to see how bad things really are, try and check out the sub-picosecond drift that even a very small temperature change or signal amplitude change can have on any of the Schmitt triggers or the suggested multi-stage band-limited ZCD designs. ws *** Good, I've learned also that bandwidth can matter and that a ZCD test can done by comparison: feed the counter or TSC or TimePod or 'scope with your source signal and 2 cables, then insert the ZCD and see the difference. Actually I'm interested in a ZCD to feed the FPGA from the OCXO, I'm using a 74HC04 with feedback followed by a regular 74HC04. On Sat, Jul 21, 2012 at 4:15 AM, John Miles jmiles at pop.net wrote: I see that from one way or the other, we always end up in a TimePod. OK, then the TimePod has no comparator, no trigger but has A to D conversions. Is the A/D conversion process supposed to be threshold-free? Hey, everybody needs at least one or two TimePods. :) You can use a TimePod or TSC 512xA to measure additive jitter, or for that matter a mixer and a delay line. But these instruments will all do the job by making a phase noise measurement, then integrating the plot to find the equivalent RMS time jitter. This means that you'll have to decide what limits of integration you want to use. A counter, on the other hand, will give you the total jitter seen across its entire front-end bandwidth, so there is less thinking involved. The trouble is, any good shaper or ZCD will have very low jitter, perhaps too low for even a Wavecrest-class TIC to measure. This is what Wenzel's quick-and-dirty differential amp with a pair of 2N3906s looks like, when the splitter test mentioned by Bob is performed with a TimePod, TSC or other phase noise analyzer: http://www.wenzel.com/documents/waveform.html http://www.ke5fx.com/wenzel_shaper_resid_jitter.png That's about 100 fs of additive jitter, measured between 0.1 Hz and 100 kHz. Because the broadband floor is relatively high, a great deal of the total jitter comes from the higher decades. (The circuit's jitter contribution between 0.1 Hz and 100 Hz is only about 10 fs.) A counter will not be limited by the 100 kHz or 1 MHz integration range of a TimePod or TSC 5120, so you might see enough jitter to be noticeable on a Wavecrest in the 1 to 10-ps neighborhood. But maybe you only care about jitter at lower offsets... in which case the counter will make your shaper look a lot worse than it really is. For instance, if the reason you're investigating ZCDs is because you want to build a DMTD, then you may be more interested in a residual ADEV plot instead. The pair of bipolars contributes white and flicker PM noise, so its residual ADEV at t=1s isn't too different from the residual jitter in the ADEV measurement bandwidth, which was 500 Hz in this case: http://www.ke5fx.com/wenzel_shaper_resid_ADEV.png It's worth noting that I made these measurements on a TSC 5120A. The phase noise measurement could have been made on a TimePod, but the residual ADEV plot could not, as it's below the TimePod's ADEV floor. To me, this says that there are better ways to spend one's time than designing a fancy multistage ZCD. The important thing is to consider how much bandwidth is really required in your application, and whether/how it should be limited. -- john, KE5FX Miles Design LLC ___ 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] Holding Phase constant
Two part question: I'd like to test the effect of small signal level changes on the phase output of a high resolution linear phase detector at ADEV values below 1e-16 and tau 1000 sec. I'm looking for suggestions on how I can manually vary the signal amplitude of one of it's 10 MHz sine wave inputs by up to say 3 db with ~0.1 db step size, while keeping the signal's phase constant in the sub 0.1 picosecond range. Is there any data available on how much the signal amplitude of a LPRO Rubidium Oscillator or a HP10811 class Oscillator changes over temperature and time when driving an exact constant resistive load? ws ___ 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] Why 9,192,631,770 ??
It is interesting that the leap seconds correction is always a positive number. But less so now than 40 years ago according to: http://en.wikipedia.org/wiki/Leap_second So does that mean the earth is speeding up? Maybe the cause is all the DARK ENERGY out there speeding everything up :) A good and simple explanation of why they CHOOSE to make the second wrong is at:. http://www.nist.gov/pml/div688/leapseconds.cfm There are two main reasons that cause leap seconds to occur. The first is that the duration of the atomic second was measured and defined by comparing cesium clocks to the Ephemeris Time (ET) scale, an obsolete time scale that defined the second as a fraction of the tropical year. The duration of the ephemeris second was slightly shorter than the mean solar second and this characteristic was passed along to the atomic second. If the atomic second had been defined with respect to the mean solar second, it is likely that leap seconds would have been required much less frequently. The second reason for leap seconds is that the speed of the Earth's rotation is not constant. It sometimes speeds up, and sometimes slows down, but when averaged over long intervals the trend indicates that it is gradually slowing. This gradual decrease in the rotational rate is causing the duration of the mean solar second to gradually increase with respect to the atomic second. ___ 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] Interesting paper: Don't GPSD' your Rb...
Magnus wrote: It's sad that they have not described the control algorithm in greater detail. I have to ask WHY?? The paper is So low tech, It is hardly worth reading, let alone wondering how it is done, IF the goal is to learn something a bit advanced. Maybe I'm just missing the satire here. I see nothing there that is anything more than a beginner's first project. The paper is disciplining a RB Osc using a very poor GPSDO and an overkill high end counter. ~ by averaging the Phase difference over n time, use that to change the freq of a RB using a 16 bit dac giving about 1e-14 frequency steps. This is not a paper about Don't GPSD your RB, as the nut subject line suggest. It seems a better subject line would of been DON'T discipline your RB with a GPS THIS WAY! Seems like a pretty lame way of doing it to me. ws ** - Original Message - From: Magnus Danielson mag...@rubidium.dyndns.org To: time-nuts@febo.com Sent: Saturday, May 05, 2012 3:33 AM Subject: Re: [time-nuts] Interesting paper: Don't GPSD' your Rb... On 05/03/2012 11:29 PM, Poul-Henning Kamp wrote: This is pretty think, but interesting: http://tf.nist.gov/sim/Papers/Trigo_CPEM_2010.pdf I interpret this as a GPS slaving of the rubidium. Given that there is fairly high stability in both sources, the comparison rate does not have to be stellar. It's sad that they have not described the control algorithm in greater detail. 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] Question about precise frequency / phase measurement
Wolfgang asked Does anybody know a possibility to get a resolution 1 mHz ? (in 1 second) The goal is look for frequency deviations caused by external influences ... A silly question to ask time nuts. :) How good do you really want it to be? 1 mHz out of 10 MHz in one second is only 1 part in 1e-10 and needs a resolution of 0.1 ns For a high end example showing external influences causing small freq variation, see the swinging OSC test at http://www.thegleam.com/ke5fx/tpll/swing.gif This has a resolution of ~0.01 mHz (1e-12) at ~100 Hz update rate, which is about 10K better than what you have asked for. Many of the high end suggestions you are getting is how to do it 100 plus times better than what you've asked for. Yes, plain old HC parts and some care can get you resolution and repeatability below 0.1 ns when averaging for one second. For something pretty simple, see Bruce's XOR Linear Phase detector page at, http://www.ko4bb.com/~bruce/LinearPhaseComparators.html I made a version of that using 74AHCxx parts that gives ~1 mHz freq difference resolution at 100 Hz update rate. For really high end, simple, low cost, with no digital parts, there is a 2.0 version of the TPLL with resolution of 1e-14/sec. That is capable of near 1mHz resolution with an update rate of 10K/sec. Information on TPLL version 1 is at http://www.ke5fx.com/tpll.htm ws snip I want to monitor the frequency deviation continuously (that means: i don't want to look at a scope ;) and log the data several times per second. The goal is not to make a 'quality test' of the oscillator, but to look for frequency deviations which are caused by external influences of various kind. The question is, if 74HCxx parts would be good enough to get 1 mHz resolution for a 10 MHz frequency with an update rate of 1 sec. Regards, Wolfgang Hello @all, my name is Wolfgang and i'm new to the list. :) I browsed through the list archive, but i didn't find the infos i need, so i decided to join the list and to ask the experts directly. :) I want to measure the frequency difference between a 10 MHz OCXO and a 10 MHz Rubidium. I think that's what many people here have done many times... but i don't want to use expensive equipment like time interval counters with picosecond resolution etc. I would prefer a cheap and easy solution. I also would like to have an update rate of more than 1 measurement per second, or even more. My first approach was to use a simple XOR phase comparator. I tried a 74HCT86 and a 74HCT4046. It works, but it's very noisy, so i don't get better than about 10 mHz frequency resolution. If i look at the lowpass-filtered output i don't see a nice sine or triangular wave, but it looks more than a triangular wave with round tops and some bumps between them. Another problem is that the difference frequency gets very low when the frequencies are very close, so it's not enough to look only for zero crossings of the difference signal. Does anybody know a possibility to get a resolution 1 mHz ? Best regards, Wolfgang ___ 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] How best to exchange Large files?
Recording high speed and/or long general purpose raw Osc data, the file can become very large. I'm looking for a simple, fast and easy (and cheap) way to transfer large compressed data files of up to say a 100 MB between time-nuts. I know there are all kinds places one can store large files that others can then have access to, so I do not want to use the OLD way of breaking it up into many small pieces. I do not need to do this very often, so I do not want to sign up for any long term thing or maintain a Friends or face book type thing, I'm just looking for an easy, temporary way (say lasting up to a week each) to transfer a few big files that are too large to email. Suggestions anyone? Thanks ws *** ___ 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] How best to exchange Large files?
Bob Worked great for my long zip file, and a large. jpg Thanks very easy to use, this will be very helpful to me. still a little problem, It would NOT take my short .gif file unless I falsely renamed it with a .jpg extension ws Bob Smither smither at c-c-i.com Bob Smither wrote: After some changes, I was able to upload a 30 MB file with no problem. I will try a larger one later today. I just uploaded a 119 MB file - so the exchange page http://www.c-c-i.com/exchange/ seems to be working. -- Bob Smither, Ph.D. smither at c-c-i.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] How best to exchange Large files?
Bob The gif files upload OK now but the ones with funny non standard names will not download for me. can you tell me which character it does not like? ws * [time-nuts] How best to exchange Large files? WarrenS wrote: Bob Worked great for my long zip file, and a large. jpg Thanks very easy to use, this will be very helpful to me. still a little problem, It would NOT take my short .gif file unless I falsely renamed it with a .jpg extension Thanks Warren! Should be fixed now. -- Bob Smither, Ph.D. Smither at c-c-i.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] Update on Rb Performance
John said in part; ignore the last two (ADEV) plot points as there isn't enough data for them to be very meaningful. you need a lot more than 10 days data to draw any real conclusions; IMHO, ADEV is not the right tool or even a very useful tool for evaluation the long term performance of these Rb Osc. Whenever possible, best to record the Raw data so other tools, such as available in TimeLab can be used to better compare the different Rbs. I have to wonder how many others notice ADEV's severe limitation in its able to reliable predict even 1 day in the future from 10 days worth of past data. Where as, ADEV is a great tool for measuring 1 sec noise, It is a poor tool to use for predicting future 1 day errors. This is especially true when the majority of the errors are due to measurable systematic things such as ageing and tempCo, as is the case with these Rb oscillators. This seems like a case of using the wrong tool for the job. ADEV's usefulness and power is its ability to predict future errors from past random Noise. For this, it helps to have at least a 10 to one and preferable a 100 to one ratio of raw data to tau. Because of the randomness of Noise, in order to get good consistent ADEV results, The larger the ratio of recorded data to tau the better the answers. So to get a good consistent 1 sec ADEV answer, best to have 100 seconds or more of raw data. To get good 1 day ADEV answers from noisy data, would need to have 100 or so days worth of raw data. One of the ironic things of trying to use ADEV plots to predict long term future errors, is that during the 100 days of recording raw data, the systematic things that are causing the errors will have likely changed enough that the raw long data run may still be near useless to predict future errors over even the next day or two using ADEV. The ratio of time that raw data needs to be collected compared to future predicable time, can be greatly improved by using any number of more appropriate tools. By using something rather than ADEV, taking 10 days worth of the right data, one can then better predict the next 10 or even 100 days in the future when the major error sources are systematic rather than Random. from http://en.wikipedia.org/wiki/Allan_variance The Allan variance is intended to estimate stability due to noise processes and not that of systematic errors or imperfections such as frequency drift or temperature effects ws - Original Message - From: John Ackermann N8UR Subject: Re: [time-nuts] Update on Rb Performance Hi Warren -- for these tests, I wasn't capturing raw data, just using the tables and graphs that come out of the TSC box. John * On Feb 18, 2012, at 11:57 PM, ws at Yahoo John If you have the raw phase data, can you post a plot of what the well filtered freq offset looks like over that 10 day period? I've have found a properly filtered high resolution freq vs. time plot provides a lot more useful information than the couple of data numbers of a ADEV plot for evaluating long term performance of an Osc and helps separate all the many different possible causes of poor ADEV numbers. This is because then one can see the shape and magnitude of the Freq drift, therefore being able to see if the freq drift has a short term cycle due to temperature or if it is linear due to ageing or 2nd order due to still stabilizing or if it contains freq jumps due to 1/f flicker, or a single large jump due ...etc, etc. To be of any long term use, the freq data must be filtered over a long enough time period, such as a 1 hr running averaged, so the plot is more than just the 1 sec noise shown on most freq plots. ... ws John Ackermann N8UR jra at febo.com This isn't the real long-term stability test I'm planning to do, but I did let the measurement continue on the last unit I was testing (an Efratrom FRS-type) out to 10+ days, which should give fairly reasonable data out to 100K seconds. An ADEV plot is attached. I would ignore the last two plot points as there isn't enough data for them to be very meaningful. Bottom line is that Efratom specs the FRS units at 1e-10/day, and this one seems to do more than an order of magnitude better. But also looks like you need a lot more than 10 days data to draw any real conclusions; you can look at this plot and think that the ADEV is maybe heading back down after a peak near 1e-11. 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] Testing a LPRO RB
In additional to the standard ADEV answers, Two important additional performance numbers to consider when testing and evaluating a RB Osc, are its TempCo, (as in freq change per degC) and its Ageing rate, (as in drift rate per day). Anyone with a spare TBolt can measure them. One simple method to measure the generally elusive Temperature coefficient and the ageing rate of a high end Osc like the LPRO Rb is by using a TBolt-Tic and LadyHeather. Attached is the LH screen dump showing the results of a 7 day run in which a LPRO is being disciplined using a TBolt that has been modified for use with a external Osc. see http://www.ke5fx.com/tbolt.htm The Dac Plot, in the attached screen dump, shows what the LPRO's EFC needs to do to keep the LPRO's freq and phase tracking the GPS over the long term. From this Dac plot it is easy to see what the LPRO's tempCo is as well as what it's ageing rate would be if the unit where allowed to go open loop and be undisciplined. With the room temperature changing around +- 1 degC, this units TempCo is around 3 e-13/degC, which is measured by adjusting LH's temperature plot so that it tracks and overlaps as close as possible the Dac voltage plot. The 1 week average drift rate shows a very surprising and optimistic ageing rate of 7e-16/day, over this special selected time period, as verified by measuring the slope of the Dac's trend line. This is a standard LPRO in the open on a desktop, which is just sitting on top of a simple heatsink. As of yet, I have not made any effort to try and get the best from this LPRO or protect it from changing room temperature. (the house heater goes on at 7am and cycles somewhat throughout the day and night) As can be seen, even over this limited +- 1 deg temperature range, the change due to temp is by far the dominate error factor. The first thing this LPRO needs, to bring it up to nut standards, is the addition of a simple temperature compensating circuit. At these LH's setting where the temp and Dac plots are made to overlap, One Dac div = 0.33e-12 freq offset, One Temp div = 1.102 degC, so TempCo = 0.33e-12 / 1.102degC. LH's reported aging rate is 6.8e-14 /day which needs to be divided by 100 because I'm running the unit in the x100 extended TC mode. (To fool the TBolt's S/W tracking time constant so that it will be slower, I've told the Tbolt that the Dac gain is 0.36Hz/V when in fact it is only 1/100 of that) The H/W setup I'm using to disciplined this LPRO's is done by connecting the LPRO's external C field EFC input thru a 221K 1% resistor, which gives a measured Dac sensitivity of 1e-10 freq change for a 280mv Dac change. This equals 0.0035Hz /Volt for this LPRO setup. 28mv for 1e-11, 9,333uv in the Dac = 3.3e-12 of freq offset per division for the DAC plot. (resolution is 4e-15 / Dac count) I set the Tbolt's gain to +0.36 Hz/V to give it the x100 extended TC range (because the TC needs to be more than the otherwise maximum useable 1000 secs). The 30 sec TC setting I use causes an effective tracking TC of 3000 sec and the 8.0 damping factor setting gives an effective 0.8 damping factor. (1/sqrt_extended_gain) (The Tbolts tracking TC can be set from 10 seconds (using 0.1 sec) up to just over one day (using 1000 sec) with this x100 extended configuration.) Now set the elevation and AMU, (with this antenna I use 20 deg and 6.5 AMU), and do an extended LH plot until a weeks worth of stable, repeatable data is obtained. If the plot shows that the unit is unstable or has not yet stabilized fully, cleanup the settings where necessary and continue plotting, until you get a weeks worth of consistent data. There is another description of how to discipline a LPRO using a Tbolt that has a bit more details. http://www.febo.com/pipermail/time-nuts/2011-May/056526.html http://www.ko4bb.com/dokuwiki/doku.php?id=precision_timing:lpro_disciplining_with_thunderbolt a 1ms to 1000 sec ADEV plot of a typical LPRO is at: http://www.febo.com/pipermail/time-nuts/attachments/20111006/46ca3fbc/attachment-0001.gif and http://febo.com/pages/oscillators/rubes/ ws ** attachment: LPRO#2-2-15 (1).gif___ 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] LPRO Rubidium Performance
To get the most from ADEV numbers one needs to be able to get repeatable and reproducible results. To get that at short taus the tester needs sub ps resolution. To get it at long taus, all uncontrolled variable influences that effect the results (such as temperature) need to be removed and plotted separately. What I've seen is that the LPRO's ADEV turn up at long taus, for the most part, is caused by either the unit's ageing still settling down or some temp fluctuations or barometric pressure changes happening during the run. I've seen that even the natural slow daily temperature cycles can cause an ADEV turn up at around 1 hr (3000 sec) if the temperature is not controlled or compensated for or removed with post processing. I have compared John A's green LPRO ADEV plot taken with a 5120A and posted at http://febo.com/pages/oscillators/rubes/ with the red blue LPRO plots I did using a TPLL2.0 posted earlier at http://www.febo.com/pipermail/time-nuts/attachments/20111006/46ca3fbc/attachment-0001.gif Both LPRO plots are within about 10% of each over the whole range from taus below 1e-2 to taus above 1e+2 I find this encouraging and somewhat amazing considering they where done on two completely different systems with different references, at different times, and different locations, on different LPRO, by different people. The ADEV difference of about 6 db at 1ms tau can be explained by the fact that if I apply a 500 Hz LP filter to my 9600 sps raw data, the same filter used on the 5120A's 1K sps data, then even our 1ms ADEV answers become very close. I have found that using a 1/2 zero tau BW filter like the 5120A does can falsely lower its tau zero ADEV answer by 3 to 6 dB. The 5120A's use of a 1/2 tau zero LP cutoff filter is why the 5120A ADEV answers are generally not the same at Tau zero when sampled at different tau zero rates. The difference between our plots at 1k seconds is because the dual oven HP10811 reference osc I'm using is not as good as the LPRO or John's HP5065A reference for long term stability. The ADEV data can not be any better than the Reference Osc used, but still interesting that the 10K and 20K sec numbers from the my red LPRO plot nearly match John's green LPRO plot. Note that the last decade of a ADEV plot can get quite variable as shown in my test where I'm plotting different sections of the SAME data run. My green and violet plots show the results of plotting the SAME 60K sec data run (618K data points) in 3 and 30 segments using one of TimeLabs useful capabilities. Can a plot be convincing? To get the kind of matching seen in John and my plot over the full range of taus needs everything to be working right. ws ___ 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] Entering Altitude for Thunderbolt
John I have Not seen any reliable consistent way to predict what the Tbolt will use for it's altitude, It seems to just do it's own thing. It is certainly NOT the same as the Oncore's answers. To get close and see if the different is 30 meters etc, take the Tbolt out of fixed location and watch it's reported location for a while and then you add whatever correction that seems closest to your others altitude. For self check, If you get any of the Tbolt's locations wrong, It will do large Phase jumps as the sat switch. If its is happy with it's location settings, and there is a good antenna signal there will be almost no sudden phase jumps as sat change. ws * [time-nuts] Entering Altitude for Thunderbolt John Ackermann N8UR jra at febo.com That's an experiment I should run, but the current experiment requires setting the Tbolt to the same coordinates as the other units, so I'm just looking to do that. :-) On Feb 12, 2012, at 12:42 PM, David C. Partridge david.partridge at perdrix.co.uk wrote: Or even better get Lady Heather to do the 48 hour survey. Dave -Original Message- From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On Behalf Of Azelio Boriani Sent: 12 February 2012 16:31 To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Entering Altitude for Thunderbolt Let the TBolt do its autosurvey ___ 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] Low-Cost Rubidium Performance
Indeed, ADEV is for random freq variation not easily measured by other means. Temperature fluctuations do not cause random freq changes and the temperature's effect should be removed if one wants accurate long term ADEV numbers. Even daily diurnal cycles due to temperature can have major negative effect on ADEV numbers as low as 2000 to 3000 seconds, and if there is an Heater or AC cycling, then any ADEV numbers about a few hundred seconds can be due to TempCoeff, which should not be measured with ADEV or included in ADEV plots. This is much the same as a single outlier data point that can screw up the whole ADEV plot and make it pretty much meaningless and unrepeatable. Ditto for linear ageing, Should be remove first if one wants true ADEV plots. ws *** [time-nuts] Low-Cost Rubidium Performance Bob Camp lists at rtty.us Thu Feb 9 11:58:27 UTC 2012 Hi Past 100 seconds I have seen some FE's that look better than your LPRO plot and some FE's that look worse than your FE plots. Running in a +/- 2C room apparently is not the best way to operate them for good long tau performance. 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] good ADEV data (was Low-Cost Rubidium Performance)
you follow a A*ln(B*t+1) curve which isn't matching the requirement, so you will only get first degree compensation of that with HDEV style measures. Temperature variations is tricky to say the least. When you have random and systematic effects, separate them and estimate them separately and then build a combined prediction from these models. Random jitter and deterministic jitter are two such aspects. Same applies at longer taus as well. Cheers, Magnus Hi Warren -- JimL responded before I did, making pretty much the same point -- I think ADEV is a tool to measure performance in the environment that you want. If you want to measure the best-possible performance of a device, you want to control for all external factors. But if you want to see the real-world performance, you want to measure in the real-world environment. FWIW, these tests were done in my basement lab. I don't have my temperature monitoring stuff set up yet so don't have data, but the furnace isn't cycling too frequently, and there is relatively little air flow from the registers into the area (the thermostat is upstairs and we just bleed a little air into the basement). We don't do a huge amount of day/night setback at this time of year, so I suspect that the temperature is remaining stable within 2 or 3 degrees C. I suspect the seasonal variation is greater than the short term. But on the project list is getting several temperature sensors installed to feed a data logger... On the very long term project list, I'd like to climate control my clock room to maintain better than 1 degree C, but that one is down the road. John A ** From: Jim Lux Interesting point you make here. The rising ADEV at 100-1000 second-ish tau in a system that should be better is a classic sign (at least around here) that temperature effects are showing up. However, how could one remove that effect from the raw data? And isn't the measurement of the system, which includes the environmental effects. I suppose you could run your widget in a temperature controlled chamber, get those numbers. Then run it in a less controlled benchtop environment, and get those numbers, and claim that the difference is environmental. But at some point, what you're interested is the performance of the system in the environment in which it will be used. If you need good ADEV performance at the 1000 second tau, then you need an oven, a vacuum bottle, or a better design that's less environment sensitive. (difference between TRL6 and lower, for those into such things) ** From: WarrenS warrensjmail-...@yahoo.com Indeed, ADEV is for random freq variation not easily measured by other means. Temperature fluctuations do not cause random freq changes and the temperature's effect should be removed if one wants accurate long term ADEV numbers. Even daily diurnal cycles due to temperature can have major negative effect on ADEV numbers as low as 2000 to 3000 seconds, and if there is an Heater or AC cycling, then any ADEV numbers about a few hundred seconds can be due to TempCoeff, which should not be measured with ADEV or included in ADEV plots. This is much the same as a single outlier data point that can screw up the whole ADEV plot and make it pretty much meaningless and unrepeatable. Ditto for linear ageing, Should be remove first if one wants true ADEV plots. ws *** Bob Camp lists at rtty.us Hi Past 100 seconds I have seen some FE's that look better than your LPRO plot and some FE's that look worse than your FE plots. Running in a +/- 2C room apparently is not the best way to operate them for good long tau performance. 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] FE-.5680A trimming resolution ( TBolt)
Chris asked: LH reports the signal at 40dB, +-2dB. Is that good enough? Good enough for what? The TBolt can be setup to work with that, but it could certainly be much better. With a good Tbolt antenna setup you should see about 50 db for overhead birds and in the high 40's for the lower ones. With an indoor puck antenna I see mostly in the low 40's, and it still works OK, IF the Tbolt is set up for the lower signal level. More important is the Antenna signal strength variations plotted over the whole sky which LH can do. Look for low signal areas due to obstructions in the SAS plot and small delta signal strength blips in the SAD plot due to multipath cancellations. ws * - Original Message - From: Chris Albertson albertson.ch...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Monday, January 30, 2012 11:52 AM Subject: Re: [time-nuts] FE-.5680A trimming resolution On Mon, Jan 30, 2012 at 10:43 AM, Mark Sims hol...@hotmail.com wrote: These are 4-BYTE single precision floating point numbers, not 4 bit integers. They are the values plotted in the Lady Heather PPS and OSC graphs Sorry I type faster than I think. You are right they can't be four bits. I work in rocket telemetry, you'd think I'd get this straight. I write software to unpack this kind of stuff. A much better approach is to minimize the system errors with a GOOD antenna, accurate position survey, proper oscillator control parameters, and temperature stabilization (of both the receiver and power supply)... Lady Heather is willing to oblige on the last points. A good Tbolt implementation can get the PPS plot to under a few nanoseconds of error. I've done this. I see values in the single digit nanoseconds. I have a timing antana on a mast on the roof. Perhaps I could get a better timing antenna and low loss coax lead. LH reports the signal at 40dB, +-2dB. Is that good enough? I've seen adev plots from an Oncore MT12 (www.leapsecond.com/pages/m12-adev/) where these error estimates are added in or not and they get maybe 20% better with the corrects applied.the MT12 produces error estimates about that same size as a T-bolt. The data looks noisy on LH's graph because of the scale of the graph. Compared to the 1PPS it is a smooth function. 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] 5680A update
to Chris What I've seen is that holding 0.1 C AT the SENSOR is pretty easy, (Lady Heather will hold the TBolt's sensor to 0.01 deg using just a fan), AND if you blow a lot of air around, then keeping the air gradients inside a closed 'oven box' below 0.1 deg is also NO problem. to Bert Have you measure what the Temperature coeff is over normal room changes with and without the addition of the temp controller? What is the best configuration to keep the fe5680 freq constant? For the LPRO, what I found by experiment worked best for me is to place the unit upside down so the heat sink was on top. If any air was blown on the non heat sink side, that would greatly effect the frequency stability in a bad way. A way to get around the compromise of where the best place is to put the sensor, either close to the heat source or close to the device. Best answer is BOTH. The way to get high end control and a much more stable control loop, is to use TWO temperature sensors. Put one temperature sensor near the Heat source and a second one at the place you want to hold constant. Then in effect 'AC couple' the heat source sensor, so that it does the course temperature control. One way to do this is to set it up so that the heat source sensor is the feed-forward or D input for the main sensor PID control loop. Another way to set it up is so that the device sensor's error slowly changes the temperature set-point of the heat source's temperature control loop. ws *** I am, as I reported previously using a SMD LM335 away from the fan and held down with a screw and a small bracket and I get consistent .1 C. I do not think that I would get 1 E-12 over weeks when my lab has seen more than 5C temperature changes if my temperature readings are not correct. Do not forget this was a quick and dirty setup, the final product will look more professional. Bert Kehren * albertson.chris at gmail.com writes: On Tue, Jan 17, 2012 at 8:38 AM, EWKehren at aol.com wrote: I am using a fan that holds it within .1 C Its been month since I measured it but I did report it here and I think it is 42.7C. 0.1C is very good for just using a fan. What is the fe5680 mounted to? just the heat sink or is there a thick metal plate. Also what are you using as a heat sensor. Is the sensor press fit to the heat sink or.I do remember reading about your temperature controlled fan but not the 0.1C part. I'd have guessed you could only do about 2.0C with a setup like yours. 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] Thunderbolt? (re simple gpsdo.) capacitors
Yes almost as long as you include ONE more Resistor, R2 added below. The dual cap thing does not get rid of leakage entirely, but close enough in most cases. That configuration is most useful for slow open loop filters when you want low leakage errors. It may be a bit of an overkill for a closed loop filters when a 10 % leakage would be tolerable. I tested a 10,000 sec TC filter using a 10 meg and 1000 uF, and got under 1% leakage error open loop. ws *** [time-nuts] Thunderbolt? (re simple gpsdo.) capacitors Poul-Henning Kamp phk at phk.freebsd.dk The leakage current noise I measured was way below insignificant when things are properly scaled. Couldn't the double condensor from voltage references trick be used to eliminate the leakage entirely ? [Some op-amp] -+-R2-+-- | | | - | - | | +---||---+ | - - | GND -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 ___ 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] Thunderbolt? (re simple gpsdo.) capacitors
this thread has wandered a bit. The thread was originally for Simple... Bottom line is that electrolytic caps can be made to work fine for a SIMPLE analog controller built for home NUT use, Not recommended for space or critical life support applications, or any production thing. Besides putting the crappie RC inside a closed loop the other thing that seems several are missing is to limit the correction range. If one sets up the simple loop to give say a 100 to 1 improvement, then all the other concerns become non-issues. The noise created by the leakage current in an electrolytic will be an issue outside the loop bandwidth and only will be reduced by the available gain... Loop Gain is not a problem when making a frequency lock loop, even with a P only controller, using any kind of phase detector because the gain is infinite. The leakage current noise I measured was way below insignificant when things are properly scaled. Such as when you scale it so you only care about a 1% of 5 volt change and not uv. If you're depending on a specific time constant for a SIMPLE controller using electrolytic caps then the problem is the design and not the caps. If you're want to make a 1e-10 to one correction with a simple controller the problem is not the cap but the configuration and the expectations. But making a 1e-13 correction to a 1e-9 Rb is no problem (1000 to one improvement) Hal Murray Posted: I'm not interested in the frequency shift of the filter as the temperature but the voltage shift due to a fixed charge as the capacitance changes. Interesting question, so I tried it. No effect on the One I tested. I charged a cheapie 1000uf, 50V cap to 5 volts then changed it's temperature which did changed it's capacitance and leakage, but had no effect on it's charge voltage. I guess the charge is not Fixed, so not the same thing as changing the value by paralleling the cap. ws ** [time-nuts] Thunderbolt? (re simple gpsdo.) capacitors Bob Camp lists at rtty.us Hi No argument there, but this thread has wandered a bit. If you are depending on the capacitor to provide a specific time constant, then you will have issues. If the control loop is not impacted by the changes, then they will track out. Often it's not quite an either / or, but a some of this and some of that. In any case the noise created by the leakage current in an electrolytic will be an issue outside the loop bandwidth and only will be reduced by the available gain... Bob *** On Behalf Of Chris Albertson Hi Using electrolytic caps in timing applications is a bit exciting. Their leakage current changes each time you change the voltage on them. It's enough of a change to significantly impact long time constants. In some cases the capacitance changes with voltage as well.. In general you are right. But in this case the electrolytic cap is inside a closed loop so as the temperature changes and the voltage in the cap changes, the loop will correct it, as long the temperature changes slowly compared to how frequently we measure the phase of the PPS signal. You could always place the entire system inside box and control it to a constant temperature. 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] Thunderbolt? (re simple gpsdo.)
Hal posted:
For those who aren't familiar with this trick, it's easy to make a low pass
filter in software:
X = X*(1-k) + k*new orX = X - k*X + k*new
OR
Gives exact same results using only one multiply,
New_X = Last_X + k * (New_data - Last_X)
OR
For powers of square root of two 1.414 steps, which is close enough for GPSDO
control loops using only shifts can add:
New_X = Last_X + [ { (New_Data + 1/2* New_Data) - (Last_X + 1/2*
Last_Data) } divided by 2^N ]
I think the main problem in this area is building a low pass filter with a
long time constant.
Not At ALL, That can be the easiest part as long as it is in a CLOSED LOOP
system where accuracy is not very important.
As you stated, with digital filters you can go as slow as you want as long as
you do not let it loose LS_Bits when shifting and adding.
How do I build an analog filter with a time constant that long?
The TC filter is inside a loop so Most all the bad things that slow poor analog
filters do does not matter much at all.
100 meg and 10 uf Tantalum capacitor can work fine as a 0 to +5V, 1000 sec
analog filter inside a loop.
I've found that a 10 Meg resistors and most small, 10 cent ,1000uf caps work
fine for a closed loop 10K sec TC filter.
What's the input impedance of a VCXO or Rb unit? I assume we will need an
op-amp to buffer the filter.
No buffer usually needed, most are pretty Hi_Z, and many are floating inputs
such as the HP10811.
MOST of the time, for SIMPLE the best results are obtained by highly
attenuating the EFC input so high value filter resistors can be used.
The other thing that helps a lot is the less the EFC feedback gain the lower
the RC time constant need be for the same effective loop time constant.
example of simple and high performance:
Say you need a 10,000 second time constant analog filter when using the full
+5 to - 5V EFC range of a disciplined HP10811 osc.
You can get the same 10K sec Loop time constant using a +5 mv to -5 mv EFC
range and a 10 second filter time constant. (and a manual freq offset
adjustment)
Can make that using a couple 20 meg resistors, center taped with a 1uf cap (10
sec TC), connected to the EFC with a 40K ohm to ground (plus a RF bypass cap)
You get a 10,000 sec effective loop Time constant, low noise system that can be
controlled just fine with an 8+ bit dithered Dac, to performance a nut would
want.
There has been many postings of all sorts of possible bottle neck problems that
are true when making a overly complicated Rube Goldberg kind of nut
controller.
BUT for 'SIMPLE' with a little thought and compromise, most of these do not
need to apply, therefore they are not an issue even at the highest performance
levels.
ws
***
[time-nuts] Thunderbolt? (re simple gpsdo.)
Hal Murray hmurray at megapathdsl.net
Sun Jan 1 01:56:46 UTC 2012
As soon as you say Software the device is no longer simple.Even a
microprocessor is a very complex device and so is its development system.
The software inside the uP is not simple either if you count the number of
possible paths through the code (2 raided to the power of the number of
branches.)
Yes and no...
Software doesn't have to be big, bloated, ugly, and complicated. (But I agree
that it often is.)
This looks like fun to me, but I like writing that sort of code. Note that it
doesn't need an OS or even any libraries.
The context for simple wasn't well specified.
Does simple refer to design or construction?
How good does the GPSDO have to be? (After all, this is time nuts.) What sort
of adev at what sort of time scale?
I think the main problem in this area is building a low pass filter with a long
time constant.
The time constant of the filter has to be:
long relative to the noise from the phase detector
short relative to aging of the oscillator
short relative to environmental changes
(so the osc can track temperature and voltage
those changes may be in the PLL system rather than the osc)
If we are starting with PPS (rather than 10KHz), the filter time constant
needs to be 10s or 100s of seconds. How do I build an analog filter with a
time constant that long?
What's the input impedance of a VCXO or Rb unit? I assume we will need an
op-amp to buffer the filter.
The ugly problem in this area is that time constant to filter out phase
detector noise overlaps the time constant needed to let environmental changes
through. That doesn't matter if the filter is analog or digital.
If the osc is stable (Rb) filter time constants of 1000s of seconds might make
sense. That might help take care of some of the hanging bridges.
For those who aren't familiar with this trick, it's easy to make a low pass
filter in software:
X = X*(1-k) + k*new
or
X = X -k*X + k*new
where k is less than one. Smaller k makes a slower filter.
If you pick k as a (negative) power of 2, the multiplies can be done with a
shift so there is nothing complicated
Re: [time-nuts] Thunderbolt? (re simple gpsdo.)
Here is another analog control example based on the quick and dirty example below. It is a simple and Very poor GPSDO Rb design as far as noise jitter goes because of the nonlinear and high Phase detector gain, and high 1e-8 noise jitter on the PPS, but still no problem to do with cheap basic parts. Given: 1) LPRO Rb with a + - 1e-9 range analog tuning range plus an internal freq adj pot with the same range. 2) 1pps GPS control signal with 10 ns noise at 1 second 3) Desired 1e-11 GPSDO jitter at one second 4) Total Attenuation needed from phase detector to EFC input 1000 to 1. Can be a combination of resistor and cap. 5) Use a 74HC74 D Flip-Flop phase detector whose 1ns sensitivity is good enough because it is much less than the 10 ns control signal jitter. 5a) 1 sec control signal to FF clk in, 10MHz divided by 100 using a 74HC390 to the FF D input (100KHz will give a 5us range before jumping a cycle) 6) limit range of fine EFC control input to + - 1e-10 freq change with resistor divider, and use the LPRO's course adj pot for course freq setting. 7) If Rb phase is before the control signal the 5V FF Q_not output will drive the Rb freq 1e10 lower in freq (1ns/10 seconds) 7a) if the Rb phase is later than the control signal, the 0 volts of the FF Q_not output will drive the Rb freq 1e-10 higher. 8) LPRO Rb EFC input Z is 50 Kohm with a 0 to 5V control, designed to be left open when not in use so resistor noise is not an issue (best to add a RF cap to gnd) 9) Output the FF thru a 10 sec low pass prefilter RC using 10K and 1000uf cap to give a 10 sec average of the 10ns phase noise 10) Feed the Rb EFC from this RC thru two 250K ohm resistors in series to give a 10 to one attenuation (500K to 50K) 11) Add the main slow LP filter as desired to the center of the 250K res center tap, with small resistor in series with a big cap. 12) use = 1000uf cap for 100 sec + TC, = 100 to 1 cap attenuation Plus 10 to one resistor attenuation = over all 1000 to one jitter attenuation Maybe no free lunch, but total controller cost can be under a dollar. Note that all the crappy LP filter RCs that many seem to be most concerned about are all Inside a closed loop, so their poor, less than ideal performance does not mater so long as the cap leakage is not so great that they never charge. ws * Hi For some designs (like a Rb) the time constant may be in the days range.. Even for something simple, you can easily get out to several thousand seconds. You also need low noise past the cutoff time (for short times the cap may help you). That's going to get you into resistor noise and / or op amp noise. All of this will push up the capacitance required. Quick and dirty example: 1 pps comparison setup 10 ns jitter on the GPS ( 1x10^-8 at one second) 1x10^-11 as the desired GPSDO jitter at one second. . you need 1,000X attenuation of the jitter at one second. With a 1 uf cap, that's gets you to pretty noisy resistors. Most TBolt's are quite happy doing the sort of thing in the example. 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] Thunderbolt? (re simple gpsdo.)
Chris Here is a GPSDO I built that better fits Your definition of Simple. I used this as my freq standard before getting a TBolt. 1) Feed the PPS output of an oncore GPS timing engine which has 1 Hz or better yet 100 Hz output to the clk of a D FlipFlop (74HC74) 2) Feed the FF's D from a 10 MHz osc which has been divided down to 100KHz or less using 74HC390. The FF output shows if the Phase of the Osc is greater or less than the GPS signal and the FF will toggle back and forth when the phases are near equal due to the typical 40 ns jitter on the GPS pulse signal. 3) Add a RC filter to the FF output using a big cap, so the voltage out of the RC filter is 0 to 5 volts depending on the duty cycle of the FF. (A small R in series with the cap will help stabilize it if a real Big cap is used). 4) Feed the filtered analog FF output voltage (No buffering necessary) to the EFC of an 10 MHz osc that has its EFC input desensitized with a couple of Rs and has been set to be real near 10 MHz at the nominal analog FF's 2.5 volts output using the Osc's mechanical tuning and/or add a fine freq adj pot. A couple basic ICs and a few Rs and Cs and you're done. This makes a basic PI controller that will cause the 10MHz osc to track the GPS PPS. The less you make the Osc's EFC tuning range the better this works, and Once it is tracking you can fine tune the freq adj pot every now and then to keep the Filtered FF voltage at near 2.5 volts if the Osc tends to drift outside of the control range. Not very high tech and there are Lots of possible ways to add more parts to improve it further, depending on what your goals are and how much you want to learn about GPSDO and PID control loops. If the definition of simple is less parts and more programming you can replace all the active parts with a simple PIC and get better performance by controlling the Osc's EFC using a software PID and PWM with an external RC filter as the Dac. ws Chris Albertson albertson.chris at gmail.com Sat Dec 31 06:01:38 UTC 2011 On Fri, Dec 30, 2011 at 10:16 AM, Hal Murray hmurray at megapathdsl.net wrote: Software. As soon as you say Software the device is no longer simple.Even a microprocessor is a very complex device and so is its development system. The software inside the uP is not simple either if you count the number of possible paths through the code (2 raided to the power of the number of branches.) I have nothing against software, that is what I do for a living, every day. But you can't count a uP with software indise as simple. And the point of this exercise is to find the simplest thing that can still work. 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] Thunderbolt? (re simple gpsdo.)
Chris posted: What level of performance did you get? Correct it depends on what parts you use and how nutty you want to get. So much also depends on how you define performance, and where you want to compromise. Compared to WWV and WWVB it was much better, Compared to a correctly set up TBolt much worse. In a NUT-Shell, It is good of enough for most any REAL non-Nut application. Ball park numbers: Freq error of 1e-8 is simple, 1e-9 is easy, 1e-11 gets hard without some good parts and lots of care to details. Besides the GPS engine and the Osc, The time period the freq is averaged over is an important factor, because of the jitter. If you do not loose sync, like all GPSDO, over a long enough time period of many days or weeks, it is good enough to check and calibrate ANY Osc, because it can be set up so that there is NO long term accumulative drift, just short term freq jitter. just one flip-flop, divider and a capacitor. AND some resistors I'm looking for a controller that is much more like the bimetallic spring thermostat. For a Bang bang type two state controller like your bimetallic example, you don't even need the cap which is added to filter out freq jitter. Take out the filter cap, scale and adjust things right and what it does is if the freq is less than the GPS, when the FF toggles it will raise the freq above the GPS and then when the phase matches, it will toggle back and lower the freq below the GPS. This will continue forever keeping the AVERAGE Osc Freq dead nuts on bouncing back and forth between a couple frequencies in what then becomes a PWM like function of the OSC bouncing between two frequencies, one higher and one lower than 10.000 MHz. The freq step size and jitter is a function of the resistor divider used and the EFC sensitivity. The PWM cycle rate depends on freq step size, the speed of the PPS signal, the osc divider used and GPS PPS phase noise. Lots of other uses for this type of D FF as a basic ns hi-low Phase detector for low freq signals. Remove the EFC feedback, Reduce the 100 to 1 divider to two or so and you can use this to measure and/or manually set a Rb Osc to be on frequency if you have an accurate 1PPS signal. ws [time-nuts] Thunderbolt? (re simple gpsdo.) Chris Albertson albertson.chris at gmail.com Sat Dec 31 20:34:14 UTC 2011 I think this is the simplest design that can still work, just one flip flop, divider and a capacitor. What level of performance did you get?I think it depends on how big the integrating capacitor is and how stable the VCXO is. I guess if you switched to using the t-bolt the performance was not as good as a t-bolt. On Sat, Dec 31, 2011 at 10:23 AM, WarrenS warrensjmail-one at yahoo.comwrote: Chris Here is a GPSDO I built that better fits Your definition of Simple. I used this as my freq standard before getting a TBolt. 1) Feed the PPS output of an oncore GPS timing engine which has 1 Hz or better yet 100 Hz output to the clk of a D FlipFlop (74HC74) 2) Feed the FF's D from a 10 MHz osc which has been divided down to 100KHz or less using 74HC390. The FF output shows if the Phase of the Osc is greater or less than the GPS signal and the FF will toggle back and forth when the phases are near equal due to the typical 40 ns jitter on the GPS pulse signal. 3) Add a RC filter to the FF output using a big cap, so the voltage out of the RC filter is 0 to 5 volts depending on the duty cycle of the FF. (A small R in series with the cap will help stabilize it if a real Big cap is used). 4) Feed the filtered analog FF output voltage (No buffering necessary) to the EFC of an 10 MHz osc that has its EFC input desensitized with a couple of Rs and has been set to be real near 10 MHz at the nominal analog FF's 2.5 volts output using the Osc's mechanical tuning and/or add a fine freq adj pot... Chris Albertson Redondo Beach, California snip Home heating thermostats can be simple of complex. Some use LCD displays and a computer. Other have a simple bimetallic spring inside. But for now I'm looking for a controller that is much more like the bimetallic spring thermostat. 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] Using Thunderbolt to Discipline FE 5680A?
Fred What you may of seen was how to use a TBolt to discipline a LPRO Rb. There are several time nut posting on how to do that in a very simple and high performance way. http://www.febo.com/pipermail/time-nuts/2011-May/056526.html http://www.ko4bb.com/dokuwiki/doku.php?id=precision_timing:lpro_disciplining_with_thunderbolt You should be able to do something similar using the FE-5680A. The basic way I've done it is to: Modify a Thunderbolt (preferable one with a poor Osc) to use the LPRO's 10 MHz as it's ref osc, and bring out the Tbolt's Dac thru a 1K ohm. http://www.ke5fx.com/tbolt.htm For the LPRO, I added a 12K 1% resistor to the high side of its C field winding, making a low sensitivity EFC input, and connected that to the Tbolt's 1K Dac out resistor. Then by using an 'Extended' Time constant and damping factor setting on the Tbolt, you can set the control loop to anything you want up to many days. Depending how good the Rb's temp-co is and how much you allow it's uncompensated temperature to change, I found that an extended Time constants from 5K sec to 24 hrs worked best for the LPRO. ws *** - Original Message - From: Frederick Bray Sent: Thursday, December 22, 2011 8:50 AM Subject: [time-nuts] Using Thunderbolt to Discipline FE 5680A? Has anyone successfully used a Thunderbolt to discipline a FE-5680A? I thought I saw a posting or site where someone disabled the 10 MHz oscillator on the Thunderbolt and used the Thunderbolt to discipline the FE-5680A. However, I can't find it now. Thanks. Fred ___ 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] Using Thunderbolt to Discipline FE 5680A?
IF? the RS232 command changes the freq and does not reset the phase, then the way to get there is to use dither or PWM between two frequency values. Example: to change the phase 1ps, change the freq by 7e-13 for 1.4 seconds and then put it back. If you want finer resolution than 1 ps then update faster. ws Using the digital input will only give you 7 E-13 steps. I will use it for preset. Bert Kehren *** albertson.chris at gmail.com writes: On Thu, Dec 22, 2011 at 9:52 AM, Chuck Forsberg WA7KGX N2469R caf at omen.com wrote: You could disable the Tbolt's oscillator and put the Rb output in its place. Then write a program that reads the PPS and/or OSC offset and issue appropriate commands to the Rb to bring it in line. ** I don't think it is possible to do that. The RS232 commands don't allow the level of control that is required. All you can do is step the frequency, no way to adjust the phase of the Rb 10MHz output. 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.
[time-nuts] TPLL2 and Tbolt Tic
Sounds like an interest project, Do you have any performance plots? It would be interesting to see how it compares with the TPLL2 which uses a $5.00 USB sound card to greatly improve the performance of the old all analog $10 TPLL. Using mostly junk box parts, and a 3e-13 selected HP10811 reference Osc, the TPLL2 can do fast, high resolution Frequency and ADEV plots that closely match the best testers and can provide taus plots starting as fast as 0.1ms with a noise floor as low as 1e-14/sec. (limited by the reference Osc). Using John's TimeLab software, live, real time ADEV plots showing tau data from 1ms to 1 sec can be plotted for an Osc in as little as 10 seconds with one key press (and a couple of Enters). This can be useful for quick Osc testing because using a fast, low noise tester, the tau of many high end oscillators is pretty flat between 0.1 sec and 1 sec taus. Also possible is 1e-12 freq measurements in about 100 ms, with data logging fast enough at up to 10k/sps, and resolution high enough at 10fs, to measure the effects of line noise and it's harmonics on the oscillator's frequency. The TPLL2.0 provides good short term sub picoseconds resolution. For longer runs the TPLL2 can be combined with a single or dual TBolt Tic to provide long term resolution as low as 0.1 ns(1e-10/sec), which is good enough to measure and compare Cs from day to day. ws * Ulrich, DF6JB posted: I have just finished the work on a pcb ... snip ... The board features an AD654 voltage to frequency converter which is connected to the PLL's loop voltage and delivers pulses to an ATMEGA32 counter input. That would make it possible to use the board as an correct implementation of the tight pll method as discussed here ___ 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] T-bolt and LPRO marriage
MB asked (off line): I have wanted to find out how to marry one of my Tbolts to one of my LPRO Rb oscillators for a long time. Some say doing this is a waste of time. All depends what you plan to do with it. Changing the Tbolt's internal Osc to an external LPRO Rb Osc will increase the Tbolt's 10MHz output noise at taus below a couple hundred seconds. Past around 500 seconds, It can give you a freq reference that is as useful and accurate as some Cs. In any case, it is not a problem at all to set up a Tbolt to discipline (or test) most anything that runs at 10.000 MHz. The Tbolt is by far the best and most universal GPS unit I know of. One of the tricks is to use an extended time constant type setup. Without that, the TC setting is limited to about 1000 seconds, which is not nearly long enough for a Rb. Using an extended Time constant you can discipline most anything whose freq can be changed with an analog voltage, and set the time constant from 1 sec to a year with any desired damping factor. Works even on a Cs or Masers. (The TBolt's antenna should have to have a good sky view so that it never goes into Holdover) You can find more info on past post OR see John's site for help on how to do the TBolt's Hardware at: http://www.ke5fx.com/tbolt.htm and Didier's Wiki pages for notes on setting up the Tbolt at: http://www.ko4bb.com/dokuwiki/doku.php under LPRO disciplining with Thunderbolt. Have fun, ws ** Subject: T-bolt and LPRO marriage Hi, Warren-- I have wanted to find out how to marry one of my Tbolts to one of my LPRO Rb oscillators for a long time. Some say doing this is a waste of time, but I still think it would be an interesting project. How complicated is it to discipline an LPRO Rb osc with a T-bolt? Thanks-- MB ___ 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] Neutrino timing
I have a more basic time-nut question. Why is it a problem at all? How can the time uncertainty between two known and fixed locations be that large? If they know they have a 70ns uncertainty in time, that would suggest that their time measurement is known to be varying at one or both places. Is this just from a spec or do they see a true variation in time between something, and if so compared to what? Is this time difference or variation between several difference timing devices at each end or is it variation when compared to time of flight of the supposedly same neutrinos? I can not say anything about the accuracy of my absolute time, but the difference and uncertainly comparing the phase difference between different external Osc Tbolts at the same location is way way under 70ns. Sure lots of BASIC things to do to make sure the two Tbolts are set the same so that their oscillator's phase do they agree, such as using the same type antenna and same cable and length, and getting the antenna's location correct, etc, etc, but basic stuff and seems like if using the same basic GPS system at two different locations, what would the additional problems be except to make sure both ends are syncing on the same 100ns 10MHz cycle. I was under the impression that getting down to ns uncertainly differences (and staying there) at theses distances is old stuff using common view GPS. So what are the problems that cause their large timing uncertainty? ws * Good morning, Recently physicists using a neutrino beam from Geneva Switzerland to the Gran Sasso in Italy have reported a measurement of neutrino velocity that is faster than the speed of light. The effect over a 730 km path length is reported as 60 ns, which means that precise timing is required at both ends of the beam to have sensitivity to this effect. The reported result, if true, has major implications for the fundamental understanding of physics. Thus, it is important to carry out independent checks of this measurement. A similar beam exists between Fermi National Accelerator Lab in Batavia IL and the University of Minnesota's Underground Laboratory at Soudan in northeastern Minnesota. This U.S. beam has been used to make a similar measurement, but the GPS timing equipment that was used (Truetime XL-AK, Model 600-101-015) resulted in an estimated uncertainty of about 70 ns in the neutrino time-of-flight, too large to test the recently reported effect. I am one of a group of physicists working with the neutrino beam in the U.S. Although we are also talking with professionals at USNO and NIST, I am interested in possible suggestions from the Time Nut community with respect to the following: (a) the possibility of retrospectively improving the existing timing data recorded since 2005 using the Truetime XL-AK, and (b) a quick, low-cost improvement in the timing instrumentation that can be made right away, pending arrangements for techniques such as Two-Way Satellite synchronization. In addition, if there are any Time Nuts in the Minnesota area who would like to get more involved in this project, please feel free to contact me at marshak at umn.edu Thank you very much. Marvin Marshak ___ 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] DMTD using TBolts
Tbolt-Tic is what I call a Tbolt when it is NOT used as a GPSDO controller but instead used as a high resolution time interval counter. (really a time difference logger). How do you make a single TBolt-Tic much better? Simple, By making a dual TBolt-Tic. From an offshoot of my Common view TBolt experiments, I connected a common GPS antenna to two Tbolts that both have been modified to use an external osc. Results: This makes a simple, high performance, DMTD tester with low ps resolution using the 'noisy' GPS signal as the common offset Osc. DMTD and common view both work on the same basic principle. The end results is that the noise of the common signal source (GPS in this case) tends to cancel when the difference between the two Tbolt data streams is use. The data difference then gives the freq and the phase difference between the two 10 MHz Oscillators that are being compared. (neither of which needs to be disciplined or have an EFC input). From the phase difference and the PPT Freq difference data, standard low noise floor ADEV plots can be made with tau zero = 1 sec. No software yet to make it all easy and automatic, but hopefully that will happen in a future version of LadyHeather and/or TimeLab. Maybe, the existing Plotter S/W can already take the raw data from two Tbolts, find the differences by subtracting both the Phase and PPT columns and plot the results. If not, any volunteer to come up with a SIMPLE routine to do the above ws ___ 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] Common View Tbolt-Tic
Thanks Guys, Gives me lots to consider and go over. Not going to be quite as easy as I hoped. Then if it was easy it would not be Nut-fun. Lots to learn, which I do best with experiments. Sounds like using times much longer than 1 Hr is the way others do it, But then they have different goals. My thought is that a well setup TBolt using a good external oscillator will pretty much beat anything if let run long enough, So what I'm first interested in is to see if there is a significant improvement possible over short time periods. Preliminary test results using two Tbolts on the same Osc, with different antennas that are close together is: Comparing the short term Tbolt Phase plots does not help much, they are pretty random noise short term. Comparing them after passing thru a slow low pass helps. On the other hand, The two TBolt's PPT freq plots are tracking each other nicely. This agrees with early test that showed the Tbolt's PPT data has much less short term noise than the Phase data, (but the PPT data is not so good long term). I'm seeing tracking between these two Tbolts of better than 1e-12 using filter setting of 10 to 100 sec. This is giving at least a 10 to one improvement compared to using just one Tbolt in single view mode. Now that I have data showing what the Tbolt is capable of, need to redo the test where the antennas are separated by hundreds of miles, to see what the GPS is capable of over that distance. Still TBD is how to best take advantage of the Tbolt's unique characteristics. I'll respond to the other questions and show some LH graphs, once I get some better data. Thanks, any other comments/experiences and translations of what the papers are saying that apply to this effort are welcomed ws * Warren, This will be fun. Are these standard TBolts or ones with external oscillator (Rb)? ws) All the above I won't address the issue of noise measurement in this email. The first question is how long did you collect data among the sites? ws) I'm looking at short term results from seconds to an hr or so The standard GPS Common View that the timing labs do is based on 13 minute tracks (per satellite). In other words, it's not the raw one second measurements they compare; it's the summary of the entire 780 second track. The raw TBolt LO time (phase) data has a lot of GPS signal and receiver noise and won't correlate at short times. That's why GPSDO need such long time constants. Also with 1 SV in your test instead of 8 SV the noise will be all the greater. Anyway, reduce the data in 10 to 15 minute chunks and see if that helps at all. There's more to common view; not sure how much to dump on you for starters. How did you try to correlate it? Send me some of the raw data if you can. For some light reading start with: http://tf.nist.gov/time/commonviewgps.htm http://www.usno.navy.mil/USNO/time/gps/about-the-cggtts-data http://www.nrc-cnrc.gc.ca/eng/services/inms/time-services/positioning-data.html http://www.usno.navy.mil/USNO/time/gps/gps-timing-data-and-information You don't have to use the CGGTTS format for this initial trial but the information about the file format will be a useful guide to how common view works. The advantage of the format is then you can compare against USNO and anyone else that publishes CGGTTS files. But I'm getting ahead of myself. For some deeper reading, please enjoy these: A review of time and frequency transfer methods http://tf.nist.gov/general/pdf/2311.pdf Time and Frequency Measurements Using the Global Positioning System http://tf.nist.gov/general/pdf/1424.pdf A Comparison of GPS Common-View Time Transfer to All-in-View http://tycho.usno.navy.mil/ptti/ptti2005/paper40.pdf Effects of the Rooftop Environment on GPS Time Transfer http://tf.nist.gov/general/pdf/2199.pdf Google for Novel GPS Survey Antenna for details on that pinwheel antenna mentioned in the above paper. /tvb * Hi Warren, What is not too clear is how much of that is due to the Tbolt engine and how much is the GPS Reference. Do you have two working Tbolts with their orginal oscillator removed? From what I've seen in my test, a large amount of that noise floor is due to the GPS. I think a dual Tbolt configuration would eliminate GPS instabilities and rely more on the house standard. As proposed in previous email. -- Björn * Hi Warren, ... The 2Tbolt-system is really a degenerated Common View time transfer system, with both receivers beening colocated and using the same GPS antenna signal. Moving the receivers to different time-nut labs, we have a traditional time-transfer system. Where we perhaps only lack L2 measurements, compared to the serious time tranfer systems used by national labs. http://tf.nist.gov/time/commonviewgps.htm -- Björn I propose an experiment with two Tbolts running from the same antenna and sharing the same oscillator, ie at least one of
Re: [time-nuts] Common View Tbolt-Tic
Ed I think I have confused things by doing two completely different things. One is how best to make a better Tbolt GPSDO, the other is how use a Tbolt to make a remote OSC tester. To do the first, the osc needs to be disciplined slowly, to do the second, best to do it using the disable mode with no disciplining. Correct, when the Tbolt is in the disabled mode, using either with it's own internal or an external Osc, It is just running the osc as a standard OCXO. But what I'm taking advantage of is that the Tbolt is also recording data showing what the difference is between that Osc and the GPS signal. This is the same function any Tic has. The Tic tester does not change the Osc, it just measures it by comparing the osc against some other reference. When the Tbolt is in the disciplined mode, what it does is change the osc by removing any long term difference between the Osc and the GPS. This is not so good for comparing oscillators, because ideally they are now being made equal in the long term. And correct, when in the TPLL mode, the TBolt 10MHz output has Nothing to do with it's Osc, It is just showing the GPS noise. While this allows one to test what the received GPS noise is by using an external reference and ADEV tester, it has little or no information about the osc being used and therefore (mostly) useless for directly comparing the TBolt Osc to the GPS, which is what is needed to measure common view differences. Two different functions, two different goals, two different procedures and two different uses of the Tbolt. and two different Fun projects ws *** - Original Message - From: Ed Palmer Posted What do you see when you look at the ADEV of a Tbolt in the Disabled state? To me it looks like an ordinary OCXO. In my case, the aging looks like about 5E-10 per day. The Tbolt book doesn't say much about the Disabled state. Is it possible that the Disabled state means 'Disable the GPS and pretend that it's just an OCXO'? If so, this is not the mode you want to be in for a Common View test. By comparison, the ADEV of a Tbolt in the TPLL mode looks a lot like a bare GPS receiver. Would that work better for what you want to do? ... snip Ed *** On 10/18/2011 12:32 PM, WarrenS wrote: I'm doing some experiments in hopes of using the TBolt-Tic in a common view configuration to lower the short term noise. That is, instead of comparing a local externally connected Tbolt Osc to the GPS, I want to compare it remotely to one of say Tom's supper H-masers or Cs references. The single view Tbolt-Tic works great using averages of a half day plus to get down to 1e-13, but being nuts I want to do it Faster and better. Test setup: I have three COMPLETELY independent Tbolts running, each with its own LadyHeather monitor. Two of the Tbolts are a couple feet away from each other, the third one is a few hundred miles away. All three are in single satellite mode set to watch the same near overhead satellite. All three of these Tbolt oscillators are capable of short term noise a decade or two better than the short term GPS noise. I also measured the TBolt's engine phase noise to be a decade lower than the short term GPS noise. All three are in disable mode, so that their plotted LH phase noise is for the most part ALL due to the received satellite signal noise. My hope was that there would be a high correlation between the Phase noise of their three Phase plots.. What I see is almost no correlation, they are all just doing their own thing with random phase noise of a couple ns. Just to check I tried the same test with a satellite that had an elevation of around 45 deg with the same results. One test I should run is to use the same antenna for two of the Tbolts, But that defeats the whole purpose, which is to be able to compare by way of LadyHeather's remote function, a local Osc to an external Rb or Cs remote reference Osc. Any suggestions? Something is wrong somewhere. Maybe it is that the Tbolt's engine noise is not what I measured it to be, but I have double checked that a couple of different ways. Anyone have personal common view experience comparing Tbolts OR any other thing using GPS. ws ___ 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] Sneaky Errors
Maybe this is too simple LadyHeather is always checking the Tbolt's Internal Osc value against the GPS. By watching it's plot outputs you can tell if the Tbolt is on freq. (compared to the GPS) If no plot outputs, then something is broken, at that point is does not matter what, can assume it is that Tbolt. A couple of other things to assume also for this to be the solution to the problem. 1)The GPS is Always right and is correct, IF one of the Tbolts fails IN any way. The GPS is used as the 3rd Osc to vote who is wrong when there is disagreement between the two Tbolts. 2) The Tbolt always has an output that is at the same freq as it's internal Osc. While not a critical fail safe for everything, this does cover the case requested. If the two Tbolt do not agree, what one is wrong. Answer is the one that is different than the GPS When they are both close to the same freq (with-in 1e-9), don't need the GPS's vote, if you assume they are both right. ws * As long as the Thunderbolt is working perfectly it's built in error checking will work fine. This should be obvious as anything that works, works. But I can think of plenty for failure modes where the built in error checking might not work. First off there could be a software or firmware bug or a stuck bit in a ROM. An open conecton on a DAC, lots of things. The assumption has to be the broken hardware is totally unpredictable We can not know in advance what it will do after it breaks. I'm not saying the built-in diagnostics are useless, just that they are never 100% reliable On Wed, Oct 19, 2011 at 2:18 PM, ws at Yahoo warrensjmail-one at yahoo.com wrote: Simple way is to use LadyHeather. From its output, you can tell if either or both are working correctly as well as how well they are working. That is assuming of course that there is at least one working GPS satellite in view at all times. If not it well tell you that also. 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.
[time-nuts] Common View Tbolt-Tic
I'm doing some experiments in hopes of using the TBolt-Tic in a common view configuration to lower the short term noise. That is, instead of comparing a local externally connected Tbolt Osc to the GPS, I want to compare it remotely to one of say Tom's supper H-masers or Cs references. The single view Tbolt-Tic works great using averages of a half day plus to get down to 1e-13, but being nuts I want to do it Faster and better. Test setup: I have three COMPLETELY independent Tbolts running, each with its own LadyHeather monitor. Two of the Tbolts are a couple feet away from each other, the third one is a few hundred miles away. All three are in single satellite mode set to watch the same near overhead satellite. All three of these Tbolt oscillators are capable of short term noise a decade or two better than the short term GPS noise. I also measured the TBolt's engine phase noise to be a decade lower than the short term GPS noise. All three are in disable mode, so that their plotted LH phase noise is for the most part ALL due to the received satellite signal noise. My hope was that there would be a high correlation between the Phase noise of their three Phase plots.. What I see is almost no correlation, they are all just doing their own thing with random phase noise of a couple ns. Just to check I tried the same test with a satellite that had an elevation of around 45 deg with the same results. One test I should run is to use the same antenna for two of the Tbolts, But that defeats the whole purpose, which is to be able to compare by way of LadyHeather's remote function, a local Osc to an external Rb or Cs remote reference Osc. Any suggestions? Something is wrong somewhere. Maybe it is that the Tbolt's engine noise is not what I measured it to be, but I have double checked that a couple of different ways. Anyone have personal common view experience comparing Tbolts OR any other thing using GPS. ws * ___ 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] Russian GPSDO
So where do I get a cheap, used Russian GPSDO? I have not seen any on EBay Can I trade them my Tbolt? :) per: http://tycho.usno.navy.mil/ptti/1998/Vol%2030_18.pdf Although not as well known as the GPS, the Russian global satellite navigation system GLONASS possesses comparable capabilities for navigation, precise geodetic positioning, and time-transfer applications [l]. one-site measurements are used to show that single-channel GLONASS precise code, combined with temperature-controlled antennas, reduces the noise experienced by time receiving equipment of a few picoseconds for 1e-15 frequency accuracy in one day, and unlike GPS P-code, it is available to civilian users ... ws ___ 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] Cable delay correction for Tbolt Cs substitude
Anyone know what the propagation delay temperature coefficient is for RG6U coax and how much it varies between different brands of cable? In my efforts to improve the Tbolt's performance to make it into a better Cs substitute, test suggest that the temperature coefficient of the antenna lead-in cable's propagation delay is contributing to diurnal errors. Anyone have a idea for a SIMPLE cheap voltage controlled delay line that can be changed by a few ns as a function of the outside air temperature? As an alternative, Mark, want to consider adding another LadyHeather feature that tweaks the Tbolt's cable delay value as a function of the outside temperature? If interested, I have a couple ideas of how to get the outside temperature to LadyHeather. ws ___ 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] Cable delay correction for Tbolt Cs substitude
Thanks John Any chance using 75 ohm cable (as suggested in the Tbolt manual) like RG6U, when used in a 50 Ohm system could be orders of magnitude worse than LMR-400? Sounds like may be time to do some controlled cable experiments comparing different cables. I do know that Cheapie GPS timing antenna's can have a large Phase variation when the Sun hits them. I had one antenna that changed 25 ns every day around Noon time. That is when I changed over to a Symmetricom 58532A antenna and things improved 10 fold. With the new antenna the phase error change is now down at least near the GPS noise level, but it seems to still have some antenna system temperature effects. Maybe a silly question but how can a 1.5GHz preamp and filter change the phase over so many cycles? Does anyone ever add a temperature controller on the antenna? Maybe that should be my next test. ws ** from John Ackermann N8UR I did some very rough measurements last summer with. Run of LMR-400 that was laying on the roof in the hot Georgia sun. Using a network analyzer to ping the cable I found the day vs. night delay difference was pretty much in the noise. I'll see if I can find the details and if so will post them. I found via google a brief paper from Haystack that measured LMR-400 and LMR-240 and found in the range of -11 to +17 ppm/K of the total cable delay. They note that 9 ppm/K is about 3ps/degree in 100M of cable: http://www.haystack.mit.edu/tech/vlbi/mark5/mark5_memos/069.pdf However, there's another possible tempo contributor that I suspect could be a significant contributor, and that's the preamp up in the antenna, particularly if it has a bandpass filter. It wouldn't surprise me at all if preamp/BPF tempo was noticeable. John On Oct 16, 2011, at 1:32 PM, WarrenS wrote: Anyone know what the propagation delay temperature coefficient is for RG6U coax and how much it varies between different brands of cable? In my efforts to improve the Tbolt's performance to make it into a better Cs substitute, test suggest that the temperature coefficient of the antenna lead-in cable's propagation delay is contributing to diurnal errors. Anyone have a idea for a SIMPLE cheap voltage controlled delay line that can be changed by a few ns as a function of the outside air temperature? As an alternative, Mark, want to consider adding another LadyHeather feature that tweaks the Tbolt's cable delay value as a function of the outside temperature? If interested, I have a couple ideas of how to get the outside temperature to LadyHeather. ws ___ ___ 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] Cable delay correction for Tbolt Cs substitude
Sounds like its time to do some testing and see what the effect is on the actual hardware. 1) Heat and cool the Tbolt box and see if that effects THIS Phase delay, maybe by way of its internal GPS amp/BPF. In the past I have not seen a need to use LH's temperature controller on a Tbolt that is driving an external Dual oven Osc or a temperature stabilized Rb like this Tbolt is. 2) Place an extra 50 ft of RG6 between the Antenna and the Tbolt inside an oven, then heat and cool it. 3) Put the Roof top antenna in an RF transparent box with a heater. too much fun ws Griffiths bruce.griffiths at xtra.co.nz wrote: It's merely a calculation of the change in inductance due to the temperature induced change in skin depth due to the resistivity tempco of the inner conductor which varies the inductance per unit length. Since RG6 uses a copper plated steel inner conductor there may be significant differences in the inductance tempco should the plating thickness not be much greater than the skin depth (most likely at lower frequencies). The thermal expansion of the inner conductor will also be smaller than that of a copper conductor. Thus the delay tempco of RG6 may differ somewhat from that of LMR400. Bruce *** John Ackermann N8UR wrote: I wouldn't think the cable type will make an order-of-magnitude difference. Referenced in the Haystack note is another paper that goes through the theoretical derivation that produced the expected results column. I think it's the same URL but 067.pdf as the file name. John On Oct 16, 2011, at 2:21 PM, WarrenS wrote: Thanks John Any chance using 75 ohm cable (as suggested in the Tbolt manual) like RG6U, when used in a 50 Ohm system could be orders of magnitude worse than LMR-400? Sounds like may be time to do some controlled cable experiments comparing different cables. I do know that Cheapie GPS timing antenna's can have a large Phase variation when the Sun hits them. I had one antenna that changed 25 ns every day around Noon time. That is when I changed over to a Symmetricom 58532A antenna and things improved 10 fold. With the new antenna the phase error change is now down at least near the GPS noise level, but it seems to still have some antenna system temperature effects. Maybe a silly question but how can a 1.5GHz preamp and filter change the phase over so many cycles? Does anyone ever add a temperature controller on the antenna? Maybe that should be my next test. ws ** from John Ackermann N8UR I did some very rough measurements last summer with. Run of LMR-400 that was laying on the roof in the hot Georgia sun. Using a network analyzer to ping the cable I found the day vs. night delay difference was pretty much in the noise. I'll see if I can find the details and if so will post them. I found via google a brief paper from Haystack that measured LMR-400 and LMR-240 and found in the range of -11 to +17 ppm/K of the total cable delay. They note that 9 ppm/K is about 3ps/degree in 100M of cable: http://www.haystack.mit.edu/tech/vlbi/mark5/mark5_memos/069.pdf However, there's another possible tempo contributor that I suspect could be a significant contributor, and that's the preamp up in the antenna, particularly if it has a bandpass filter. It wouldn't surprise me at all if preamp/BPF tempo was noticeable. John On Oct 16, 2011, at 1:32 PM, WarrenS wrote: Anyone know what the propagation delay temperature coefficient is for RG6U coax and how much it varies between different brands of cable? In my efforts to improve the Tbolt's performance to make it into a better Cs substitute, test suggest that the temperature coefficient of the antenna lead-in cable's propagation delay is contributing to diurnal errors. Anyone have a idea for a SIMPLE cheap voltage controlled delay line that can be changed by a few ns as a function of the outside air temperature? As an alternative, Mark, want to consider adding another LadyHeather feature that tweaks the Tbolt's cable delay value as a function of the outside temperature? If interested, I have a couple ideas of how to get the outside temperature to LadyHeather. ws __ ___ 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] Thunderbolt error?
Rix If you are using LadyHeather, Post or send me a screen shot using W S Cr Maybe just that the min or max Dac values are not set to - + 5V, or something else easily fixed. ws [time-nuts] Thunderbolt error? Rix Seacord eseacord at verizon.net Hi gang I'm getting an error message of vco near rail or vco at rail. Is this saying my thunderbolt is dying or can this be fixed? -Rix Seacord ___ 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] Thunderbolt error?
Rix Nothing looks wrong in that snap Shot Your osc (which is the main cause of the out of range error) is working fine and under control and has near zero volts on it's EFC. Take a look at the screen when you key , that has the screen with the Max and min DAC setting info on it. Should be +5 and -5 (set with N -5 Cr and x 5 Cr) Also can use F A command to turn on the Altitude filter If it misses up again, use the \ key to get an automatic screen shot save without it first updating. If bonkers is about 1 deg, maybe you have the low resolution Temp sensor chip (It has about 1/2 deg C resolution). That does not really matter or effect anything important unless you are doing temperature control with LH. If the temp never changes, then likely the DS?? surface mount 8 pin temp sensor chip is broken and should be replace Do note the way you have the temp plot set up (Zero offset and low gain) you will only be able to see large changes on the plot. Have fun ws *** Warren I may have jumped the gun on this. I cycled the power a few times and it appears to work. Note the temperature never seems to change. It sometimes goes bonkers then settles down again. Attached is the screen shot Thanks much Rix *** On 10/16/2011 3:47 PM, WarrenS wrote: Rix If you are using LadyHeather, Post or send me a screen shot using W S Cr Maybe just that the min or max Dac values are not set to - + 5V, or something else easily fixed. ws ___ 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] Measuring ADEV using TBolt-Tic tester
Tom Thanks for the Tbolt vs. H-maser data log, That's great data showing how good GPS can be out to 200,000 sec with SA off. Your data showing a little under 5e-14 at 1 day, makes a very good reference point to remember. Any guess when your plot would flattens out or turn around? It is also a very useful plot that can be used to see where to set the TC for a Rb disiplined GPSDO. What I see with LH and a disciplined tweaked-out LPRO on a good run, for periods of time lasting a few hours is a RMS phase noise a little under 2ns. With the Tbolt noise floor being well under 1ns, good to know it is not a limiting factor. Tom Posted on Oct. 4, 2011 I have a couple of suggestions for you; in another posting. Tom, did I miss anything? Thanks for all the info, ws * Tom Van Baak tvb at LeapSecond.com Posted Thu Oct 13 16:53:31 UTC 2011 The noise of the Tbolt's freq (PPT) output data measured about ten times lower than it's phase output data at 1 sec. How it does it is anyone guess, but looks to be some sort of high speed averaging going on, taken over a one second time interval. ws The short-term frequency values could be aided by carrier phase while the longer-term timing from code phase. I am trying to dig out the work I did on packets 0x8F-AC and 0x8F-A7 some years ago. In those runs I recorded all the raw data from a TBolt (not from LH) at the same time as comparing the 10 MHz output against a stable reference. That helped separate internal tracking effects from actual 10 MHz performance. Yes, the switching in/out of different satellites is quite an effect, as you have observed. This is exposed in 0x8F-A7. Note the long-term (say hours to one day) TBolt performance is a couple ns RMS; which is close to a plain M12+T receiver. I'm looking for some parallel runs I did with various Oncore and TBolt receivers. I think you'd enjoy those data sets, but I have to locate the old PC first. There's one nice long TBolt data set that I posted: http://leapsecond.com/pages/tbolt/log36116.dat.gz and described here: http://www.febo.com/pipermail/time-nuts/2011-January/053621.html Put that into TimeLab and play around with it. The stdev of this several day run is 2.6 ns. The peak to peak variations are around 10 to 15 ns. TDEV is about 1 ns. One other trick you can pull with this data set is zoom in on the ADEV. If you look closely you can see that the ADEV for a GPSDO is ever so slightly better near tau 86164 (sidereal) than it is as tau 86400 (solar). http://leapsecond.com/pages/tbolt/log36116-adev-sidereal.gif This, because of the GPS SV orbital period. /tvb *** Tom Posted on Oct. 4, 2011 What I'd like to find out is how accurate a GPS Disciplined_Rb_Osc can be made compared to the typical Cs out there. Warren, Most modern GPSDO will outperform rack-mount Cs in stability as the tau grows beyond a day or a week. Of course, it depends quite a bit on the particular GPSDO or the brand of Cs but in general GPSDO's are really good and always win in the end because they are locked to UTC and a free-running Cs isn't. Some of my 5071A flicker out at 5e-15. It takes a 4 ns RMS GPS timing receiver about 10 days to get to the same point. Remember that a GPSDO is a really just a radio receiver, a time-transfer device, a slave repeater; not strictly a clock. So their superior long-term performance isn't surprising. It also explains why there's a huge market for GPSDO products and a very small market for large stand-alone Cs standards. The surplus Z3801A and Thunderbolts that hit the eBay market this decade have been the greatest treat any amateur could possibly have hoped for! I have a couple of suggestions for you; in another posting. /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] Measuring ADEV using TBolt-Tic tester
I'll try again. My last post was completely garbled somewhere along the line. Using the 1 sec ADEV noise floor from the plot at http://www.febo.com/pipermail/time-nuts/attachments/20111007/48d1ab68/attachment-0001.gif This shows the RMS sum of the short term GPS signal's noise Plus the Tbolt engine, plus the Osc, for the achievable resolution at 1 second. The one shot, 1second resolution of the Tbolt's phase data is 100 ps or less The one shot, 1 second resolution of the Tbolt's PTT detector is 10 ps or less What is not too clear is how much of that is due to the Tbolt engine and how much is the GPS Reference. From what I've seen in my test, a large amount of that noise floor is due to the GPS. In these cases the Tbolt's external Osc noise is low enough as not to contribute significantly to the RMS sum. This is not necessarily an equal comparison to your 1 shot numbers, because the Tbolt is using high speed averaging to get its low single shot 1second resolution by averaging over many cycles of a higher frequency. Using this basic technique and averaging over 10,000 cycles of the 100ns 10MHz signal, the one shot resolution achieved by the TPLL2.0 is under 10 femtosecond in 1ms. ws * From: Azelio Boriani The HP58503A has the Oncore 8-channel GPS receiver. The single-shot resolution capability is the ability to resolve the time interval without any averaging. For example, the Fluke/Pendulum PM6681/CNT81 has a 50pS resolution, the HP5370 has 20pS, the Racal Instruments 2351 VXI TIC has 8pS single shot maximum resolution, the Wavecrest SIA3000 signal analyzer has 200femtoS hardware resolution at 3GHz. On 10/13/11, ws at Yahoo wrote: I know very little about the HP58503A. Any chance it is using the old 6 channel Oncore GPS engine? If it is like the Oncore I tested long ago, that noise was about a decade or so higher than the Tbolt's phase noise. Not sure what you can call single-shot resolution. The data is reported with Pico second resolution. The cycle to cycle max phase varation, If there is not a satellite change at the same time, is around 0.4ns max error. With the very high resolution that is output, averaging provides a lot of benefit. The noise of the Tbolt's freq (PPT) output data measured about ten times lower than it's phase output data at 1 sec. How it does it is anyone guess, but looks to be some sort of high speed averaging going on, taken over a one second time interval. ws * From: Azelio Boriani Your work is very interesting, now I wonder what is the Tbolt single-shot resolution? Does the Tbolt use the analog interpolator method? I don't have the Tbolt, I have an HP58503A at work as the only reference. ** ___ 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] Measuring ADEV using TBolt-Tic tester
Thanks Tom very interesting. I like your guess on how they get such a low noise for the PPT data. I would like to know why they would go to the trouble, because I don't see anywhere that information is used except for the PPT output. Alos the Tbolt's PPT freq data, long term is usually offset by a couple of parts in e-12 on LH plots. Any reason you know of why it would bottom out long term, beside software rounding? I see this in LH plots as well as the ADEV plot. Is there anyway to get the M12+t's 1 sec resolution down below 1ns? I'd expect the Tbolt and M12+t to be the same over the long-term (say hours to one day), or even a few minutes, the noise should be completely dominated by the GPS and not by the engine of a good receiver by then. The Satellite switching phase jumps gets much worse with a poor antenna set up, such as if the location is not set right or there is mutipath etc, etc. I got mine down from what use to be 10 ns to around 1/2 ns. I would like to see how low that noise is with a near perfect antenna setup using a choke ring etc, to know how much more improving I still need to try for. ws ** Tom wrote: The noise of the Tbolt's freq (PPT) output data measured about ten times lower than it's phase output data at 1 sec. How it does it is anyone guess, but looks to be some sort of high speed averaging going on, taken over a one second time interval. ws The short-term frequency values could be aided by carrier phase while the longer-term timing from code phase. I am trying to dig out the work I did on packets 0x8F-AC and 0x8F-A7 some years ago. In those runs I recorded all the raw data from a TBolt (not from LH) at the same time as comparing the 10 MHz output against a stable reference. That helped separate internal tracking effects from actual 10 MHz performance. Yes, the switching in/out of different satellites is quite an effect, as you have observed. This is exposed in 0x8F-A7. Note the long-term (say hours to one day) TBolt performance is a couple ns RMS; which is close to a plain M12+T receiver. I'm looking for some parallel runs I did with various Oncore and TBolt receivers. I think you'd enjoy those data sets, but I have to locate the old PC first. There's one nice long TBolt data set that I posted: http://leapsecond.com/pages/tbolt/log36116.dat.gz and described here: http://www.febo.com/pipermail/time-nuts/2011-January/053621.html Put that into TimeLab and play around with it. The stdev of this several day run is 2.6 ns. The peak to peak variations are around 10 to 15 ns. TDEV is about 1 ns. One other trick you can pull with this data set is zoom in on the ADEV. If you look closely you can see that the ADEV for a GPSDO is ever so slightly better near tau 86164 (sidereal) than it is as tau 86400 (solar). http://leapsecond.com/pages/tbolt/log36116-adev-sidereal.gif This, because of the GPS SV orbital period. /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] Measuring ADEV using TBolt-Tic tester
Good ideas, That's more to put on my to do list, But not near the top. I've got two external Tbolts (one is a loaner) plus an internal one. Right now I'm limited because of some long term testing I doing. Something to be careful about when doing what you suggest is that the two Tbolts will not switch birds at the same time, so need to not use that part of the data if you want to remove the effect of the GPS. Treat that part like outliners. To check for Tbolt noise floor, Good idea to use just one external one and an internal one as long as it has a good low noise Osc in it. Can using the 10 MHz output of the internal one to drive the input of the external one. Also to remove as much variation as possible, put BOTH of them in the disable mode (but not holdover mode) and manually adjust their setting so they both read about the same values for their Phase and freq. Now you're suggesting making a better Tbolt Tic by using two and comparing their differences. Have to think that over a little, sounds like a good plan, But so far have not seen anyone else that will even try it with one. Thanks, I'm now thinking about how to use two external Tbolts in a setup more like a DUAL Phase thing. The GPS signal can be the Offset osc and therefore will have little effect. The GPS will just act as a near zero offset frequency osc, and watching the phase differences between the two Tbolts, should work fine. Thanks, so many fun things still to play with. ws * Hi Warren, What is not too clear is how much of that is due to the Tbolt engine and how much is the GPS Reference. Do you have two working Tbolts with their orginal oscillator removed? From what I've seen in my test, a large amount of that noise floor is due to the GPS. I think a dual Tbolt configuration would eliminate GPS instabilities and rely more on the house standard. As proposed in previous email. -- Björn * snip I propose an experiment with two Tbolts running from the same antenna and sharing the same oscillator, ie at least one of the Tbolts modified to accept external 10MHz. This would take out most/all GPS system errors, leaving receiver measurement noise. When speaking of 1-shot resolution I think a dual-Tbolt configuration, with one driven by the DUT and the other by the house standard, is closer to a fair comparison with a TIC instrument. Since this configuration will eliminate the GPS system and propagation errors and the TIC is always limited by the house standard. Does anyone have two working Tbolts modified for external oscillator available for testing? I have one Tbolt and a loaner unit from a friend. I am not very keen on modifying the two I have in my lab right now. kind regards, Björn ___ 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] Measuring ADEV using TBolt-Tic tester
John wrote: I'm curious where you got the noise data for the TBolt GPS engine Besides the measured ADEV plot I posted at http://www.febo.com/pipermail/time-nuts/attachments/20111007/48d1ab68/attachment-0001.gif Attached is another way I've measured Phase noise of the Tbolt, to optimizing its antenna system. This LH plot shows a total phase noise (GPS, + TBolt + Osc) of 0.087 ns RMS reading to reading variation at one second update, over a time period of 26 minutes using a one second disiplined loop. This is the same as 0.87 e-10 RMS freq noise if using a 1 second time base. On this test, I set the Tbolt's Time Constant to 1 second and its damping to 10. (The Dac gain must be set right on to work right) This causes the Tbolt's discipline loop to correct any phase error due to noise on the very next 1 sec update by stepping the Oscillator's frequency. This Is an easy way to measure the reading to reading phase difference using just LadyHeather. The data can also be interpreted.as the average RMS frequency variation over 1 second, which is approximately equal to the ADEV value at a tau of one second (1e-10). example: If the first phase reading where zero and the next one is +1ns then the control loop will change the Osc freq by way of its EFC, by 1e-9 so that the very next phase difference is zero again. This makes it into a 1 sec delayed TPLL (Tight Phase Lock Loop). I ran this same test on John's Online Tbolt. Its phase noise measured 0.13 ns RMS. Most of the difference was caused by satellites switching during the test. Each switch causes a ns or so noise spike when the number of satellites changed. I also tried several other test including using just one bird with no switching. That was more than twice as noisy depending on which satellite bird I selected. I'd like to see what the Phase noise is of other Tbolts using this same method, especially when using a good choke ring antenna that has a good sky view. ws * ws at Yahoo wrote: The noise data is my measured values which I do several different ways. Some of which are: The GPS engine value was calculated from measuring the UNFILTERED RMS noise of the freq plot data using LadyHeather, backed up by the independent way of looking at the UNFILTERED 1 sec ADEV values obtained when plotting the ADEV from that data using an external low noise osc. The other proof that the data is unfiltered was done by black box testing of small near instantaneous freq changes of 1e-10 and measuring and how long it took the Tbolt plot to settle to the new freq value using different filter setting. The answer is that it knows the correct freq (within it's nose limits) in the next 1 sec sample period when the filter is turned off. As for the ns phase noise that is the RMS Phase noise value from LH using a good LPRO osc with it's Time constant set to many hrs. (Phase correction TC was 100K sec). The RMS noise value is very insensitive to the filter setting up to 1000 seconds because most of the phase noise is slower than 1000 seconds. As far as the 4 to 10 ns day to day USNO data , that has nothing to do with sub ns short term noise which I generally limit to more like a few minutes of sampel time, and if there is a satellite change during the test run, then I start the test over because I'm looking at GPS engine noise and not the GPS noise causes by changing satellites etc. As far as the 4 to 10 ns over a two day period, that agrees pretty well with what I see some times on a bad day. On a good day I can get more like 2 to 3 ns, with a 500 sec filter, on a bad day up to 5 or 6 ns. For some periods lasting up to 5 to 6 hrs, I've seen numbers as low as 1.5 ns RMS. ws ** From: John Ackermann N8UR In that test I was just capturing the ADEV table from the TSC-5120 so don't have raw phase data. I'm curious where you got the noise data for the TBolt gps engine -- that's far better than I've seen quoted before. The Trimble data sheet that I found specs the system PPS accuracy at 20 nanoseconds one sigma; they don't separately spec the GPS engine. (The data sheet for the current Thunderbolt E data sheet says 15 nanoseconds.) The USNO says that their filtered, linear fit time transfer measurements over a two day period, over the entire constellation, have an RMS residual of 4 to 10 nanoseconds without SA (http://tycho.usno.navy.mil/gpstt.html). That may not be apples-to-apples methodology, but it implies that sub-nanosecond results may be difficult to obtain. John attachment: ws-tb-10-12.gif___ 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] [volt-nuts] Safe power-up. was (Solartron 7075 ...)
Peter Gottlieb nerd at verizon.net wrote: 99% of the time I just plug things in and see what happens. I do fix a lot of stuff, though, Hmmm, I have to wonder if there is more than a casual cause and effect relationship between those two statements. I've seen a strong relationship between the wasted time spent fixing extra things that where fried unnecessary, with how careful one is at initial turn on. Monitoring the wattage, using a Kill-A-Watt meter when turning on Old things can save 'futzing time' in the long run. And the most time saving thing I've found besides apply power and throw it out if there is smoke or nothing, is to do a complete visual inspection inside, to insure things are still the way they where designed to be, BEFORE applying any power. Yes Variac, My spell checker thanks you for teaching it the correct spelling. I find it one of the more useful pieces of test equipipment when checking/modifying things to get max Nut-Precision from them. If changing the line voltage or the temperature a little causes ANY measurable effect on performance, then for me, it's time to change something and made it better, which can often be done with just simple changes (and a lot of futzing time). ws Peter Gottlieb nerd at verizon.net Hmmm. 99% of the time I just plug things in and see what happens. That's what they were designed to do. If something pops I fix it from there. If a fuse keeps blowing I use the light bulb in series trick. On older tube gear I do softly bring it up with the variable autotransformer (Variac, Powerstat), but that's only really because of the capacitors. Just my 2 cents. I do fix a lot of stuff, though, and don't like to waste time futzing when I don't have to. Weak parts get replaced. If they were likely to fail enough to do so when I just plug something in, they need replacing anyway. ** On 10/11/2011 1:14 AM, David J Taylor wrote: The proper use of the variact's output voltage has a learning curve, because equipment with switchers behave differently than things with linearly supplies ws Warren, It's likely Variac you mean, not variact http://en.wikipedia.org/wiki/Variac#Variable_autotransformers Cheers, David ___ 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.
