[time-nuts] Using Allan Plots, was(LPRO-101 with Brooks Shera's GPS locking circuit)

Ulrich Bangert df6jb at ulrich-bangert.de
Mon Dec 18 04:46:18 EST 2006


Hi Brooke,

with this specs Stanford Research says: The sheer numerical resolution
that the SR620 can display/signalize using IEEE488 is 1 ps. In addition
the counter shows a 1 sigma 20 ps noise from measurement to measurement
due to a lot of different effects in the inside electronics. In this
case the additional noise dominates the noise introduced by resolution
and the specs are to be understood as a warning that unlike with many
other digital equipment you should in this case not confuse numerical
precision with measurement precision.

Having these specs at hand you don't need to make a single measurement
to determine the TIC's Allan plot: It will be a straight line starting
at 2E-11 @ 1 s and having a slope of -1. If you are eager for making a
measurement of your own: Let the SR620 make time interval measurments on
pps signals that are derived from its own timebase. I am not aware of
the SR620's trigger capabilities: If it can start and stop on a signal
in the same input channel you need only one divider. Otherwise you need
two dividers to feed the start and the stop channel independend. Using
the own timebase for the measurement will remove effects from long time
oscillator drifts which would otherwise show up in the plot. If you use
a external time base then use this one for generating the 1pps.

As you see the SR620 (although being the more modern device) compares
well to what can be done with a HP5370A/B for which resolution and noise
are almost the same. The HP5370's resolution could have easily been
increased by orders of magnitude with slightly increased time necessary
per measurement. I guess the HP engineers stopped to increase the
reolution at 20 ps when they saw that below this value other effects in
the electronics especially in the trigger circuits would dominate the
overall noise of the counter.

Perhaps you are a bit disappointed but even with a fine instrument like
the SR620 you will not be able to measure Allan Deviation of good
oscillators directly without further tricks because their ADEV is an
order of magnitude smaller at observation times 1-100 s.

Best regards
Ulrich Bangert, DF6JB 

> -----Ursprüngliche Nachricht-----
> Von: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] Im Auftrag von Brooke Clarke
> Gesendet: Sonntag, 17. Dezember 2006 19:14
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] Using Allan Plots, was(LPRO-101 with 
> Brooks Shera's GPS locking circuit)
> 
> 
> Hi Ulrich:
> 
> Thanks very much for your email of 16 December it's a big 
> help for me to 
> understand how to use Allan plots.  I would like to learn more about 
> their application to Time Interval Counters.  For example I have the 
> SR620 and although the one shot resolution is 1 ps the one shot 
> precision is specified as 20 ps.  What test can be done to 
> determine an 
> Allan plot for a TIC?
> 
> Have Fun,
> 
> Brooke Clarke
> 
> w/Java http://www.PRC68.com
> w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
> http://www.precisionclock.com
> 
> 
> 
> Ulrich Bangert wrote:
> 
> >Brooks, Brooke and Bruce,
> >
> >1) I do not want to talk bad Brooks Shera's design. In fact 
> i admire it 
> >a lot for its simpicity. It was the first to be published in amateur 
> >literature and that makes it easily the best available in 
> amateur use 
> >for a long time. And I learned lots from it. Indeed i needed 
> weeks to 
> >understand how some subtle ingredients go ahead hand in hand to make 
> >the whole thing work, the short measurement times that i 
> talked about 
> >being one of them. The original QEX publication was surely a 
> >breakthrough in amateur technology.
> >
> >2) One of the things that the original publication lacks is 
> a in-depth 
> >rule on how to set the loop time constant correct for a 
> given LO. When 
> >i was new into this topic it was kind of my belief that 
> choosing this 
> >parameter correct was the 'black art' in constructing a good 
> frequency 
> >standard and I wanted to learn more about it. Today i know, 
> that only 
> >ONE SIMPLE RULE applies to this question despite the fact that some 
> >math for drawing tau-sigma-diagrams is indispensable.
> >
> >3) This rule is: An OXCO has a banana like tau-sigma-diagram 
> with the 
> >lowest ADEV anywhere between 10-100 s. A GPS receiver's 
> >tau-sigma-diagram is a straight line with a slope of -1 starting 
> >anywhere from ADEV 2E-8 @ 1 s to 1E-7 @ 1 s depending on the 
> receiver. 
> >Note that these receiver figures apply to raw, not sawtooth 
> corrected 
> >values. Now have a look to where the lines meet each other. 
> Left from 
> >that point the OCXO's ADEV is smaller then the GPS receiver's. Right 
> >from that point the GPS receiver's ADEV is smaller the the OCXO's. 
> >There is no guessing or speculating at all: The loop time 
> constant MUST 
> >be set to where the meeting point is. If it is set to anything else 
> >this will make the ADEV of the standard's output more worse than is 
> >necessary. Note that the OCXO's tau-sigma is already on its 
> ASCENDING 
> >slope where the lines meet.
> >
> >4) From that simple rule a complete briefing for the 
> construction of a 
> >good frequency standard may be deduced:
> >
> >a) Because left of the meeting point the standard's output 
> stability is 
> >only a function of the OCXO's stability and NOTHING ELSE choose the 
> >best available LO in terms of ADEV up to the expected 
> meeting point of 
> >the lines. For this purpose a GOOD xtal oscillator may by 
> all means be 
> >better than a Rb! Perhaps the people that are going to 
> discipline a Rb 
> >with GPS may be disappointed: While the Rb is much easier to 
> discipline 
> >due to its smaller sensibility to environmental changes a good xtal 
> >oscillator (the key word is: good. And good means: better than a
> >HP10811) may outperform a Rb based standard in terms of ADEV 
> for short 
> >observation times. @1 to some 10 s the HP10811 is better in 
> ADEV than 
> >most Rbs. However up from there its ADEV goes up steeper 
> than that of 
> >an thermically better managed USO like a FTS1000/1200. An 
> even better 
> >choice but beyond the financial scope of most of us were a BVA based 
> >oscillator.
> >
> >b) Because the meesting point is always on the the OCXO's ascending 
> >slope choose the best available receiver in terms of how 
> high it's -1 
> >slope tau-sigma is located. The less high the absolute 
> position of his 
> >tau-sigma is, the more left (=earlier) the meeting point 
> will be. The 
> >more left the meeting point is the less the overall ADEV of the 
> >standard's output will be deteriored by the OCXO for 
> observation times 
> >near the meeting point due to its ascending ADEV slope.
> >
> >c) The TIC measurement resolution must be high enough to not 
> deterior 
> >the phase measurements by the sheer measurement 'granularity'.
> >
> >Some graphics might be helpfull in understanding this. Have 
> a look to 
> >page 22 of
> >
> >http://www.ulrich-bangert.de/AMSAT-Journal.pdf
> >
> >which i wrote for the German AMSAT journal. Don't worry over the 
> >German, just look to the pictures. In this graphic both the 
> tau-sigma 
> >of a HP10811 and a M12+ are drawn into the same diagram and 
> according 
> >to 4) it becomes immediatly clear why we want the OCXO as stable as 
> >possible before the meeting point and the receivers 
> tau-sigma as low as 
> >possible to make the meeting point as early as possible.
> >
> >Exactly this is the point where i fear that you, Brookes, are the 
> >victim of a basic misconception, at least your comment makes 
> me think 
> >so:
> >
> >  
> >
> >>>I believe the sawtooth correction is of little or no value for a
> >>>GPSDO,
> >>>which typically requires a low pass filter between the GPS 
> >>>      
> >>>
> >>1pps and the
> >>    
> >>
> >>>disciplined oscillator.  This filter is quite effective in
> >>>      
> >>>
> >>removing the
> >>    
> >>
> >>>sawtooth quantization introduced by the GPS rcvr clock,
> >>>      
> >>>
> >>just as it removes
> >>    
> >>
> >>>the similiar quantization caused by my phase detector.
> >>>      
> >>>
> >
> >This indicates that you are believing that it can all be 
> done with low 
> >pass filtering. And this is wrong for two reasons:
> >
> >a) As Bruce and TVB have pointed out there are 'anomalies' in a GPS 
> >receiver's raw pps (well documented on TVB's web pages) 
> where the idea 
> >that lowpass filtering the raw phase data will do the job is simply 
> >unsustainable.
> >
> >b) Low pass filtering is a trade with nature: You can get better 
> >precision due to low pass filtering but you have to pay for 
> it in terms 
> >of time that you have to wait for the samples to avarage over. Look 
> >again at page 22 of
> >
> >http://www.ulrich-bangert.de/AMSAT-Journal.pdf
> >
> >and ask yourself what the noisefloor of you circuit would 
> look like in 
> >this diagram. I tell you: Even if you had the best current 
> GPS receiver 
> >available your phase measurements would be dominated by a noisefloor 
> >induced by the 4E-8s single shot resolution of your TIC giving a 
> >straight line starting at 4E-8 @ 1 s and having a slope of -1 i.e. a 
> >line that runs parallel to the M12+ graph but a factor 2 higher in 
> >absolute terms. Low pass filtering = averaging means nothing 
> else than 
> >running up and down the line. Go to any point of time on the 
> horizontal 
> >axis and draw a vertical line there. Where this line meets your 
> >noisefloor draw a horizontal line and on the vertical axis read the 
> >precision that you gain if you average over that time. It is 
> as easy as 
> >that. And to find out when you reach a certain precision go to that 
> >precision on the vertical axix and draw a horizontal line. 
> Where this 
> >line meets your noisefloor draw a vertical line and read the 
> necessary 
> >averiging time on the horizontal axis. And note that this horizontal 
> >line drawn in the last example has crossed the M12+'s line 
> by a factor 
> >of 2 earlier! That is: the sheer measurement resolution of 
> 4E-8 s has 
> >DOUBLED the averaging time necessary to come to a certain given 
> >precision.
> >
> >At a first glance this may be not so impressive: Instead of 10 s we 
> >have to wait 20 s with your circuit to get the precision that the 
> >receiver alone has already after 10 s. Why do I make that 
> heck out of 
> >it? Don't we have these 10 additional seconds? Please read on: The 
> >M12+'s sigma-tau shown un the diagram is the one for the raw phase 
> >data. If the sawtooth correction is taken into account the 
> line starts 
> >at an ADEV of 2E-9 @ 1 s. Unfortunately its slope is less than -1 so 
> >the factor 10 increase in precision does not hold for all oservation 
> >times. At observation times of app. 1 day the two lines 
> meet, giving an 
> >improvement in using the sawtooth corrected values only for 
> observation 
> >times < 1 day. In
> >
> >http://www.ulrich-bangert.de/html/photo_gallery_44.html
> >
> >you can see the sigma-taus for the raw and the corrected data from a
> >M12+ drawn into the same diagram. With a good OCXO the meeting point
> >between receiver tau-sigma and OCXO tau-sigma is in to order 
> of 1000 s. 
> >1000 s are small against a day, that means that almost the full 
> >possible improvement in ADEV by using the sawtooth corrected values 
> >apply to the case of a loop time constant of 1000. This 
> factor of 10 in 
> >conjunction with the factor of 2 that we had before results in the 
> >factor of 20 that i claim that the noisefloor ot your circuit is 
> >inferior to that of a modern GPS receiver. And of course my 
> claim stays 
> >intact!
> >
> >Some of you may now scratch your head and say: "Well...yes 20 is a 
> >handfull! With the Shera circuit we will have to wait 20 
> times the time 
> >that is necessary due to GPS 1pps jitter alone, but isn't it more 
> >important that we reach this precision/stability (in a sense 
> these two 
> >words are synonyms in this discussion) AT ALL with the Shera 
> circuit?"
> >
> >This is EXACTLY where the misconception starts. If someone 
> is claiming: 
> >"I can average over 30s to get an improved measurement 
> precision." I am 
> >going to ask him: "Hey, why don't you average over 300 s, 
> giving you an 
> >additional factor 10 improvement." The answer might be: 
> "Yes, perhaps I 
> >could do. It depends.." My next question were: "Depends? Depends on 
> >what? If every factor 10 in measurement averaging results in 
> a factor 
> >10 in measurement precision, why not even average over 30000 
> or 300000 
> >s ??" I know the next answer very well in advance: "Oh no, i 
> can't do 
> >THAT. While the argument of improving the measurement precision is 
> >right, i can't make use of this precision because my OCXO 
> has drifted 
> >too much away if I wait THIS long!" AAHH! You have to take your OCXO 
> >into account? And yes, that is correct, but it is correct in a 
> >different sense than you may think!
> >
> >It is correct in the sense that i tried to explain before: The 
> >tau-sigmas of the OCXO and the receiver meet each other and 
> where they 
> >meet depends ONLY on
> >
> >a) receiver quality in terms of ADEV
> >
> >b) OCXO quality in terms of ADEV
> >
> >c) TIC's noise floor
> >
> >In reality you are not free to choose "I want to average 
> over 30 s" or 
> >"I want to average over 100 s". Instead the simple rule 
> DICTATES that 
> >you HAVE to set your averaging time to the meeting point's 
> x-axis value 
> >and to nothing else. There is simply no use in saying: "But 
> with such 
> >and such averaging times i would reach a precision of such 
> and such". 
> >You cannot choose! The physical properties of your receiver, 
> your ocxo 
> >and your TIC dictate it!
> >
> >Since we now know what 'averaging' is all about let us now consider 
> >again at which ADEV the two tau-sigmas meet. Clearly we want to make 
> >the ADEV at this point as small as possible as it represents a local 
> >maximum in the overall tau-sigma of the standard's output. 
> Since we are 
> >on the ascending slope of the OCXO our interest must be that 
> the lines 
> >meet AS EARLY as possible. Since we cannot do anything on 
> the -1 slope 
> >of the receiver's tau-sigma we achieve this only by shifting the 
> >absolute position of the tau-sigma as low as possible. This 
> in turn is 
> >achieved by using the best available receiver AND using the sawtooth 
> >correction. A TIC resolution of 4E-8 shifts the meeting 
> point a factor 
> >of 20 more to the right than would be necessary with a good 
> receiver. 
> >Since I admire it a lot what you do, Brookes, i would be glad if you 
> >could gain the insight that averaging over raw phase data is 
> something 
> >VERY DIFFERENT from using sowtooth corrected values.
> >
> >  
> >
> >>Hi Ulrich:
> >>
> >>I think the answer is what other low cost options
> >>are available?  I would like to have a more modern 
> >>TIC capability to add to the clock I'm working on.  
> >>But although there's been a lot of discussion about 
> >>different ways of making TIC measurements, it's not 
> >>clear to me how to do it on a budget.
> >>
> >>For example the TIC232 circuit by Richard H McCorkle
> >>is easy to implement, but how good is it's noise floor.
> >>See:
> >>
> >>http://www.piclist.com/techref/member/RHM-SSS-SC4/TIC232.htm
> >>
> >>Then there's the low cost frequency counting TIC that appeared
> >>in QEX that we know trades performance for low cost so it's 
> >>not a candidate.
> >>
> >>Any ideas on what circuits have a noise floor that's compatible
> >>with the M12+T or it's newer equivalents and at the same time are 
> >>in the low cost category? 
> >>    
> >>
> >
> >Brooke, looking at the web page and the circuit diagram I second 
> >everything that Bruce has already said to it. This one uses a 16 MHz 
> >TIC time base and therefore its performance is even worse 
> compared to 
> >Brooks's circuit. This one has its tau-sigma starting point 
> at 62E-9 @ 
> >1 s, abt. 30 times worse than the M12+.
> >
> >If it can be done 'on a budget' as you say depends a bit on what you 
> >would call 'a budget' but it can surely not being done better if you 
> >have the Shera design prices in your head! In my own DIY 
> GPDSO I do it 
> >using a delay chain out of the fastest interconnection elements 
> >available in a ALTERA Flex10K10 gate array, giving 110 ps 
> resolution. 
> >That chip is surely not more than 50 US$ in single quantities. 
> >Unfortunately the delay of a single element of this delay 
> line depends 
> >on chip temperature and supply voltage so that the lines need to be 
> >'calibrated' on a cyclic base. While this is done in the controllers 
> >firmware it makes the whole circuit a bit tricky. I currently try to 
> >migrate the design into a XILINX Spartan III fpga XC3S400 
> worth 25 US$ 
> >in single quantities. Let us see what 2007 has to bring for us.
> > 
> >  
> >
> >>One can only achieve the subnanosecond resolution required to avoid
> >>degrading the performance of an M12+ by using a clock 
> >>frequency of 1GHz or more. Thus this method is probably too 
> >>expensive and difficult to implement. 
> >>    
> >>
> >
> >Bruce, the clue is NOT to go out for a high clock frequency. Instead 
> >search for sub-clock interpolation schemes. Lots of them are 
> available!
> >
> >Best regards
> >Ulrich Bangert, DF6JB
> >
> >
> >  
> >
> >>-----Ursprüngliche Nachricht-----
> >>Von: time-nuts-bounces at febo.com
> >>[mailto:time-nuts-bounces at febo.com] Im Auftrag von Dr Bruce 
> Griffiths
> >>Gesendet: Samstag, 16. Dezember 2006 02:00
> >>An: Brooks Shera; Discussion of precise time and frequency 
> measurement
> >>Betreff: Re: [time-nuts] LPRO-101 with Brooks Shera's GPS 
> >>locking circuit
> >>
> >>
> >>Brooks Shera wrote:
> >>    
> >>
> >>>----- Original Message -----
> >>>From: "Ulrich Bangert" <df6jb at ulrich-bangert.de>
> >>>To: "'Discussion of precise time and frequency measurement'"
> >>><time-nuts at febo.com>
> >>>Sent: Friday, December 15, 2006 05:47
> >>>Subject: Re: [time-nuts] LPRO-101 with Brooks Shera's GPS 
> >>>      
> >>>
> >>locking circuit
> >>    
> >>
> >>>.......
> >>>  
> >>>      
> >>>
> >>>>I second Bruces's opinion about what is an overshot or
> >>>>        
> >>>>
> >>not. When ps
> >>    
> >>
> >>>>reolution is ready available then why not use it? I attach
> >>>>        
> >>>>
> >>a online
> >>    
> >>
> >>>>output from my DIY GPSDO from a few minutes ago that shows
> >>>>        
> >>>>
> >>the M12+'s
> >>    
> >>
> >>>>signal properties when measured with abt. 110 ps
> >>>>        
> >>>>
> >>resolution against a
> >>    
> >>
> >>>>FTS1200. The yellow line reperesents a prefiltered version of the
> >>>>sawtooth corrected values (blue). The filter time constant 
> >>>>        
> >>>>
> >>is 1/3 of
> >>    
> >>
> >>>>the loop time constant as in a PRS-10. The yellow values
> >>>>        
> >>>>
> >>are the ones
> >>    
> >>
> >>>>to feed the regulation loop.
> >>>>    
> >>>>        
> >>>>
> >>>  
> >>>      
> >>>
> >>>>What I wanted to explain is the Shera concept noise floor
> >>>>        
> >>>>
> >>is a factor
> >>    
> >>
> >>>>20 above what a modern receiver can deliver (again inc.
> >>>>        
> >>>>
> >>the sawtoth
> >>    
> >>
> >>>>correction). And yes, you are right: There were different numbers
> >>>>when this concept was thought out! And exactly because different 
> >>>>number were there when this concept was thougt out I am 
> >>>>        
> >>>>
> >>going to ask
> >>    
> >>
> >>>>why people still built it today.
> >>>>    
> >>>>        
> >>>>
> >>>  
> >>>      
> >>>
> >>>>Best regards
> >>>>Ulrich Bangert, DF6JB
> >>>>    
> >>>>        
> >>>>
> >>>I believe the sawtooth correction is of little or no value for a
> >>>GPSDO,
> >>>which typically requires a low pass filter between the GPS 
> >>>      
> >>>
> >>1pps and the
> >>    
> >>
> >>>disciplined oscillator.  This filter is quite effective in
> >>>      
> >>>
> >>removing the
> >>    
> >>
> >>>sawtooth quantization introduced by the GPS rcvr clock,
> >>>      
> >>>
> >>just as it removes
> >>    
> >>
> >>>the similiar quantization caused by my phase detector.
> >>>
> >>>For example, reading from your graph I averaged the raw
> >>>      
> >>>
> >>data (as best
> >>    
> >>
> >>>I
> >>>could by reading the blue line).  The running average of
> >>>      
> >>>
> >>the raw data over
> >>    
> >>
> >>>40 sec (starting at 12:31:30) was -4.5 nsec, after 60 sec
> >>>      
> >>>
> >>it was -4.2 nsec.
> >>    
> >>
> >>>These values appear to be indistinguishable from the values
> >>>      
> >>>
> >>you get by
> >>    
> >>
> >>>averaging the "sawtooth corrected" data (the yellow line).
> >>>
> >>>It appears from your plot that the sawtooth correction has
> >>>      
> >>>
> >>contributed very
> >>    
> >>
> >>>little or nothing that averaging does not already provide. 
>   Have I 
> >>>misunderstand something?
> >>>
> >>>I believe that your "noise floor is a factor 20 above what a modern
> >>>receiver
> >>>can deliver" statement is incorrect.  With an HP 5720B 
> >>>      
> >>>
> >>(about 100 psec
> >>    
> >>
> >>>resolution), I have measured the phase difference between
> >>>      
> >>>
> >>the GPS 1pps and
> >>    
> >>
> >>>the phase of a 5 MHz oscillator controlled by my
> >>>      
> >>>
> >>controller. This data has
> >>    
> >>
> >>>been compared with simultaneous phase serial output from
> >>>      
> >>>
> >>the controller as
> >>    
> >>
> >>>determined its maligned 24 MHz asynchronous internal phase
> >>>      
> >>>
> >>measurement
> >>    
> >>
> >>>circuitry.
> >>>
> >>>ADEV Stable 32 plots of both data sets are essentially identical.
> >>>From this
> >>>I conclude that nothing would be gained, for the purpose of 
> >>>      
> >>>
> >>discipling an
> >>    
> >>
> >>>oscillator, by using a more elaborate and expensive phase
> >>>      
> >>>
> >>detector  (the
> >>    
> >>
> >>>phase detector in my controller costs $6.61, including
> >>>      
> >>>
> >>$5.35 for the dual 24
> >>    
> >>
> >>>MHz osc that is shared as the PIC clock).  It was my goal
> >>>      
> >>>
> >>when I designed
> >>    
> >>
> >>>the controller was to make the design transparent to the
> >>>      
> >>>
> >>builder and to use
> >>    
> >>
> >>>as few parts as necessary consistant with performance
> >>>      
> >>>
> >>limited only by
> >>    
> >>
> >>>available GPS receivers and VCXOs.  When I wrote the QST
> >>>      
> >>>
> >>article I was
> >>    
> >>
> >>>totally ignorant of the fact that I could buy the HP58503
> >>>      
> >>>
> >>with similiar
> >>    
> >>
> >>>performance for $5400.
> >>>
> >>>Your earlier comment about the capture range of the phase
> >>>      
> >>>
> >>detector is
> >>    
> >>
> >>>well
> >>>taken.  For the past several years the PIC software I
> >>>      
> >>>
> >>provide has included
> >>    
> >>
> >>>an option designed for use with inexpensive TCVCXOs.  It
> >>>      
> >>>
> >>requires only an
> >>    
> >>
> >>>external 128 divider chip and produces EFC voltages
> >>>      
> >>>
> >>suitable for inexpensive
> >>    
> >>
> >>>oscillators.  It works very well and provides sufficient
> >>>      
> >>>
> >>performance for
> >>    
> >>
> >>>many applications.
> >>>
> >>>Regards,  Brooks
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>------------------------------------------------------------
> ----------
> >>    
> >>
> >>>----------
> >>>
> >>>
> >>>  
> >>>      
> >>>
> >>>>_______________________________________________
> >>>>time-nuts mailing list
> >>>>time-nuts at febo.com
> >>>>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >>>>    
> >>>>        
> >>>>
> >>>_______________________________________________
> >>>time-nuts mailing list
> >>>time-nuts at febo.com
> >>>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >>>
> >>>  
> >>>      
> >>>
> >>Brooks
> >>
> >>Your comparison of your circuit with measurements taken with
> >>the "5270" 
> >>(is this a typo? did you mean 5370? which is known to have  
> >>differential 
> >>non linearities well in excess  of  100 picoseconds,  at 
> >>least according 
> >>to the designers - some later modifications  to the 
> circuitry reduced 
> >>this effect somewhat) demonstrates very little unless the 
> >>measurements 
> >>were corrected for the sawtooth error.
> >>
> >>The only true test is to compare a sawtooth corrected
> >>GPSDOCXO alongside 
> >>a sawtooth corrected GPSDOXO. Both should of course use equivalent 
> >>performance oscillators and GPS timing receivers.
> >>
> >>The short plot that Ulrich furnished doesn't include any
> >>hanging bridges 
> >>which occur when the GPS oscillator drifts through a harmonic 
> >>of 1Hz. Most M12+ GPS timing receivers produce sawtooth 
> >>correction errors in 
> >>which such "hanging bridges" are not infrequent.
> >>
> >>No one is disputing that with an low performance oscillator its not
> >>worth going to too much trouble in improving the phase 
> >>detector performance. However some of us have oscillators 
> >>with much better performance than 
> >>such cheap oscillators. We also have a need to achieve an 
> oscillator 
> >>instability of less than a few parts in 1E12 which your 
> >>circuit cannot 
> >>reliably provide in the presence of hanging bridges and 
> aberrant PPS 
> >>pulses which do occur from time to time.
> >>
> >>The existence of a commercial GPSDOCXO that achieves an Allan
> >>variance 
> >>of 2E-13 or better from tau = 1 sec to 1 year, indicates that it is 
> >>possible to do much better than your circuit is capable of. 
> >>All we are 
> >>doing is exploring cheaper ways of approaching this 
> >>performance within a 
> >>factor of 10 or so.
> >>
> >>Bruce
> >>
> >>_______________________________________________
> >>time-nuts mailing list
> >>time-nuts at febo.com
> >>https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> >>
> >>    
> >>
> >
> >
> >_______________________________________________
> >time-nuts mailing list
> >time-nuts at febo.com 
> >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >
> >  
> >
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> 




More information about the time-nuts mailing list