[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