Looking to contact time-nuts people in Houston, Texas Thanks, rlighthou...@fastmail.fm
On Thu, Dec 27, 2012, at 06:00 AM, time-nuts-requ...@febo.com wrote: > Send time-nuts mailing list submissions to > time-nuts@febo.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > or, via email, send a message with subject or body 'help' to > time-nuts-requ...@febo.com > > You can reach the person managing the list at > time-nuts-ow...@febo.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of time-nuts digest..." > > > Today's Topics: > > 1. GPS Clock with Four Letter Words (Brooke Clarke) > 2. Re: Questions about TAC frontend, and some measurements > (Bruce Griffiths) > 3. Re: Z3805A cooling requirements? (Magnus Danielson) > 4. Re: An embedded NTP server (Michael Tharp) > 5. Re: An embedded NTP server (Hal Murray) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Dec 2012 10:54:16 -0800 > From: Brooke Clarke <bro...@pacific.net> > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Subject: [time-nuts] GPS Clock with Four Letter Words > Message-ID: <50db47d8.4040...@pacific.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi: > > Here's one of my GPS controlled clocks that also displays random four > letter words. > http://www.prc68.com/I/timefreq.shtml#FLW > > When people visit it's almost hypnotic. > > -- > Have Fun, > > Brooke Clarke > http://www.PRC68.com > http://www.end2partygovernment.com/2012Issues.html > > > > > ------------------------------ > > Message: 2 > Date: Thu, 27 Dec 2012 07:57:50 +1300 > From: Bruce Griffiths <bruce.griffi...@xtra.co.nz> > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Subject: Re: [time-nuts] Questions about TAC frontend, and some > measurements > Message-ID: <50db48ae.4010...@xtra.co.nz> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Fabio Eboli wrote: > > Hello, hope you all had a happy Christmas. > > > > Back to the topic. > > Bob Camp asked: > >> Hi > >> One very simple question - how good would it do if you just did it > >> all with logic gates? Tri-state buffers and things like that?. > >> Now that you are up to a 100 to 200 ns long pulse, a lot of the > >> fiddly stuff about "can't get a 2 ns pulse through it" goes away. > >> I'm not suggesting you tear up what you have. It's just something > >> else to try and compare > >> Bob > > > > Bob, are you hinting to something like the last mail from Bruce? > > I.e. to use a tristate buffer to charge the capacitor? > > If not can you explicit what are you thinking? :) > > > > Thanks also to Alan Melia and Tom Miller for the details about > > bjt saturation . > > > > Bruce, about the tempco of the current generators, > > There is the led in series with a BE junction. > > The blue leds should have a tempco in mV per ?C similar > > to th BE junction, dont know the red ones. > Similar. > > Would it be better to use something like a 4.7 or 5.1V > > zener? If I remember correctly these zener voltage > > shuld cancel most of the BE tempco. > > And what about a TL431 instead of the led+bjt? > > > The BJT is essential to ensure that the current source has a high output > impedance. > Opamps dont help as most have insufficient gain at high frequencies. > The input capacitance of an opamp input connected directly to the > current source emitter isnt conducive to a high output impedance either. > Its better to drive the emitter of the second transistor with an npn > emitter follower thats part of a servo loop using a suitably decoupled > opamp (series resistor from the current source emitter to the inverting > input of the opamp) to set the emitter current of the current source > transistor. > > The Avago diodes are pretty costly :) > > Is that circuit working like the internals of ECL logic > > families? > > > Yes apart from the lack of emitter follower outputs. > Its called current mode logic. > >> The simplest (lowest part count and least number of power supplies) > >> consists of a tristate buffer driving an RC circuit. > >> The PPS signal is connected directly to the buffer input whilst the > >> output of the PPS synchroniser (at least 2 stages to minimise the > >> probability of metastabilty at the synchroniser output) drives the > >> buffer tristate control input. > > > > A 2 stage syncronizer is composed of 3 FF? > No 2 FF, the first FF is just a convenient means of stretching narrow > pulses and ensuring that the synchroniser input pulse width has the > required duration. > > I.e. clock in parallel to 3 FF, PPS to the > > first D, Q from the first to D of the second, > > same from the second to the thid, and Q from > > the third to out. Let's assume that the inputs > > from PPS and 10MHz are fast enough, what can still > > generate metastability? Setup time violation? > > > >> The RC network starts charging when the PPS signal goes high and > >> stops when the synchroniser output goes high. > >> The capacitor charging is nonlinear but this is easily corrected in > >> software. > >> The capacitor is connected between the input of a capacitive charge > >> redistribution ADC and ground. > >> Software correction for the effect of charging the charge ADC input > >> capacitance is also required. > > > > I see you are stressing the fact of using a capacitive charge > > redistribution adc. I dont know much about the internals > > of the ADC devices, can you suggest a partnumber for an example? > > > Almost any modern SAR ADC such as the LTC1282 and later. > >> > >> Suitable fast single gate tristate drives are readily available. > >> With low tempco resistors and capacitors the TAC gain tempco can be > >> 200pmm/C or less. > >> The only disadvantages are the increased software complexity and the > >> need for an extra bit of ADC resolution to maintain TAC resolution. > > > > The 3-state buffer + R-C seem an elegant solution for a microcontroller > > based thing, I'v given an eye to logic buffers, and seem that all > > suggest that the Hi-Z state leackage current is not very well > > specified, but something around 1uA, that means that cap's voltage after > > the pulse can rapidly (and unpredictabily?)change due to leackage. > > I imagine also that the leackage of the buffer will vary with > > temperature. > > > Kasper Pedersen has used this technique. http://n1.taur.dk/gpsdo2a.pdf > However he only used a single stage synchroniser which is far from ideal. > > The ADC of the micro is pretty fast, I shuld check the datasheet > > but I remember around 1uS per conversion, what would happen connecting > > directly the micro ADC to the charged cap? And sync the ADC to sample > > immediately (few uS) after the pulse. Could the loading from the > > s/h capacitance be corrected in fw? > > > The best way is to have the ADC in sample mode whilst the capacitor is > being charged. > Wait sufficient time at the end of the charging process for the ADC > sampler to settle and then trigger a conversion. > If possible, its best for this conversion trigger to be generated by the > synchroniser (use a shift register 1st 2 stages for the synchroniser > prper and the following stages used to generate the required delay. > The effect of the sampling capacitance can be corrected in software to a > first approximation it merely changes the TAC gain. > >> > >> Bruce > > > > By the way, I updated my miserable schematic, I tried a simple > > mod to avoid the saturation of the switches. Only because I had > > it already built: http://pastebin.com/9VHkhmSv > > > > Now I'm chasing the origin of the drift variation, logging > > the temperatures and voltages. More on this as soon as I > > have some data. > > > > Thank you all, > > Fabio. > > > Bruce > > > > ------------------------------ > > Message: 3 > Date: Thu, 27 Dec 2012 04:09:54 +0100 > From: Magnus Danielson <mag...@rubidium.dyndns.org> > To: time-nuts@febo.com > Subject: Re: [time-nuts] Z3805A cooling requirements? > Message-ID: <50dbbc02.6050...@rubidium.dyndns.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Mark, > > On 12/26/2012 06:24 PM, Mark Spencer wrote: > > Tom, Magnus, Ulrich: > > > > Thanks for the comments and suggestions. They are appreciated and I > > now have an even better understanding of why ADEV measurements are > > not a good tool for characterizing the performance of oscillators that > > are subject to transient events or glitches. > > Good. You do get a gold star for your ADEV over time analysis, also > known as dynamic ADEV. It helps to see where in time a certain ADEV > wrinkle occurred so the time-plot makes sense. Trouble is, you already > have to have a clue to get to that point. > > > Just to clarify a few points and ask a few questions: > > > > My concern about not putting much emphasis on Adev data for Tau's of > > less than 80 seconds in the plots I?ve provided is driven by a > > belief that at shorter Tau's these ADEV plots are largely showing the > > noise of the counter (an HP5370B) vs the noise of the device being > > measured. Perhaps the 80 second cut off point is overly conservative > > but at some point I believe the counter noise will swamp the noise > > from the devices being measured. > > I agree with you, but rather than not showing it, show it and point out > that this is counter-noise. Then that little slope remaining has a > natural explanation and you also get a good line to follow down and > understand where the DUT noise takes over. > > It would be cool if we could artificially "remove" that limitation and > see the added noise only. > > AVAR_lim(tau) = (ADEV_lim(tau0)/tau)^2 > ADEV_corr(tau) = sqrt(AVAR(tau)-AVAR_lim(tau)) > > It should be fairly simple to fit ADEV_limit to the curve, and it will > represent the white phase noise limit. Seeing that number should also > help to see where trigger noise etc. could be improved. > > In a similar sense could other noise-forms be removed, so that you would > have a residual ADEV plot. This is after all what ADEV was developed > for, to establish the levels of noises and have them in separated form. > > > My goal was not to try and use ADEV measurements to characterize > > the performance of the GPSDO in question while it was subject to > > fluctuations in air flow (or subject to other transient events..) > > I did include a frequency plot in my post that provides some > > insight as to what happened when air flow was added. > > > > The goal was to see if operating the GPSDO in question with air > > flow changed the ADEV readings vs operating the GPSDO without air > > flow. I agree ADEV may not be the best tool for this but it is easy > > to collect and I have prior data to compare the results to. ADEV > > also seems to be a commonly used figure of merit for characterizing > > devices such as GPSDO?s.(I realize there are also other commonly > > used figures of merit.) > > It all comes down to how "quiet" your ambient air is to your GPSDO/OCXO. > Forced air-flow improves the thermal connectivity between the ambient > air and the GPSDO/OCXO. For many professional buildings and computer > halls, the AC/heating system is not as quiet as you would like. I've > killed several good measurement runs of free-running oscillators just by > walking up to the lab-bench and with it a wall of colder air sweeps over > it... > > That's why I try to measure things in a cardboard box just to get > somewhat less airflows on the oscillators, and it works very well. > > Forced air as such poses some issues, but ambient air is in my > experience the real killer. > > > The lowest ADEV reading I have ever observed for the GPSDO in > > question came from analyzing a data set collected 45 thru 65 minutes > > after air flow was applied to that GPSDO in that particular > > circumstance. I found that result surprising although I agree the > > absolute difference in the ADEV figures is very small. > > Which I could very well believe. > > > It's my understanding (based largely on comments I've read on this > > list over the years) that if you have roughly nx10 data points you > > can begin to draw inferences from ADEV plots for Taus<n. Is this > > a reasonable practice and or are there caveats one needs to be > > aware of ? > > Having spent many times watching the data coming into timelab, seeing > the high end flap like a whip until it settles down, I'd say that x10 is > still very unstable, but by all means look at it. The reason you want to > see real confidence intervals on your measure is to know where about the > real value could be compared to the value you currently see. > How tight you want your confidence interval to be depends on what form > of conclusion you want to take. I'd say that even more conservative > values like 100 time samples could be viewed as incorrect for some > applications. This is where you need to decide what you need. Sit down > and see the curve vary for a tau until it settles, that way you learn > where your confidence in values lie. > > > > > I agree that one test of this nature is in sufficient to draw any > > firm conclusions from and much more data is needed. > > It's more about building experience of what matters. > > Temperature changes rather than temperature as such affects you, as long > as the oven is operating in linear state. > > For one oven I once saw an interesting case, and I realized that the > oven took a "nap" to cool down and then started heating up again. In > effect, during the nap, the crystal was cooling down in an unregulated > environment, and then it was being heated up by a jolt of energy. > > Another oven had a self-oscillation in the oven controller, which was > visible from power-on. It also had my current digits flopping around and > current measurement gave the controller away finally. That design was > built on a ceramic brick rather than FR4 board, so it lacked the thermal > mass to remain stable. When the vendor understood the issue, they kept > that design running arguing that the other customers didn't complain. Ah > well. > > Cheers, > Magnus > > > > ------------------------------ > > Message: 4 > Date: Thu, 27 Dec 2012 01:41:25 -0500 > From: Michael Tharp <g...@partiallystapled.com> > To: time-nuts@febo.com > Subject: Re: [time-nuts] An embedded NTP server > Message-ID: <50dbed95.5090...@partiallystapled.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 12/26/2012 12:01 PM, Chris Albertson wrote: > > The VXCO quality hardly matters for an NTP server. As long as it > > does not gain out loose more then 1 uSecond per second. In other > > words one part per million is fine for NTP. The goal is not to > > produce a 10MHz GDPDO. Clients using this server over the Ethernet > > are happy to keep time ti 1 millisecond. > > > > Most (almost all) NTP servers use a TTL can oscillator. > > Indeed, it's just a chip VCXO. Not much of an additional cost, and it > can be disciplined in hardware. In a PC, the main oscillator is not > tunable so the kernel has to emulate a tunable clock by tweaking the > numbers on the way out. > > Now that I have the disciplining algorithm implemented I immediately > discovered a problem -- and it's not my hardware. The receiver I assumed > was a UT+ is actually a R1121N1145, which doesn't support position hold. > But even worse, the PPS seems to jump forward by precisely 1ms every > 16-20s and sticks that way. This probably explains the mediocre jitter > of 0.3-0.6ms in the NTP results I posted on the 25th. With enough > smoothing I can probably make it work, but in the meantime I will switch > to using the Trimble receiver which I know works well. My goal with this > project was always to support as many receivers as possible but the > 100mil pitch header on the Oncore is much more convenient so that's > where I started. > > The good news is that the disciplining algorithm I lifted from my > previous GPSDO project works quite well, and I have the gritty details > of measuring the PPS worked out. If I can get the Trimble working > tomorrow I might have much better results soon, otherwise I'm traveling > for a few days so it'll have to wait until the new year. > > -- m. tharp > > > > ------------------------------ > > Message: 5 > Date: Thu, 27 Dec 2012 01:36:36 -0800 > From: Hal Murray <hmur...@megapathdsl.net> > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Subject: Re: [time-nuts] An embedded NTP server > Message-ID: > <20121227093636.d6a78800...@ip-64-139-1-69.sjc.megapath.net> > Content-Type: text/plain; charset=us-ascii > > > albertson.ch...@gmail.com said: > > The VXCO quality hardly matters for an NTP server. As long as it does not > > gain out loose more then 1 uSecond per second. In other words one part per > > million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients > > using this server over the Ethernet are happy to keep time ti 1 millisecond. > > This is time nuts. It's always fair game to discuss how good things are > and/or how to make them better. :) > > The reference NTP package goes to a lot of work to figure out how far off > the > clock is and tell the kernel so it can keep (much) better time. In many > systems, that's a pretty good thermometer. > > Another thing the reference package tries to do is stretch out the > polling > interval to minimize load on the network and servers. It's trying to > find > the bottom of the ADEV curve. The default range is 64-1024 seconds. It > keeps track of it on disk to PPB. > > That doesn't work very well if the temperature/frequency isn't stable. > The > temperature swing with load change has probably gotten worse with newer > machines. > > It would be interesting to see what ntpd would do on a system with a very > good clock and/or what you could do to the code/heuristics to take > advantage > of a stable clock. > > > > Most (almost all) NTP servers use a TTL can oscillator. > > Are you sure? Or what's the current practice? > > A while ago (several/many years?) it was common for Intel boxes to have a > clock generator chip. They ran off the standard 14.xxx MHz crystal and > generated clocks for the CPU, PCI, USB, ... It usually included the > spread > spectrum hack. > > The ARM SOC chips I've worked with had similar stuff on chip. You > connect up > a crystal. It has an amplifier to make an oscillator and PLLs to make > whatever clocks are needed. > > > > -- > These are my opinions. I hate spam. > > > > > > > ------------------------------ > > _______________________________________________ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > End of time-nuts Digest, Vol 101, Issue 173 > ******************************************* _______________________________________________ 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.