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

On Feb 19, 2012, at 5:07 PM, Bill Hawkins wrote:

Yeah, my assumption was that something like a DOCXO or a VCTCXO would be about the best I'd get within budget.  But I'm very new to this, and just beginning to dip into all the articles about SC cut versus AT cut, etc.

We need the GPS fix for location, and get the time for free, so figured we'd use it.

That would be nice, of course, and we'll get the best GPS antenna we can afford and fit, but we can't have an externally-cabled antenna, or require that people put these on windowsills, or anything like that…  There will be too many of them, and the level of clue of the people plugging them in out in the field is likely to be too low.

Yes…  They'll all be indoors, which helps, and temperature-regulated crystals seem to be relatively widely available, if in a dizzying number of styles.  Regulated power is something that we need to just have someone spec out, or use a reference design, if one exists.  Anyone have pointers?

So that's something I've been having a hard time understanding…  If that's the amount of inaccuracy per oscillation, then at the time-scales I'm dealing with, it would quickly accumulate and become unuseful…  that is, 10 microseconds of drift per second is almost a second of drift in a day, whereas I need, ideally, something I can discipline to within 100 microseconds total, using just a single GPS fix, plus NTP over the long haul.

Now, I don't know whether what I want is possible or not, but that's why I'm asking these questions.

Or am I misunderstanding the parts-per-foo notation?

There will only be one device per location, and we can't have any external stuff plugged into them.  Else yes, I'd just use GPS and be done with it.

                            -Bill

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

iQIcBAEBCAAGBQJPQaZgAAoJEG+kcEsoi3+HofkP/iEYz5UKHvHuifCUe3YZwoz/
SSzYbPDnODHFBvf3QBipUVt54lFRxqapcXrSJrtM7qeu52CTKP9kl8OUmZHABogQ
iSUafnPcjOoxByStt9EucEQOp68QnLsXciELSsOR6K9Pl69i6V/A84Eg+eSXTbm5
LE/kPVDOVHI/eL6m7E70vCk9qreQY6ujCiaeUIAlgM14DWVczU1ke1IcXSbCajdl
seX3byHZOQDgL1MD+IYdi1VU/3AC8NbSwce6j0H3bYpuA1knWlfNQlrKPVWSbIfF
21QEgYgJ8ZmDG6BWounFAhjN2MqzPm4mJ4MyVBJwGi1atzLzgPWWZJFh9GoValCC
OezajJdUlAQdUEYf1bSPpbBhzK8qzVHRmBIFKDWJew62ab5VyzJt+m01y5wZJkR6
w2vz8awh5ZCDI77YVm7dsRqxRDj54QsiFIyvJV9qLGW5ubj3SQy//Bx9X4W3nIYu
WbxQD1g8o2yB8Ci9OB6Ox2Wiy3UcZegNxX+8nrupp89qDAWCk3dKxLxR/acXAQ1L
DFQbs+lxgNVTXygLnFm2GY9VgvCUKw/GW9oZqdhiDlhFQilR7vMsYrAdAyOZfv7e
6hU3g2FtoGgax9KPd7Zmyg0nhamDphnjumNnnxqUu4gXMZzGLBoeZAWy7LmSkUn0
qGQ4Qv1ff2PwTqAAlqn1
=l7OV
-----END PGP SIGNATURE-----

On 19 Feb, 2012, at 15:56 , Bill Woodcock wrote:

10, or even 100, microseconds is tough with NTP.  I don't think it is impossible, but it
requires a good, reliable network connection and a bunch of work to identify and reduce
the systematic errors.  And if "NTP" == "ntpd" I'm not sure putting a better oscillator
on the board is likely to help all by itself since ntpd's "magic" internal constants are
organized to work with the class of oscillators you typically find in computers, and this
would need to be redone to do anything useful with something better.  I think making use
of NTP at the 10-100 microsecond level might require doing your own software, the generic
reference implementation probably won't cut it.

Before doing that you might consider some alternatives:

• If you are deploying this stuff in the US, and if cell phones (particularly Verizon or
  Sprint phones) work where you are installing the stuff, you might look at this for a time
  source:

  http://www.endruntechnologies.com/time-frequency-reference-cdma.htm

  This is good if it works everywhere you need it, and assuming CDMA networks continue to
  operate for another 10 years.

• Failing that, look at IEEE 1588.  The trouble with this is that it severely constrains
  the kind of network the equipment is attached to, and the gear used to build that network,
  but if this is in your control you can buy stuff for this without having to build it.

If none of the above works, and you just can't get GPS antennas installed, then you may be
stuck with NTP, but getting a reliable 10-100 microseconds out of that is a lot closer to the
"research" part of R&D then the "development" part.  I don't think running the generic
reference implementation, ntpd, will deliver this.

Dennis Ferguson

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

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

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

On Feb 19, 2012, at 7:28 PM, Dennis Ferguson wrote:

We will have a very large mesh of devices, but the connections between them may be poor.  It's my assumption that some of them will be able to get enough GPS signal (or GPS via a GSM BTS, as we also have a Sierra Wireless GSM chipset onboard) and would thus be able to act as Stratum 1 servers for the others.  Not that there's any big shortage of Stratum 1 servers out there.  It's been a while since I've tried a large mesh of NTP servers, so I don't have much sense of what a reasonable degree of accuracy to expect is.

And...

…you're probably right about that, so my experience probably isn't applicable at all.  We've supported a lot of open-source development over the years, so I guess I need to figure out who's most actively doing NTPv4 development now, and see if they want to take a whack at it.

Nice, I hadn't seen that before.  Only a small portion of our boxes will wind up in the U.S., though, so we're using a Sierra Wireless SL6087 receiver in essentially the same role.

Yeah, I did look at it a bit, more to see if there was anything useful to be learned from it than in an attempt to actually use it, since we're connecting through the general-purpose Internet.

On Feb 19, 2012, at 7:48 PM, Chris Albertson wrote:

…or we use something to discipline the clock more often, which is why we've got GPS, GSM, and NTP…  I just have to assume that some or all of those either won't work, or won't work well enough to be useful, in many cases.  With hundreds or thousands of units in the field, it's much more about trying to make a reasonable general solution than trying to get one thing exactly right…  There'll be some sort of bell-curve distribution for the reliability of each of those methods of improving the time, and I'm just trying to figure out the best way to maximize the area under all of those curves within a budget that still allows us to build a useful number of measurement devices.

Yeah, the Trimble guys ran some numbers and figure that we can get single fixes with ~100 microsecond accuracy in twenty minutes, with the chipset they're selling us.  The tradeoff in battery size to get that down one more order of magnitude isn't worthwhile…  It would push the battery up from $35 to $200, and more battery doesn't have much collateral benefit in our application.

The number of sites where anyone would be able to install and maintain an outdoor antenna would be way out under one of the skinny ends of those bell curves, so essentially not worth spending any time thinking about.  If wishes were horses, etc.

Thank you very much for the advice.

                            -Bill

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

iQIcBAEBCAAGBQJPQdVKAAoJEG+kcEsoi3+HTNUQAIx0EzXPiYPtKeogyFdw+L3s
kg1TvnM847NwavbwoY82Z1XMQ1MLZHVitR+xIbDmR45jUa73ZreD5PD9PfGZ7iej
/LPzrc+6MIi6nHJjeMF5u73IJ0oHx5Guri3Z1iANBaOFSQjioEfQOwOSs/H0ysN2
HpETfLLzxSlLg55Fg7HUq6zFZ12i8HeBrngbWbMPRTUyjU+DosV4MbOoYS3o8QVO
hWyvkMq4tIgbunKJgYm4+zDww52J2e4NlOWqqWW6cYRJ07A+gpfJa3lJgyutRV6o
4CTYR0ZecMN4kSgzpvqWyleweBftn0dCQ+Zb4F3GIJG33fehq+POmQQAQUbbdmCZ
bbQAXpgHWN+BufRvwm+UiP9fK1GWO6f1CCFRbwbIFCE3jKlKzKjQWIW/vn+DR8eK
GsPvMqCKP3YiJNdCqd8dVEMgJN+t3qksEHgn0k3hUNsKHfVGjs2BzPz49TPBm/Ik
eXp3f9ZiXqZ0NFb4mCx5Zfl/8ZI3jN4hPxa8ktMr4NDK+uiDgeuNj+vKjWKW6sxC
MKbHG6VGyfWoULTJ+DFOw+uTkA7Xb8GseBC/f05tNw5cLUg2j9I3XlsZPpAUbiET
zQGceSSVIyyVht9F+y4qGJG+N8IqTa5LVsyCtHKgVy+RECV9QaPUG5hF37VbvhGT
etC2gTjqXt6hnegVE+jG
=QCcW
-----END PGP SIGNATURE-----

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

I think you have it right.

There are two things (1) the RATE of a clock and (2) the PHASE of a clock.

The phase is the time between a "true UTC per second tick" and the
tick on your clock.  When you see that your wrist watch is 5 seconds
different from another, that is five seconds of phase.  Phase is
measure in units of duration, like 1 uSec or 5 seconds

Rate is is always "per unit time".  A perfect clock runs at one
second per second.

Sorry if this is to obvious.  That is my point.  It's not rocket
science.    (See Below, I think NTP might work for you if you are
willing to push the state of the art forward with some purpose built
hardware.

Now about GPS and NTP.  It's huge advantage is that if you average
over enough time it runs at one second per second rate, exactly

The trouble is the noise in the phase.  NTP over the Internet has
"tens of milliseconds" on uncertainty in the phase.  It is useless for
what you want.  You need uS not mS.

GPS also has some uncertainty in the "phase" on the order of about
between 1uS and 10nS depending at the type of GPS and how much care
was used in setting it up.  You need a good site survey and time for
an OXCO to reach equilibrium to get good time data.  Turn on your
basic consumer level Garmin and you get time to about 1/2 second.  Yes
it really can be that poor.

You are correct if the rate is wrong by "X" the phase will drift at X
per unit time and soon can be very far off.  What you do with NTP or
GPS is work the other way:  NTP tells you the time (plus or minus say
1 mS)  So you wait 1,000 seconds and get the time again.  Now you now
your RATE to within 2mS per 1,000 seconds or to within 2uS per second.
In theory you could wait 1,000,000 seconds and get better rate
determination but what kills you is that we must assume the local
clock's rate is constant for this to work.  It is maybe "constant
enough" over 1,000 seconds but certainly not over 10K seconds unless
you spend that $300 budget on a good local oscillator.  If you do
then NTP can use a very long time constant in it's loop.    Typical
NTP software can't use such a long time constant because typical local
clocks are cheap ($2 or less) 20PPM crystals.  If you can afford
20PPB (1000 times better) you just might, maybe be able to get uSecond
level time from NTP over a network.  But how long would that take?
Can your users wait 100,000 seconds?  You will be pushing the current
state of the art.  Most everyone finds it is easier to simply connect
to GPS.

GPS is the same as NTP but has less uncertainty so you can get good
rate determination with a MUCH shorter integration time.

If you are willing to build a custom motherboard around an OCXO and
modify some system software and right a custom NTP driver you just
might get to 100X better than is typical.

It sure would be a fun experiment to have NTP try and discipline a
Rubidium oscillator

New TOPIC:    Mmaybe there is a better way?  Sounds like your system
uses absolute time to measure time intervals.  Better maybe to use
relative time.    Maybe for example your units all "ping" each other
at some rate.  then you measure time relative to the ping rate.  All
your units know the ping rate and don't need to know the wall clock
time as they have their own time unit.  later you can figure out the
conversion for ping rate to seconds.  It could be very accurate.
If say you want to measure the time to do one HTTP request then you
send 1000 HTTP requests and you see that you got 13,500 pings per 1000
HTTPs, the ratio is 13.5:1.  Just make up your own unit of time

Chris Albertson
Redondo Beach, California

A high-sensitivity GPS receiver might still give useful results here,
especially if it has a high-quality reference oscillator like an OCXO.
Even 20 or 30 dB of path loss from roof to your device might be
manageable.  Of course, your deployment environment could well be
worse.

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.  If
the number of satellites drops to zero, though, an OCXO will not hold
over for long inside a 10 microsecond window.

Cheers,
Peter

Hello Bill Woodcock,

Many, many questions come to mind.  Is this a fixed network that never changes its character ?  Or by network do you mean via the internet where you have no control over path variations ?  I guess the latter based upon your comments thus far.

What is driving the requirements of your delay measurements ?  Are they realistic ?

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 ?

Doing a few fixes for 30 minutes will, under best conditions, get you somewhere on a circumference around your location with a radius of 15 meters (50 feet).  For GPS to get a useful coordinate result with meaningful data will take longer than 30 minutes or so.  Typically, you would want to do a 48 hour “survey” of your position to try to achieve a 3 to 5 meter resolution.  However, that only gives you an idea of where the GPS antenna was
located and specifically not where the start of the path is located.  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.

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

Not knowing the requirements for your measurements makes it tough to give any meaningful answers.  Clearly, it seems that your needs are to correlate data from many nodes at indeterminate positions.  If this is truly the case, then “time” would be the critical factor that needs to be focused on, more so then location in my opinion.  If so, then your budget may need to increase more than your planning for.

Bill....WB6BNQ

Bill Woodcock wrote:

Bill Woodcock wrote:

On 19 Feb, 2012, at 21:08 , Bill Woodcock wrote:

In the US I suspect all GSM base stations have GPS available (E911 support
generally requires it), but I think you may find that in many (most?) other
countries the GSM BTS gear has no idea what time it is.  GSM doesn't require
the time synchronization (it requires frequency, but they can often recover
that from the tail circuit connecting the BTS to the network), so in many
places they do without GPS either to save money or because the carriers are
subject to regulatory requirements to avoid allowing the country's
telecommunications facilities to become dependent on GPS (I assume because
their regulators don't fully trust the owners of GPS)…

GPS can sometimes work under non-optimum circumstances, but it sounds like
you have run out of fallback options apart from trying to advance the state
of the NTP art.

Dennis Ferguson

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

On Feb 19, 2012, at 10:20 PM, Dennis Ferguson wrote:

Pretty wide range there…  I've certainly seen some pretty crazy time-and-dates show up on my phone upon landing in some countries.  But it's been a while since I've gotten a weird one in Europe or the more developed parts of Asia.  Africa and South and Central Asia are pretty much all over the map, though.

                            -Bill

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

iQIcBAEBCAAGBQJPQejmAAoJEG+kcEsoi3+H1E4P/jYB0QRd5zUMBVUQdpc48xSX
kwzZv/TmYUhTGkyBKifbeDrcTEmNmov9GscB+25oObEE6nfoSansDUJV0dxK6ux/
BPsMfYWZraTv3AJFJwGQ+R8ab9JTts/FgNoBUWCOaQwPkAN6lWE0LHU+8TW5o59R
LFIeZ7tsD6BnIS+kiSLsLxrAQ6RzvxtzOwZXxCejGl04VwG6NcrfE/kJjzTn6WLk
0eanG6fvqZUdNQaD37uCZKf0SDneV9EKBIkoUMK+n3X1MS4N5gNQ3uFM/rli9JGz
R7Cd2x1AgJzddNR+aOlPTTv//eWKR/nBiR2AHZRx8PjbzGrziQHVRakiJdeyqWa2
X09AKlSnaeG2+ZAFLUAxJbL2YJFSqMo/9RgTQKc65VQ7anA13OxxpioJ5W5vW+h5
E5uCMdQE7SKuChdkb+8dWJPvq4wYNwBT6MyDcvMqSQrEnDEcc/0NDsPPhHjcOKW5
ZR+1ASncyQYymI17aOHVYpLnW89bu2gUADzhfTviWLHzEgiDL9qSCVtIR5IiFVOj
8sAM+uTnd6He/96EWd6vIguY6IOGAVQX1RGBhXhOsm26Hhx11p3qAEhzuGHJLZZ2
N3bMQD8hJcFhKh0b6TkeC7a1QI2cr6cH0dKd74YnUFuJDK/NGixUUzZ1azP+iHkR
kvdseSQTGWaRrpWWY+5f
=H8L/
-----END PGP SIGNATURE-----

On 2/20/12 8:34 AM, Achim Vollhardt wrote:

I think the OP needs something over a large geographical area, and I
don't know that PTP/1588 would work through a routed "internet" kind of
connection.

Hi

Simple answer:

A rack mount cesium standard is as good as you can get. Figure on 15 ns per day of drift. That gets you to 15 us in 1000 days. You may or may not get one that drifts that little, a lot depends on  little details. For > 3 years, consider an ensemble of cesiums. At $50K each cost can go up pretty fast.

There is nothing out there that will do better stand alone for less money. Either you get a sky view or you change the budget....

Bob

On Feb 20, 2012, at 1:32 AM, Bill Woodcock woody@pch.net wrote:

On 2/20/12 10:31 AM, Bob Camp wrote:

But he does have the ability to have an external network connection..
So the real question is whether one could come up with a better-than-NTP
scheme to get the 100 (or 10) microseconds.

I suspect that with sufficiently controlled network paths (which might
be doable in a widescale deployment) and a tweaking of the NTP stuff,
you might be able to get it to work.

100 microseconds out of a day is 1E-10, which is actually a fairly
liberal drift spec for an OCXO or even a TCXO. (which are things like
ppb/day)

Maybe there's a particular time of day (or day of week) when network
uncertainties are minimal, or can be bounded.  So what you really need
is a onboard oscillator that is good at "carry over" between periodic
calibration checks.

One question about the 100 microsecond spec.. is that a worst case at
any instant, or is it an average spec over a day (so a consistent
diurnal variation would cancel out)

I've looked at the posts on this topic, and from what I've seen so far I
think is going to be a tough if not impossible call.

30 minutes to get GPS is OK, but what about the oscillator? It will need a
lot longer than that to stabilise. You also then have the vagaries of the
network. NTP won't hack the spec he is quoting and PTP won't hack the
network. And, the budget is way too low.

Food for a lot of thought methinks....

Rob K

-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Jim Lux
Sent: 20 February 2012 19:07
To: time-nuts@febo.com
Subject: Re: [time-nuts] Low-long-term-drift clock for board level
integration?

On 2/20/12 10:31 AM, Bob Camp wrote:

per day of drift. That gets you to 15 us in 1000 days. You may or may not
get one that drifts that little, a lot depends on  little details. For>  3
years, consider an ensemble of cesiums. At $50K each cost can go up pretty
fast.

Either you get a sky view or you change the budget....

But he does have the ability to have an external network connection..
So the real question is whether one could come up with a better-than-NTP
scheme to get the 100 (or 10) microseconds.

I suspect that with sufficiently controlled network paths (which might be
doable in a widescale deployment) and a tweaking of the NTP stuff, you might
be able to get it to work.

100 microseconds out of a day is 1E-10, which is actually a fairly liberal
drift spec for an OCXO or even a TCXO. (which are things like
ppb/day)

Maybe there's a particular time of day (or day of week) when network
uncertainties are minimal, or can be bounded.  So what you really need is a
onboard oscillator that is good at "carry over" between periodic calibration
checks.

One question about the 100 microsecond spec.. is that a worst case at any
instant, or is it an average spec over a day (so a consistent diurnal
variation would cancel out)

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.

Hi Bill:

When the TRANSIT navigation satellites were put in orbit the receivers required Cesium clocks.  The system worked but
was very expensive.
The GPS system was designed so that cheap clocks could be used in the receiver.  This requires getting a lock on 4
satellites instead of the 3 that would be required for a 3D position fix.  The forth satellite allows determining the
the receivers clock offset and rate.

You may be able to do a similar thing in your receivers.  For example if the master node were to send a timing message
at known times (say once at the top of  every hour) the receivers could use that to determine their local clock offset
and rate for those cases where the path was the same (or maybe even for a list of paths).  The offset and rate numbers
can be used to correct the measured time to actual time without changing the clock's rate using simple math.  You can
trade the receiver clock stability for the time between the timing messages.

Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html

Bill Woodcock wrote:

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

On Feb 20, 2012, at 8:34 AM, Achim Vollhardt wrote:

Ahah, but if I had singlemode fiber between locations all over the world, I wouldn't use it to measure the Internet, I'd use it to REPLACE THE INTERNET!  :-)

Seriously, though, thank you for the suggestion, but I'm guessing it'll be easier to start with NTP than with IEEE 1588, since the former assumes the Internet as its operational environment (which is what we actually have) rather than assuming a more predictable network with controlled latencies.

                            -Bill

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

iQIcBAEBCAAGBQJPQtNzAAoJEG+kcEsoi3+HpRIQAM4TK1s+gbXHORxSiXad6If3
FEC8x6GSayf52iRLrvqYcVk+w0oGeTg32eYN+7Zvb8lp75pnaoRP9nQu3Qn6GWZ8
p9LpNKNXR98dXqnH3/25P0xqnq/KPZXiEqOgEYIu8kU36DdlBcjnTEv5esyj1ogV
3uBGvvUMnqzCnrwnL24MJ/oWCEIR4DU6hd8i1gU/KPOA27KBLOFyyzMkRc+UydLo
U5jimmzd7yJUotMY+4UrW0OYlny8xvJ5bh3PHa2ba9omohYMZsGEG2+NCJGy63K9
N2sBbyr0t3ylv0xO51S1bq76OkMnxhILrAyB2NrlFNUgTzDa4FnD4niKQ1BCY8em
DBzJjX1Cf1zgwBUj7OE00RJ9UpZT7ylyfaKZwX4AkeBBxXQiJrS60nzFeJtU+Qx5
iEsXD49Z+VWxSshEvxLplvZlfa1iCka1sg1ictnD90gFYjyWgIExEUQ9BuF5VhdT
7UYB6tDJRuRUZWAXOP3k9YDhtP6q0xizDLOmfBziMfO/orm2l0PWj0v7LMTmVVmR
FudQdAIAOznxstg87+L0wpgLUOU/wkoHZSmoU/oLgWV//75jQkqCm6a6B28giBUO
W/xbusfA4UQQHtgOY6GOuIXBHCSRUE5Euub1usFff3H4G9TjvIYJs/EzuCXACZys
HIgkSJuaTYB1n+N0Zl3S
=IPHP
-----END PGP SIGNATURE-----

Hi

Since the network is being measured, I suspect that using it as the time reference would present a basic problem.

Bob

On Feb 20, 2012, at 2:07 PM, Jim Lux jimlux@earthlink.net wrote:

Hi Bob:

It was my understanding that the receiving station knows the path taken, is that the case? Or are you saying even when
it's the same path the time delay has large variations?

Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html

Bob Camp wrote: