Hello Bill,

this is potentially possible with the small M9108 or the Jackson Labs
Technologies GPSTCXO.

Some caveats:

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?

2. The two mentioned units above may work with indoor GPS reception. This
   would then be able to get to your 100us goal no problem. Indoor GPS
   reception  depends on your setup, it works better when there are windows that allow
   signal  propagation and multipath to reach the indoors antenna. The antenna
   won't have  to sit next to the window. 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

3. The M9108 has an external 1PPS input you could use to feed a 1PPS signal
   from a 1588 or NTP system into it as an alternative to the GPS. That 1PPS
   should  be fairly accurate though (within +/-200ns to UTC) to get your
   <100us per 24  hours holdover accuracy

4. The above units will give you position, velocity, and time as NMEA
   strings as requested, with WAAS accuracy (typically better than 0.8 meters
   horizontal rms) when they are used with an outdoor antenna.

5. The above units are priced in the ballpark of your goal in quanity,  and
   have very highly stable oscillators (OCXO and TCXO) that should help with
   your stability requirements. They are rated at 25ppb and 75ppb over
   temperature  for example, and that would mean you could reach ~100us drift without
   any  external reference (units in holdover) over 24 hours with a +/-5 Degree
   C  temperature variation.

bye,
Said

In a message dated 2/19/2012 19:49:21 Pacific Standard Time,
albertson.chris@gmail.com writes:

On Sun,  Feb 19, 2012 at 3:56 PM, Bill Woodcock woody@pch.net wrote:

engineer, so  my apologies in advance for my ignorance in this area.

network.  Once I'm done with prototyping, I'm planning a production run of
several  hundred of the devices. They'll have a GPS receiver, probably a Trimble
Resolution SMT, and they have a bit of battery so they can initially go
outdoors for ~30 minutes to get a good fix, but then they get taken indoors
and plugged into the network, and probably never get a clear view of a GPS
or  GLONASS satellite again.

operational life of at least ten years) they'll  be dependent on their internal
clock and NTP, but we really need them to stay  synchronized to within 100
microseconds. 10 microseconds would be ideal, but  100 would be acceptable. And
in order to be useful, they need to stay  synchronized at that level of
precision essentially forever.

So you can  live with a 100 uSec drift over ten years or you say 10
uSec per year is  OK.

How many uSec are there in one year?  I get  3.1E+13.  So you can
tolerate 10 parts in 3E13 or 1 part in 3E12  drift per year. And you
have a $300 budget.    Somehow I think  either the spec of the budget
will have to move by orders of  magnitude.

Of you can have both with margin to spare if you can keep a  GPS
antenna in view of the sky continuously

Your plan to sync  the system to GPS be exposing it briefly to the GPS
signal will not  work
The reason is that, let's say you wanted to adjust your wrist watch  by
adjusting the fast/slow lever.  Assume you have a perfect clock  in
your house.  You adjust the time just fine.  But now if you  only wait
5 minutes to see if the watch is moving fast or slow you will not  get
good result.  but if you wait a week then maybe you can measure  a
difference in the two rates.    Same for NTP.  It  needs a bit of
time, maybe hours or days to measure the relative  rates.  The math is
not hard.  GPS, after it has "settled"  for about an hour or so can get
the time to about 50 nano seconds.  So  you capture the time,  Now you
wait an hour and capture it  again.  You could easy have 0.1 uSecond
per hour error in the  rate.  You say you's like 10 uSecond per year.
So you need either a  better GPS or wait longer than one hour.

So it's not like you  can sync time to GPS in an instant.  it takes
at least a few hours if  you care about microseconds.

Again this becomes easy and within $300 if  you can have an outdoor
antenna.

Chris Albertson
Redondo  Beach,  California

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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Feb 19, 2012, at 9:02 PM, SAIDJACK@aol.com wrote:

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.

With and without integrated oscillators:

http://trl.trimble.com/docushare/dsweb/Get/Document-577770/022542-014A_ICM-SMT_DS_US_08_11.pdf
http://trl.trimble.com/docushare/dsweb/Get/Document-454103/Resolution-SMT_DS.pdf

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.

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:

Yep, that's one of our requirements.

On Feb 19, 2012, at 9:20 PM, WB6BNQ wrote:

Yes, the general-purpose Internet.

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.  :-)

Exactly.

Right, we were only considering the special ones, that either have an integrated oscillator, or that are built specifically to feed a good oscillator.

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.  :-)

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:

Yeah, that was the distinction I was trying to figure out the terminology for.  Thanks.

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.

http://www.msc-ge.com/en/news/pressroom/manu/1241-www/3567-www.html
http://www.thinksrs.com/downloads/PDFs/Catalog/SC10c.pdf

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.

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.

Thank you.

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.

The vast majority will be office buildings.  A few datacenters.  Probably only a handful of homes.

Yes, only ones where we've controlled the timestamp on both the origination and the receipt.

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.

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:

No, we're doing board-level integration.

                            -Bill

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJPQeWuAAoJEG+kcEsoi3+H//cP/2vAzeA/8m/HYDk8TffSHWqL
tQwWXjgrpIgxMGIaKFps0kaN5lAdKXH2fQPJJt8vyV/dtGoe8wc5nkT+Rq7TCgW9
BtYHpA5SxyGZnX0ye1n1aUs7gduacKNam2CyHug5nC6SD21B5kXy8K5dTzKQp5a+
nM/6YEp8Ujrv339gMC1KGg9QA1XJJODjtvtK8iC8xMjjIbnxS584dpKaau2+lrCN
XCm1ySwP9k2YQQ+CzVie+6oYotqsvU0CVkVaIGw3xSHRN5YERl+Wf69ronYr14YH
nXivubnvWn0QU8vq8ybOK/LqMjQTS9ftdyVhKRXhkormQirjcCYK9iAxnVeQMYwX
I4UBOBRtKtTldmiExRFdLBWksrzXKkfe+VvYEEaYD10C4lSo5LCrHG454IZjeohb
jWeAqMweRULPZeYPg/BfSOmcK2iMtxir/Mz/s+OV/IryybcB9cZlYGqFGtqXvEwE
sdfQV/u4MBprtAWNczYM7XjcAB8l6VBqB8DBA1wQPdBo+0g470njbtnbHwnbuv58
dD+xqi7Nj2zgxmx3+Qe9i35TGaId75dQUripCdnXbEtPxNLYxIfEn4CTkJr4ULxM
8SrklXTGf7Dtr2CVrw5qcRqOcqQjLF2LKcpZNeNjOLVHe7hVqSUOFr535o1A4aq2
l6HG4ACfoe7zDCaO1U34
=/9zb
-----END PGP SIGNATURE-----

Le 20/02/2012 07:18, Bill Woodcock a écrit :

With the exception of the mobile units, the units' position can be
determined with google maps or local survey data prior to installation
so if you are not relying on the GPS receiver for time sync, why not
forget it, set the data prior to shipment  and invest the saved cost on
a better oscillator.

Hi Bill,

Not quite. The 2E-10 isn't a time or frequency accuracy spec; it's a frequency drift spec.
What this means is that the frequency may change by up to 2e-10 per day, day after day...

Let's say the oscillator is keeping perfect time now.
Then 24 hours from now it may be fast or slow in frequency by 2e-10.
If the oscillator is fast by 2e-10 it will be gaining time at the rate of 0.2 nanoseconds per second.
That doesn't sound like much but since there are 86400 seconds in a day, that's equivalent to gaining at a rate of 17 microseconds
a day. But that's just the first day.

The second day the oscillator may be fast by yet another 2e-10. By the end of the day it's now 4e-10 fast so it's now gaining at a
rate of 35 microseconds a day, in addition to all the time error from yesterday.

Think of frequency changing like an upward ramp. The time error accumulates like the area under that growing triangle.
Hence the quadratic growth of time error (1/2 * drift * t^2).
After a week the total time error is over 400 microseconds; you hit your 100 microsecond limit in about 3.5 days.

The SC-10 starts at $250, presumably for a low-grade version, not the one you want.
The DX-170 looks interesting. Let us know when you get a price quote.
Note also the temperature spec; can you maintain the temperature of your device to +/- 1 C?

/tvb

Yes, the relation frequency_drift-> time_error seems difficult to figure
out. I see this misunderstanding daily here at work and haven't yet found a
way to explain to my colleagues. I have already used: integral, area, count
accumulation but none worked.

On Mon, Feb 20, 2012 at 10:37 AM, Tom Van Baak tvb@leapsecond.com wrote:

On Mon, Feb 20, 2012 at 12:15 AM, mike cook michael.cook@sfr.fr wrote:

I've been thinking that all along.  The GPS receiver is not going to
be useful at all for timing.  Even for the first setup, even if GPS
was able to get you "perfect" time as soon as you connect top NTP that
perfect time will be wiped out with NTP's idea of the time.  So it's
pointless.

Now that I've read you are building hundreds of these then I'd say
there is ABSOLUTLY ZERO chance of ntp working at the uSec level.  Yes
it might work now and then but NOT all 100+ of your systems.    For
that to happen would would require a statistical miracle right up
there with buying a dozen winning lottery tickets in one day.  It
might happen.    But getting 100+ NTP installations to work that well
is near impossible.  You WILL need GPS and even then getting to 100%
is hard.  Some sites simply will not have a good view of the sky or if
in a high rise building running antenna lead down 25 floors through
conduit would cost to much.      The ONLY way to get 100% success
rate with hundreds of installations is to have multiple options.
"coockie cutter" or turn-key just can't work.  MOST places will not
have a good enough network connection for uSec level times.  Some data
centers will.  Small offices and homes will not.    Most places will
have a way to set up GPS.  Then in the remaining places you can use
cell phone based radio clocks.  They cost more then GPS and have 100
times worse performance but they might be the only option in most
cases.

You said the person installing this will be rather clueless.  The
"fix" for that is good customer tech support.  You can walk them
through the decision process about what kind of clock is best for
their site then help them set it up and test it.  Testing is key.
Have a few fall backs if the tests fail.

Bottom line is that open loop timing at the level of 10 uSec per year
costs well into 7 digit figures (Cesium clocks) so you need some
connection to the outside world.  So must choose a connection type.
The available options are

1. NTP.  Attractive because it is free but in most cases it will not
   meet your accuracy requirements, only in places with "good" networks
   like co-location facilities and some large data centers or if you are
   lucky and the customer already base GPS connected NTP servers on his
   local network (many places do have this.  It is common with larger
   companies)

2. GPS.  Works perfectly, not expensive but it does require an antenna
   that can see much of the sky.  You may need a long antenna lead cable
   and running long wires in a commercial building can be expensive.

3. CDMA reference clocks.  These can work at the uSecond level any
   place there is decent CDMA cell phone coverage.  The clock and its
   antenna can be located indoors.
   Here is an example of one:
   http://www.endruntechnologies.com/pdf/UnisonCDMA.pdf

4. There may be other ways to connect to the outside, phone modems,
   WWB broadcasts.  Loran is still running in some parts of the world.
   Your customer may already have a precision timing system of some kind
   and you can use that. (We use IRIG in our lab)  But you do this case
   by case.

If this were me.  I'd have GPS as the default option but then tel the
user he does not need it if a GPS connected NTP server is already
installed at his facility, then he could just use NTP.  Then use CDMA
as a fall back if those fail.

Chris Albertson
Redondo Beach, California