[time-nuts] People in Houston, Texas

rlighthouse1 at fastmail.fm rlighthouse1 at fastmail.fm
Wed Jan 16 04:09:01 UTC 2013


Looking to contact time-nuts people in Houston, Texas
Thanks,
rlighthouse1 at fastmail.fm



On Thu, Dec 27, 2012, at 06:00 AM, time-nuts-request at febo.com wrote:
> Send time-nuts mailing list submissions to
> 	time-nuts at 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-request at febo.com
> 
> You can reach the person managing the list at
> 	time-nuts-owner at 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 <brooke at pacific.net>
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at febo.com>
> Subject: [time-nuts] GPS Clock with Four Letter Words
> Message-ID: <50DB47D8.4040906 at 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.griffiths at xtra.co.nz>
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at febo.com>
> Subject: Re: [time-nuts] Questions about TAC frontend, and some
> 	measurements
> Message-ID: <50DB48AE.4010400 at 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 <magnus at rubidium.dyndns.org>
> To: time-nuts at febo.com
> Subject: Re: [time-nuts] Z3805A cooling requirements?
> Message-ID: <50DBBC02.6050508 at 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 <gxti at partiallystapled.com>
> To: time-nuts at febo.com
> Subject: Re: [time-nuts] An embedded NTP server
> Message-ID: <50DBED95.5090500 at 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 <hmurray at megapathdsl.net>
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at febo.com>
> Subject: Re: [time-nuts] An embedded NTP server
> Message-ID:
> 	<20121227093636.D6A78800037 at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> albertson.chris at 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 at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> 
> End of time-nuts Digest, Vol 101, Issue 173
> *******************************************



More information about the time-nuts mailing list