From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Subject: Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit Date: Sat, 16 Dec 2006 15:56:32 +0000 Message-ID: <29148.1166284592@critter.freebsd.dk> > In message <000001c72126$ecc89270$0202fea9@athlon>, "Ulrich Bangert" writes: > >Poul, > > > >i appreciate your comments always a lot! But dynamical methods are > >especially usefull when the input parameters are subject of change, > >aren't they? > > They are also very useful for amateur projects where the users do > not have the necessary measurement facilities and likely use random > components bought on ebay :-) Indeed. If you buy a particular GPS diciplination kit, only the TIC performance is assumed to be known. If you include serial communication (to allow for sawtooth corrections) to the GPS, for some receivers we could have included apriori knowledge (since we now may ask the GPS what type it is), but not for all. Many GPS receiver do not emit sawtooth corrections unfortunatly. Also, the big range of oscillators being trained is not under control. Also, the actual condition of one such oscillator may deviate from another measured, so it is really only in the experienced time-nut (type of person rather than list member) hands that the actual values could be used as a priori knowledge. Also, if an oscillator has been knocked around etc, it will have worse ADEV than when it has healed itself. So not being overly dependent on a priori knowledge might actually be a key for optimum performance not on average but rather in the momemnt. This is kind of the point of using GPS steering IMHO. > >But how would you solve the system of equations with TWO > >unknowns (LO and GPS jitter) if you have only ONE information? > > The way you do this is by measuring the ADEV between your two sources > and how it changes with changes in your timeconstant. I.e. out of your TIC. The trouble is that you do not get one result but several. Either you just drive the time-constant to minimize ADEC(100) or something or you are a little more creative and make a (possibly weighted) sum of a few ADEVs (say 10, 30, 100, 300 and 1000) and then let that be the parameter to be minimized. Maybe an integral over ADEV to integrate the energy would be appropriate, maybe not. However, there have already been work done that shows painstakingly well that this is a task for Kalman filters and these days we should also have a look at particle filters. This is computingwise more complex than the above solution, but may be of interest if one wants go further. I think that something like the above may be helpfull, althought not being done as scientifically as Ulrich explanation. > In my experience, the better way is to start with a short timeconstant > and increase it, until the ADEV shows signs of detoriation. That should be simple enought to put into a PIC or AVR for a dirt-cheap solution. To keep tracking the time constant to actual performance it can then wiggle it up and down and decide if a step up or down is to be done. Cheers, Magnus

In message <20061216.171802.-1808230165.cfmd@bredband.net>, Magnus Danielson writes: >> The way you do this is by measuring the ADEV between your two sources >> and how it changes with changes in your timeconstant. > >I.e. out of your TIC. The trouble is that you do not get one result but >several. Either you just drive the time-constant to minimize ADEC(100) or >something or you are a little more creative and make a (possibly weighted) >sum of a few ADEVs (say 10, 30, 100, 300 and 1000) and then let that be the >parameter to be minimized. Maybe an integral over ADEV to integrate the >energy would be appropriate, maybe not. No, that is too simple. Both OCXO and Rb units have the same basic ADEV shape and all GPS receivers have the same basic ADEV curve and the combined ADEV curve has a limited range of shapes. All you need to do is monitor the shape and you know if your timeconstant is too short or too long. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Subject: Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit Date: Sat, 16 Dec 2006 17:06:00 +0000 Message-ID: <29410.1166288760@critter.freebsd.dk> > In message <20061216.171802.-1808230165.cfmd@bredband.net>, Magnus Danielson writes: > > >> The way you do this is by measuring the ADEV between your two sources > >> and how it changes with changes in your timeconstant. > > > >I.e. out of your TIC. The trouble is that you do not get one result but > >several. Either you just drive the time-constant to minimize ADEC(100) or > >something or you are a little more creative and make a (possibly weighted) > >sum of a few ADEVs (say 10, 30, 100, 300 and 1000) and then let that be the > >parameter to be minimized. Maybe an integral over ADEV to integrate the > >energy would be appropriate, maybe not. > > No, that is too simple. > > Both OCXO and Rb units have the same basic ADEV shape and all > GPS receivers have the same basic ADEV curve and the combined > ADEV curve has a limited range of shapes. All you need to do > is monitor the shape and you know if your timeconstant is too > short or too long. Hmm, yes indeed. Also recall that the GPS receiver and TIC have similar ADEV shapes. You still want to produce some form of quality measure for the ADEV shape in order to form some form of control loop. It needs to be articulated. Cheers, Magnus

In message <20061216.204606.2086054816.cfmd@bredband.net>, Magnus Danielson writes: >You still want to produce some form of quality measure for the ADEV shape in >order to form some form of control loop. It needs to be articulated. Yes. I'll leave this as an exercise to the reader, only with the footnote that what Dave Mills (and Ulrich) has decribed is close to correct, but not quite :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

> Yes. I'll leave this as an exercise to the reader.... Oh dear, this one follows me since my university days centuries ago! Ulrich Bangert, DF6JB > -----Ursprüngliche Nachricht----- > Von: time-nuts-bounces@febo.com > [mailto:time-nuts-bounces@febo.com] Im Auftrag von Poul-Henning Kamp > Gesendet: Samstag, 16. Dezember 2006 20:52 > An: Magnus Danielson > Cc: time-nuts@febo.com > Betreff: Re: [time-nuts] LPRO-101 with Brooks Shera's GPS > locking circuit > > > In message <20061216.204606.2086054816.cfmd@bredband.net>, > Magnus Danielson writes: > > >You still want to produce some form of quality measure for the ADEV > >shape in order to form some form of control loop. It needs to be > >articulated. > > Yes. I'll leave this as an exercise to the reader, only with > the footnote that what Dave Mills (and Ulrich) has decribed > is close to correct, but not quite :-) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > > _______________________________________________ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts >

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@febo.com >>[mailto:time-nuts-bounces@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@ulrich-bangert.de> >>>To: "'Discussion of precise time and frequency measurement'" >>><time-nuts@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@febo.com >>>>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>>> >>>> >>>> >>>_______________________________________________ >>>time-nuts mailing list >>>time-nuts@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@febo.com >>https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts >> >> >> > > >_______________________________________________ >time-nuts mailing list >time-nuts@febo.com >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > >

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@febo.com > [mailto:time-nuts-bounces@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@febo.com > >>[mailto:time-nuts-bounces@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@ulrich-bangert.de> > >>>To: "'Discussion of precise time and frequency measurement'" > >>><time-nuts@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@febo.com > >>>>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>time-nuts mailing list > >>>time-nuts@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@febo.com > >>https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > >> > >> > >> > > > > > >_______________________________________________ > >time-nuts mailing list > >time-nuts@febo.com > >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > > > > > > _______________________________________________ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts >

In message <000601c72289$5f9a7350$03b2fea9@athlon>, "Ulrich Bangert" writes: >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. Not quite. 2E-11 is the spec, the counter is likely to do better. >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. Wrong. This is will not give a random sampling over the internal noisespectrum, and the number is likely to be different from the applicable jitter value for the specific counter. Instead feed in any stable frequency (an ocxo is best) different from the clock on the SR620 to both start and stop inputs and measure the time interval between them. The jitter on that measurement is the number you really want to know. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Subject: Re: [time-nuts] Using Allan Plots, was(LPRO-101 with Brooks Shera's GPS locking circuit) Date: Mon, 18 Dec 2006 09:58:47 +0000 Message-ID: <40859.1166435927@critter.freebsd.dk> > In message <000601c72289$5f9a7350$03b2fea9@athlon>, "Ulrich Bangert" writes: > > >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. > > Not quite. > > 2E-11 is the spec, the counter is likely to do better. Also, the random jitter is <= 20 ps(RMS) where as the deteministic jitter is guaranteed to be at (least) 1 ps from the quantization. Tau does different things to these numbers and it is the combinational effect which forms the actual ADEV. Toss in other circuit aspects especially for higher taus. > >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. > > Wrong. > > This is will not give a random sampling over the internal noisespectrum, > and the number is likely to be different from the applicable jitter > value for the specific counter. > > Instead feed in any stable frequency (an ocxo is best) different > from the clock on the SR620 to both start and stop inputs and measure > the time interval between them. > > The jitter on that measurement is the number you really want to > know. Asynchronous clocks make strange things to circuits. Cross-talk internal to the counter will show up as a variation in jitter. The intersting thing is that it will both decrease and increase the jitter depending on the phase relashionship. This is really a relative time/phase jitter variation. The amount of crosstalk will certainly give away how well the designers did in considering crosstalk. The quickest way to disclose crosstalk as an issue is to have two stable sources be near beating while logging the timings. One of these may be the time-base. However, since there might be crosstalk from the time- base you might want to not rely on that too. Single-channel measures will show channel-timebase crosstalk while dual-channel measures with two independent clocks will show channel-channel crosstalk. Nonlinearities in interpolators will also show up here, those are best disclosed by having one of the channels starting or stopping on the timebase of the counter and the slow phase steps of the free-running clock will scan the full interpolators range. Preferably the "free-running" clock is actually a locked and detuned oscillator. Cheers, Magnus

In message <20061218.112305.1155416385.cfmd@bredband.net>, Magnus Danielson wri tes: >The quickest way to disclose crosstalk as an issue is to >have two stable sources be near beating while logging the timings. One of these >may be the time-base. I have used such a "vernier" setup to measure stuff in the FreeBSD kernel and once you get the setup right, the reproducibility is very good. But until then your numbers will look very random. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.