Re: [time-nuts] Frequency deviations in Europe affect clocks

[Bill Woodcock]

> On Mar 8, 2018, at 6:39 AM, Jean-Louis Rault  wrote:
> 
> A picture of my own microwaves oven, this 8th of march, near Paris, France .


https://preview.entsoe.eu/news/2018/03/06/press-release-continuing-frequency-deviation-in-the-continental-european-power-system-originating-in-serbia-kosovo-political-solution-urgently-needed-in-addition-to-technical/


-Bill



signature.asc
Description: Message signed with OpenPGP
___
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.

Re: [time-nuts] Atomic Watch

[Bill Woodcock]

>>> On Mon, Oct 17, 2016 at 9:45 PM, Jim Palfreyman 
>>> wrote:
>>> 
 Well I think there's a mistake or two here...
 
 https://www.inverse.com/article/20497-john-patterson-atomic-ce

But, MARS!

-Bill






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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.

[time-nuts] Fwd: "NUT4ANT is a four-channel, all-frequency, GNSS RF-to-bits receiver"

[Bill Woodcock]

Perhaps of interest, forwarded from CrowdSupply.

-Bill


> Begin forwarded message:
> 
> From: Crowd Supply 
> Subject: A satellite-guided floating Panopticon bristling with the talons of 
> freedom
> Date: September 22, 2016 at 2:56:38 PM PDT
> To: 
> Reply-To: Crowd Supply 
> 
> The latest and greatest from Crowd Supply.
> View this email in your browser 
> 
>  
> 
> 
> “Electricity is really just organized lightning.”
> ― George Carlin
> Now Funding
>  
> 
> NUT4ANT is a four-channel, all-frequency, GNSS RF-to-bits receiver. Hacking 
> on a Global Navigation Satellite System (GNSS) has never been easier or more 
> fun.
> Learn About NUT4ANT 
> 
> 






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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.

[time-nuts] Fwd from NANOG: Erroneous Leap Second Introduced at 2014-06-30 23:59:59 UTC

[Bill Woodcock]

Begin forwarded message:

 From: Tim Heckman t...@heckman.io
 Date: June 30, 2014 at 17:33:52 PDT
 To: na...@nanog.org
 Subject: Erroneous Leap Second Introduced at 2014-06-30 23:59:59 UTC
 
 Hey Everyone,
 
 I just was alerted to one of the systems I managed having a time skew
 greater than 100ms from NTP sources. Upon further investigation it
 seemed that the time was off by almost exactly 1 second.
 
 Looking back over our NTP monitoring, it would appear that this system
 had a large time adjust at approximately 00:00 UTC:
 
 - http://puu.sh/9Rs6O/a514ad7c97.png (times are in Pacific in these
 graphs, sorry about that)
 
 A few of our systems did alert early this morning, indicating they
 were going to be receiving a leap second today. However, I was unable
 to determine the exact cause for NTP believing a leap second should be
 added. And after some time a few of the systems were no longer
 indicating that a leap second would be introduced.
 
 This specific system is hosted in AWS US-WEST-2C and uses the
 0.amazon.pool.ntp.org pool.
 
 Has anyone else seen any erroneous leap seconds being added to their system?
 
 Cheers!
 -Tim Heckman
___
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.

Re: [time-nuts] Boeing 787 GPS reception trouble

[Bill Woodcock]

I've flown on 787s three times before, and am about to do so again later today. 
 The prior times I used my cell phone as normal and didn't give it any thought. 
 This time I'll pay particular attention and report back.  Twice for me have 
been Ethiopian Air, once London-Addis, once Dulles-Addis. The third time was 
ANA Osaka-San Francisco.  Today will be London-Addis again, but a different 
actual plane, since the previous one is one of the ones that burned. 

-Bill


 On Jun 2, 2014, at 10:03, Tom Van Baak t...@leapsecond.com wrote:
 
 1) When I fly I often use my iPhone while on the ground, before take-off or 
 after landing.
 
 2) I sometimes carry a GPS receiver. When permitted (varies by airline), it's 
 fun to log NMEA data for a flight and later plot the flight path and duration 
 with UTC accuracy.
 
 3) On occasion I also bring a logging Geiger counter. It's amazing how much 
 background radiation there is up at flight altitude compared to down at 
 ground level. You can go from 10 or 20 CPM (counts per minute) at home to, 
 say, 500! CPM at 40k feet. Those of you who live in mile-high Colorado enjoy 
 higher background levels. I know, because my Geiger counter was wonderfully 
 close to 60 CPM (= 1 CPS) in a hotel near NIST. Yes, I have the 1PPS ADEV 
 plot for this and, yes, background radiation makes the world's worst atomic 
 clock.
 
 Anyway, over the years I've collected some nice GPS 
 latitude/longitude/altitude data sets as well as background radiation as a 
 function of altitude. Just to be clear, I do turn off these devices according 
 to airline regulations.
 
 Now I have never had a problem with reception in the terminal, walkway, or 
 even while seated inside a plane. I figured the aluminum frame of the plane 
 was thin enough that photons at cell, GPS, and gamma frequencies easily pass 
 through the outer shell or the windows.
 
 But last week I flew the new composite Boeing 787 Dreamliner and noticed 
 something quite different. From the second I entered the plane, I lost both 
 cell and GPS reception. It didn't matter how close I was to a window or not. 
 I know the word composite sounds inert, but carbon fiber must be somewhat 
 conductive, yes? And there must be serious lightning suppression layers too, 
 maybe? Furthermore, the B787 windows are exotic; like giant oval LCD screens 
 which electronically dim from near transparent to very opaque. Does all this 
 make the new 787 a record-holding RF-tight flying Faraday cage?
 
 Is this the first airplane in history where a time-nut can't receive GPS? At 
 least gamma rays make it though, so I got RAD data. But no GPS data. Not a 
 single SV fix the entire time I was inside the plane.
 
 Has anyone else noticed this? Or know about this? Please respond only if you 
 have real information. I can speculate as well as anyone; so it's solid 
 technical, RF, EMF, or composite carbon fiber engineering info I'm looking 
 for.
 
 Thanks,
 /tvb
 
 ___
 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.

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

Re: [time-nuts] Boeing 787 GPS reception trouble

[Bill Woodcock]

I'm posting this from inside an Ethiopian 787, on the ground, with the doors 
closed.  I just completed a fifteen-minute voice call initiated from inside the 
plane, with reasonable reception and no drops, while the doors were open.  And 
I was able to get a new GPS location in less than two seconds (though that 
wasn't from cold boot, so I don't know whether it was able to accelerate the 
process using cached data previously received). The phone (an iPhone 5S) is 
showing three bars inside the plane, and was varying between three and four 
bars outside. Note that the non-linear mapping of signal strength to bars is 
a matter of intense negotiation between carriers and vendors, and shouldn't be 
taken as a literal indicator of anything at all.  Likewise, Ethiopian may have 
ordered planes with significantly different options than ANA (no center 
overhead storage in business, for example) and used different paint 
formulation. 

Nevertheless, in this specific case, I'm not seeing anything that seems 
out-of-the-ordinary relative to other aircraft. 

-Bill


 On Jun 2, 2014, at 10:03, Tom Van Baak t...@leapsecond.com wrote:
 
 1) When I fly I often use my iPhone while on the ground, before take-off or 
 after landing.
 
 2) I sometimes carry a GPS receiver. When permitted (varies by airline), it's 
 fun to log NMEA data for a flight and later plot the flight path and duration 
 with UTC accuracy.
 
 3) On occasion I also bring a logging Geiger counter. It's amazing how much 
 background radiation there is up at flight altitude compared to down at 
 ground level. You can go from 10 or 20 CPM (counts per minute) at home to, 
 say, 500! CPM at 40k feet. Those of you who live in mile-high Colorado enjoy 
 higher background levels. I know, because my Geiger counter was wonderfully 
 close to 60 CPM (= 1 CPS) in a hotel near NIST. Yes, I have the 1PPS ADEV 
 plot for this and, yes, background radiation makes the world's worst atomic 
 clock.
 
 Anyway, over the years I've collected some nice GPS 
 latitude/longitude/altitude data sets as well as background radiation as a 
 function of altitude. Just to be clear, I do turn off these devices according 
 to airline regulations.
 
 Now I have never had a problem with reception in the terminal, walkway, or 
 even while seated inside a plane. I figured the aluminum frame of the plane 
 was thin enough that photons at cell, GPS, and gamma frequencies easily pass 
 through the outer shell or the windows.
 
 But last week I flew the new composite Boeing 787 Dreamliner and noticed 
 something quite different. From the second I entered the plane, I lost both 
 cell and GPS reception. It didn't matter how close I was to a window or not. 
 I know the word composite sounds inert, but carbon fiber must be somewhat 
 conductive, yes? And there must be serious lightning suppression layers too, 
 maybe? Furthermore, the B787 windows are exotic; like giant oval LCD screens 
 which electronically dim from near transparent to very opaque. Does all this 
 make the new 787 a record-holding RF-tight flying Faraday cage?
 
 Is this the first airplane in history where a time-nut can't receive GPS? At 
 least gamma rays make it though, so I got RAD data. But no GPS data. Not a 
 single SV fix the entire time I was inside the plane.
 
 Has anyone else noticed this? Or know about this? Please respond only if you 
 have real information. I can speculate as well as anyone; so it's solid 
 technical, RF, EMF, or composite carbon fiber engineering info I'm looking 
 for.
 
 Thanks,
 /tvb
 
 ___
 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.

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

Re: [time-nuts] Looking for Dual-Time Atomic Clock

[Bill Woodcock]

All the ones we use are from BRG Precision Products:

http://www.brgprecision.com/products/time_zone_displays/index.php

Here’s what it looks like on the wall:

https://www.pch.net/dnssec/zrh

-Bill






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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.

[time-nuts] Story in the Economist about GPS jamming

[Bill Woodcock]

http://www.economist.com/news/international/21582288-satellite-positioning-data-are-vitalbut-signal-surprisingly-easy-disrupt-out?fsrc=scn/tw/te/pe/outofsight

-Bill





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

Re: [time-nuts] NTP Clock suggestions?

[Bill Woodcock]

On May 27, 2013, at 8:21 AM, Eric Williams wd6...@gmail.com wrote:
 I'm happy with my OnTime dial clock.

I have been very happy with the ones I've gotten as well.  That said, I have 
one that my wife managed to snag the Ethernet cord on, ripping the Ethernet 
jack off the motherboard.  It's free to anyone who feels like a minor soldering 
project and wants to pick it up in Berkeley or send me a prepaid mailing label. 
 Model number is ONTA12-BK.  It's also missing the clear plastic front cover, 
since it was one I was going to build into a nicer frame for the house.

http://www.inovasolutions.com/network-clocks/products/analog-wall-clock.htm

-Bill





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

Re: [time-nuts] Low-long-term-drift clock for board levelintegration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 21, 2012, at 11:12 AM, Mark Spencer wrote:

 Perhaps another way to approach this problem would be to see if there are 
 entities and or individuals who already have precision time keeping equipment 
 (or at least access to GPS antennas) who might be able to participate in 
 collecting this data.

That approach has been tried by RIPE, and it yielded a couple of dozen 
usefullly-reliable measurement points after five years, twenty thousand 
man-hours, and about USD 1M in investment.  That's not the approach we're 
taking, though certainly it has produced some useful results.  The rate at 
which the number of links increases as a function of the number of nodes in a 
full mesh is a powerful incentive to pursue larger numbers of nodes.

-Bill




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

iQIcBAEBCAAGBQJPRD9hAAoJEG+kcEsoi3+Hwz4P/ibMR1SHnnsVmxdfWYKffRgF
xsZ/x4MAxb2feGIAQ0kNJXCrywZbPY4Ip0xpZpv/q5TsmpYUq4NXD3V1Li6qJhoY
jixRiCDwXwpkSBsLc7nqRelUELSU4xoAejNzIEEDZsXVfJcMydPrUv0ge+Hwz2Tg
S0GDaQYofZkNKUn1m3dFhLckM+gmKZpO6Q8BxD2s+AYlH83igAaTGl4qHpcvqEo6
FTP9lNTMbvzoCH7XT3VnQnQs2x93dKpBdZ15nMveONSahsFIFugePi0oEU6XMxe7
P/qweVmGNzUH0yLnGOT7FkwOuDyvPoeR052damXX/vsYuJFPqOJQsLl8RGIY5zZC
iGgNwCXFjnoxuNdHnUD3hvVZTVXGdLIU8G1XYua5eu/PktWVE1b8ZIwlI1wsM7K1
k/4aJGspVIOSlhiD775hMUGxd42fLiahmyCx4J6Y0y09XH4kusDIjhkKpaqFKdPL
foNj0w0lLEZI8VmFQ6oDaluKtWuIeiYk+SMRvAfazD7MDDMugbN/R1rxKMspCNyF
oD+B/dYJb0x8kgVP7eqerheaxBWwNXps0/XwsJggDczkPQw74uwEvK6I1DGLF9US
gHQDonmu1tyXfRGin4Zrexg10KpQj3hbLqGH8/gkgfk2AUyXDyt5uHCmOntUaT1o
OG84FIP5veDAzm7hukgY
=FYYB
-END PGP SIGNATURE-


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

Re: [time-nuts] Low-long-term-drift clock for board levelintegration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 What if one sends a message one way that triggers say, 10 response messages 1 
 second apart.   Then you get distribution statistics on the return path.  You 
 still don't know what the absolute forward or reverse path time was, of 
 course.

Yes, that's one of the things that we do.  You don't need a trigger, you can 
just transmit the beacon.  That's how we measure jitter and out-of-order 
delivery, and how we detect parallel paths.

-Bill




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

iQIcBAEBCAAGBQJPRD1RAAoJEG+kcEsoi3+HUZ8P/RWJMhsT0AfAQa7a/AOb69Jm
n6AAz3YT62iyHkzzW7qVRT/2sL7+Vp0CWCMgDKnTlZJuQ4bvrnblFKVBV3eCfxWq
SJN6kMjLP+O/zd9hvghxZISMvdptEdJiMILoxGdeYJDLwblsewT8ZxC77VzNi24x
KNtAiJScJ6+3R5r1oAYg/+Uro1WNJCVFfTkixmB4GC/S7Ph9cxzHlxTb7jHo6D+I
sZm3a06JeudgKReE8PdJkrbv4vJNQFSHNSUI4M/BGevMp+nWppZcVCtIVwfYUY+0
jipE/oSaGllKhSZKs7t0Dn1/qcnMDGuSi238HiPWBvHPn7mNvsKXnupXcUW4E1jD
AIf1Sjh8KLVdvRPUgcqa4nhPoOOkasBGqOCYY67GyGyc7MpyOn5BndkV3DvvuVXY
D84VQOmgv2hvKt1Llbf6/Zqb2x1t+EkHO+1Ms6DifoUZwCGMnJDKiuuBMWKOrCJC
hp8LGJg2mfVwDkznULZ9zRHNqAWU378gYa4SmdqsPZ3QXD7Pz6f3pDy47PQQfXgy
A7hSrGPlEQaoyS/pFRjJzX4Z4M2+FJ7ci+FeajjlxAxCwGAg1nB1Hv0kTkY+F2H7
4s5L7AiOG4SGzFWjmucMKPDp2fLObxmZx7fFKCiW/Sft6cRaUNZYsk/OVNuQ4S5Y
WSOhqeWT9a0oThcFUSQg
=864K
-END PGP SIGNATURE-


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

Re: [time-nuts] Low-long-term-drift clock for board levelintegration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 21, 2012, at 10:05 AM, Chris Albertson wrote:
 BTW, Is the O.P. still here?   I wonder if he is re-thinking his
 requirements.

The requirement is to do one-way delay measurements.  The requirement isn't 
changing.  I'm just here to educate myself as to how to do the best job we can.

 (1) Your method: [one-way delay]
 (2) Easy method: [traceroute[
 I suggest using method #2 for your network timing.   Method #1 is
 simply to expensive and technically hard 

That's why there are some of us who spend money and work on hard problems.  
Traceroute already exists.  In fact, plenty of one-way delay measurements 
already exist.  We're just doing a larger, better one.  Yes, that takes time 
and money.  Math is hard, let's go shopping isn't a particularly interesting 
argument.

-Bill




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

iQIcBAEBCAAGBQJPRECuAAoJEG+kcEsoi3+H0QEP/jT7VAz6h7a+C/uFWnU8S7P5
4KwElPQBjkl6O9gbDGkPZ9JxI7wolrV/W5aQyAafc9tpXtcPlqwtINbxfdpz0tcc
NDo24ths2TOL7e8Z51Z/dCTrrnUNCLPVhw/uOkYFu/SOrDOXjj6CNwfvh8Lvz3zx
sTvxWj/yaccPydO0vnuAXQWP+e8NIQlADwT2ZJJ2lriZulDXoLalH/OKTgSzIkcM
0W08yzPjKi4SvYsMZSkg6lkacNugfBBinZdizw3g2RowOfCjkXKtKVcIMSAhGaxG
3eb3Gqvv3iDn04MzIJuuQx8a1Cui0HhN/98cDPGOk+3xiEVI016QwYFl0SxeZmp8
v3lOz3FYia7mwRJlPRgALGOLelkIIjoZqLRdYXyBS8U5jVdjvaA4IbftBNUXvGHw
4C8z3s2ywmfFFuA4hbUWgDW9uZR48Byw1ViYpdcT2654ZoqcADQ9RkD96yL1ddd9
Z7nwbf154SFTouDei4nCL9W6HmE3CZrPKoKc3H1vWD+ys3jDjul0343nWCXbbjUL
3F7gnB9viOM0wGXrhaJ1dpUGdHNpWYVxaY3tKMClUbRxsfh7eTBCEIWLA20cH79C
/l2+ZM16GO8AYiELGNum+OWeYak8iAFG+5KaTIeKXI51ksXf8jiODCBhGwnXlHKi
9Hlji30Hjo7mGSAexcXR
=v+Vt
-END PGP SIGNATURE-


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

Re: [time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 20, 2012, at 8:34 AM, Achim Vollhardt wrote:
 what about White Rabbit?
 It delivers Gigabit Ethernet and precise (1nsec) timing over singlemode 
 fiber. 

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-


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

Re: [time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 20, 2012, at 11:07 AM, Jim Lux wrote:
 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)

Well, it's not a hard limit, it's a target at which our system would be 
performing at a level we'd be happy with.  Obviously some measurements will be 
less accurate, others more so, and we get what we get.

One of the primary reasons for doing link-by-link unidirectional delay 
measurement is to estimate the length or routing of cables.  Each microsecond 
of inaccuracy is 650 feet of inaccuracy in the estimate.  650 feet isn't of any 
interest.  But twelve miles (100 microseconds of inaccuracy) is starting to get 
up into the range where you might not be able to distinguish one city from 
another, for instance.  One millisecond is 123 miles, and we might well be into 
another country or something at that point.

Measuring queue depths and estimating degrees of resource contention or 
processing inside routers is a more complex topic, but similar in that it tends 
to still be interesting in the 100 microsecond range, but less so at another 
order of magnitude less precision.

-Bill




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

iQIcBAEBCAAGBQJPQvtsAAoJEG+kcEsoi3+HafsQAJQJAkux30PcrGkzcw2oZQNx
7xKXvGYA/V4Lnr11NpB/7x8JewiXvKC83iSLlJGRpmNC3Sy1egbbP13YMkfew83l
YcOn5O5g+d336//EA/hj4lrQAslr3HGG7nayt7sIZPbLnkBuiWf4mv8YMUSi+f/B
RMSeSCtGPbEwa7aqs6MmTZ4QKZIzE587v5nsoZFnN056NbE+kS2MrlF2Y5ll0apC
cfE/RBAoYp3X8ev+Gh+C0jxHX4nfutDaS/vAcJub5o/WDW3rmn5yj7wztiDst2T/
36ACCxAfll0EqbcmYQF97/rOiteLJOyJOjzOEXBrV/at2v66bYwENKRSwZYMRgVT
tG/7+fgZ/DOFCPCjE/y/Ywgmfn5vAn+iNHaW3hUxi0xVgCidQwEZtVyqwrj8LC4Z
XFKWG+eUwNLWAnCI2KZAJJFYHtaZooXlSQXuh4IwfCZPeD1by49u4aH6LRLbP1at
eXghWWjhOL4WzGzGQFn/WnPLB+cYADzarNuQf3uk2e2DvgJh4/JJH3H/+IX2m7UF
4Vc6Cm3ojlhnMMbmdA5IUrpqawfGgd61y+7LEK3vjwK6x8XMWjNV/RL6JfSrrs/i
JoxF1svN+HVYIykn2fSPjnaODbzw+BgtAweCZ22YtkECWQA7m0kFGqSDYe/s2xwG
ddesTvAo4pZ+O7j6Lpl2
=149M
-END PGP SIGNATURE-


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

[time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi. This is my first posting to this list, and I'm not a timekeeping engineer, 
so my apologies in advance for my ignorance in this area. 

I'm building a small device to do one-way delay measurements through 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.  

- From that point forward (and we hope the devices will have an 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. 

My plan, such as it is, was just to get the best clock I could find within 
budget, integrate it onto the motherboard we're laying out as the system clock, 
and depend on NTPd to do the right thing with it.  

Anyone have any thoughts or advice on clocks I could use that would be, say, 
under USD 300 in quantity 500, and would be optimized for minimal long-term 
drift?  Power-use is not particularly constrained.  It needs to be integrated 
onto our board, but space isn't too constrained either. 

I'm also happy to pay for a few consulting hours if people want to give me 
detailed advice on a professional basis. 

Thanks,

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

iQIcBAEBCAAGBQJPQYw8AAoJEG+kcEsoi3+HfuUP/3+VVQs+dyRL4ToEoCaAI0eQ
8TMEV1PD7r775P/rSA0M1wWzFsTxAegixUbBHmQDvgc2ouaEiN0ZJvQrbNwBxR8M
+b7QIuxB4h84JYyvw+Add6l8HjWWWttDW52YiUEdNmv228Q+XO7z/CMBrZ79c9bB
VeZ5CEJl3zLcEDthpBKxgtEKtHFqURUCQ0b3uqWC4dTYld3yTJ9NB7/mt5bLDlEF
IoA02IKurWBgkmNf92FU2SeC458mPejw2EiYaQ/acSv8mK23q56XJoo0O1ogNhAk
qajdSBj/z9hlLTKgRH5jBorwNeRwr0TN8AoyPjBBqIRAI14Q1QHbLJu5twhy5C92
oE78LzedFa93GBPg8+6mdxYgevG4Pm8v8qeB6CdlDBJVD8s91QF0m52Gce+l2H9V
PUGO7ACWjhVdi7VIWSOeSYGlIlqsLV4C7UYLYS+4zy0+dnrgeLFeYf9A29i6Krhr
BCrtPvE6XrC0JUr3oZ0gDzh/T9JPr0XFmWkA0w9JmOAK7D+YWfa7jTBS+vbSXemo
5XBpjK2Ioo9JBwKmUF1Gd8dOO7fSm7cclxfRYwmjjzvSGG+vXCihWhaLzJdwJz6Z
PYf60+hk23Mhrfk4V2qjTi1hVg9FJtxxNA3oC0MRuuwU45tXGIFcUqpSw3F+FS6f
IuLyIrTqwVzdakZL997f
=PpgK
-END PGP SIGNATURE-


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

Re: [time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 19, 2012, at 5:07 PM, Bill Hawkins wrote:
 If you are going to correct it with NTP, a simple crystal
 oscillator will do.

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.

 If you're using NTP, why do you need to
 initially set it to GPS accuracy?

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

 Your best solution is to maintain the GPS antenna and only use
 GPS to discipline a good crystal oscillator.

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.

 Do you plan to regulate the ambient and power environment to
 some degree of accuracy?

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?

 
 Note that 10 microseconds is 1 part in 10E5.
 The folks on this list deal in parts per 10E12.

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?

 Can you use a standalone receiver to always generate a 10 MHz
 signal or pulse per second signal that is distributed to all
 of the measurement devices in a facility?

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-


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

Re: [time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 19, 2012, at 7:28 PM, Dennis Ferguson 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…

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

 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.

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

 - 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

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.

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

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

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

  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.

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.

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

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-


___
time-nuts mailing list 

Re: [time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 19, 2012, at 9:02 PM, saidj...@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:

http://trl.trimble.com/docushare/dsweb/Get/Document-50/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.

 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 ?

Exactly.

 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 

Re: [time-nuts] Low-long-term-drift clock for board level integration?

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Feb 19, 2012, at 10:20 PM, Dennis Ferguson wrote:
 I think you may find that in many (most?) other
 countries the GSM BTS gear has no idea what time it is.

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-


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