[time-nuts] Low-long-term-drift clock for board level integration?
woody at pch.net
Mon Feb 20 06:18:21 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On Feb 19, 2012, at 9:02 PM, SAIDJACK at aol.com wrote:
> this is potentially possible with the small M9108
> or the Jackson Labs Technologies GPSTCXO.
Thanks for the pointer to both of them… It looks like Jackson Labs have several interesting similar products, and I didn't know about them before. I'll give them a call.
> 1) The Trimble Resolution-T May work, but the above stated units have a 50
> channel WAAS/EGNOS/MSAS GPS receiver and are also GPS Disciplined
> Oscillators not just timing GPS receivers. The trimble unit may only be a 12 channel
> receiver like the Resolution-T and doesn't seem to support SBAS?
With and without integrated oscillators:
My understanding was that they support WAAS but not EGNOS, but I may be misremembering. Admittedly, the Trimble datasheets are a little short on hard numbers.
> It will depend on a case-by-case
> basis if these units can get GPS reception indoors, but we even had units
> receiving GPS signals inside a metal thermal chamber without an antenna
> connected(!)... so it may be possible
I just spent the day in a facility that was four stories underground, and managed to get some intermittent GSM coverage, so yeah, my faith in radio waves is a little higher than average, today. Anyway, yes, I presume that we'll be able to get some GPS, some of the time, in some locations. Just trying to optimize it as much as possible, by getting the best internal antenna I can find within budget, for instance.
On Feb 19, 2012, at 9:19 PM, Peter Monta wrote:
> Since you get an initial fix outdoors, you could tell the GPS unit its
> location, then put it in "time-only" mode, which needs only a single
> usable satellite. This is the usual mode for timing receivers.
Yep, that's one of our requirements.
On Feb 19, 2012, at 9:20 PM, WB6BNQ wrote:
> By network do you mean via the internet where you have no control over path variations?
Yes, the general-purpose Internet.
> What is driving the requirements of your delay measurements?
In large part, we need sub-millisecond accuracy in order to distinguish asymmetric components in paths between our measurement boxes. Which, as Mr. Murray points out, is a chicken-and-egg problem, if we turn to NTP to discipline the clock. It assumes symmetric paths, which is an invalid assumption, but impossible to correct without accurate time. Thus, we want to have accurate time. :-)
> It seems to me that to do a one-way delay measurement, the precise absolute time of transmission would be quite important. Otherwise how would you know the start of the timing pulse ? How would you otherwise account for variables in the path ?
> Your intended use of GPS will not help you with the time at all because once you lose the GPS signals (i.e., going back inside the building) the reported time is meaningless because the GPS internal oscillator is no where near stable enough to maintain that time properly. This is the case for all but a few special GPS units.
Right, we were only considering the special ones, that either have an integrated oscillator, or that are built specifically to feed a good oscillator.
> Trying to study SC verses AT cut crystals and other minutiae is a complete waste of your time. Either one in its proper circuit will do the same job.
Fair enough. Yeah, this is a huge field, and I'm trying to pick up as much of it as I can as quickly as I can, but there's a tremendous amount of detail that I will undoubtedly miss. Good to hear that some of it doesn't matter too much. :-)
> No matter which, for any decently designed ovenized oscillator, it takes 30 days to truly achieve stable thermal equalibrium and reach the best specifications, as to drift, for that particular unit. In the mean time transporting, jarring around and warmup retrace factors will guarantee the
> oscillator will not be where it was at its last long term runup.
That probably won't be a problem, as I think most of these boxes will be installed and then not touched again for very long times. The exception are the ones that we're going to have to put on taxicabs and busses, which will be a separate production run; they'll be really bad environments for oscillators, but much better for GPS/GLONASS/Galileo.
On Feb 19, 2012, at 9:26 PM, Hal Murray wrote:
> Note that you don't need accuracy, just stability. Software can correct for
> a frequency that is slightly off.
Yeah, that was the distinction I was trying to figure out the terminology for. Thanks.
> So if your clock is off by 1 part in 1E8, it will drift 1 second in 3 years.
> You need 100 microseconds, or 1E-4, so you need a clock good for 1E-12.
I think a box that can't get some external source of time in three years is one that we can pretty well write off as lost. Thank you (several of you, actually) for the clear explanation of the math.
So if I'm reading those specs right, they both offer 2E-10, or 100 microseconds per 500,000,000,000, or 121 microseconds per week. So, if those are affordable (and I haven't yet called to check), that's telling me that in order to be useful in the long term, these boxes need to be getting some reference time from somewhere at least once a week.
> You have 3 unknowns: transit time out, transit time back, and clock offset.
> NTP assumes that the network is symmetric. That's the 3rd equation that lets
> it compute the clock offset which it uses to correct the local clock. If you
> assume the local clock is accurate, you can compute the network delays.
> There is a chicken-egg problem. You can't do both at the same time.
Yep. Computing network delays is something we do a lot of, and we're very patient about it, and we have a lot of other sources of network topology information, so, hypothetically, we could build a better-informed NTP, that understands path components as well as directionality, and uses measurements between stratum-1 boxes (ones that do have a clear view of a GPS satellite with sufficient frequency to keep an OCXO from drifting too much) that have paths that partially overlap the paths between boxes that don't, to get to where we want to be. Simple matter of coding. :-) Probably too much coding to actually get it done, unless I find a reliable source of hungry grad students. But the direction we're going, in principle.
> In my experience, getting to 100 microseconds is going to be hard. I
> wouldn't call it impossible, but it sure won't be easy.
> How are you going to find good NTP servers for all your boxes?
Murphy says we won't. Bell curve, again. A very few will have good symmetric paths to Stratum-1 servers, most will have mediocre asymmetric paths, and some will have nothing usable at all.
> Are you targeting homes, offices, or machine rooms?
The vast majority will be office buildings. A few datacenters. Probably only a handful of homes.
> Are you trying to measure arrival times of packets you control,
Yes, only ones where we've controlled the timestamp on both the origination and the receipt.
> Can you post-process the data?
Yes, it's all post-processed. The measurement boxes are too small to do both measurement and analysis. They just run queues of measurement jobs and stuff the results back into a central database.
> I'm thinking of something like get a
> reasonably good crystal and let your system run off that crystal without
> trying to get time from the network. The idea is to keep NTP from doing
> something stupid. You can poke it occasionally from a central server to
> track the long term drift. Or setup nearby servers in noselect mode, turn on
> logging, and get the info out of the log files.
Yes, in principle, since we're collecting all the data anyway, central management of drift makes as much sense as distributed management, assuming we don't mind centralizing the processing overhead. And it builds its own mildly-interesting dataset over time as well.
On Feb 19, 2012, at 9:48 PM, WB6BNQ wrote:
> I think he indicated he was using the common hobby type units. I
> seriously don't think they measure up to your unit.
No, we're doing board-level integration.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
More information about the time-nuts