Jeff Epler's blog2020-08-27T21:10:08ZPhotos, electronics, cnc, and moreJeff Eplerjepler@unpythonic.netGPS and relativity2020-08-27T21:10:08Z2020-08-27T21:10:08Zhttps://emergent.unpythonic.net/01598562608
This is info I've dug up a few times, but it's getting harder to find. Let's put it here, maybe I'll remember its on my own website.
<a href="http://www.leapsecond.com/history/Ashby-Relativity.htm">The ever-helpful leapsecond.com</a> has a copy of an article from lsu.edu stating:
<blockquote>
At the time of launch of the first NTS-2 satellite (June 1977), which contained the first Cesium clock to be placed in orbit, there were some who doubted that relativistic effects were real. A frequency synthesizer was built into the satellite clock system so that after launch, if in fact the rate of the clock in its final orbit was that predicted by GR, then the synthesizer could be turned on bringing the clock to the coordinate rate necessary for operation. The atomic clock was first operated for about 20 days to measure its clock rate before turning on the synthesizer. The frequency measured during that interval was +442.5 parts in 10<sup>12</sup> faster than clocks on the ground; if left uncorrected this would have resulted in timing errors of about 38,000 nanoseconds per day. The difference between predicted and measured values of the frequency shift was only 3.97 parts in 10<sup>12</sup>, well within the accuracy capabilities of the orbiting clock. This then gave about a 1% validation of the combined motional and gravitational shifts for a clock at 4.2 earth radii.
</blockquote>
It also contains supporting scans of NASA Technical Memorandum 78104, 1977 9th annual PTTI, NTS-2 report showing these statements, although the Technical Memorandum does not state whether the initial pre-tuning value was really due to "doubts" that relativistic effects were real, as compared to other operational reasons.
<p>An earlier document, <a href="https://ui.adsabs.harvard.edu/abs/1977ptti.conf..637W/abstract">NTS-2 Cesium Beam Frequency Standard for GPS</a> states
(errors mine)
<blockquote>
The NTS-2 program office at NRL was tasked by GPS NAVSTAR program office to
generate a 10.23 MHz frequency for use with the Pseudo Random Noise System
(PRNSA) onboard the NTS-2 Satellite. Frequency requrements for the NTS-2 Orbit
Determination and Tracking Systerm (ODATS) was 5MHz with a tunable ΔF offset of
approximately +1 × 10<sup>-9</sup> with a resolution of approximately 3 ×
10<sup>-12</sup>. The ΔF offset was to compensate for relativistic effects and
could not be accomplished by offsetting the cesium standard which has a tuning
range of ± 1 × 10<sup>-11</sup>. The relativistic offset was later added to
the 10.23MHz requirement.
</blockquote>
We might try to detect a hint of emotion in "The offset was …<em>later added</em> to the requirement".
<p>Citing "Alley, C., “Proper time experiments in gravitational fields with atomic clocks, aircraft, and laser light pulses”, in Meystre, P., and Scully, M.O., eds., Quantum Optics, Experimental Gravitation, and Measurement Theory", we have
<blockquote>
There is an interesting story about this frequency offset. At the time of launch of the NTS-2 satellite (23 June 1977), which contained the first Cesium atomic clock to be placed in orbit, it was recognized that orbiting clocks would require a relativistic correction, but there was uncertainty as to its magnitude as well as its sign. Indeed, there were some who doubted that relativistic effects were truths that would need to be incorporated!</blockquote>
<p>Alley: (again, errors mine)
<blockquote>
There was considerable uncertainty among the Air Force and contractor personnel designing and building the system whether these effects were being correctly handled, and even, on the part of some, whether the effects were real. The last group was not satisfied until a gravitational frequency shift was measured with a GPS test satellite called NTS-2 by a group at the Naval Research Laboratory in 1977.
</blockquote>
Alley cites T. McCaskill, J. White, S. stebbins, and J. Buisson, NTS-2
frequency stability results, "Proceedings, 32nd Annual
Symposium, on Frequency Control," U. S. Army Electronics
Research and Development Command, Fort Monmouth, N.J.
(1978), a different paper with many of the same names as the first Technical Memorandum. However, I don't see that the citation supports the "considerable uncertainty" nor that any doubted "whether the effects were real". It just states that "the Einstein relativistic clock effect was verified to less than one-half percent".
<p>So, left without a citation to follow, I am still in doubt as to whether there were doubters of general relativity on the project. Rather, except for the resigned voice that the offset was "later added" everything seems consistent with: GR (at least once the issue was raised) was assumed correct, but for other reasons (such as synchronizing it with the ground based cesium clocks before launch) the system was built with two modes, and that a story about doubters grew in the retelling.
<p>TODO: Actually read <a href="https://media.unpythonic.net/emergent-files/01598562608/ashby1979.pdf">ashby1979.pdf</a> and see if it adds information compared to any of the above.
<p><p><b>Files currently attached to this page:</b>
<table cellpadding=5 style="width:auto!important; clear:none!important"><col><col style="text-align: right"><tr bgcolor=#eeeeee><td><a href="https://media.unpythonic.net/emergent-files/01598562608/1977ptti.conf..637W.pdf">1977ptti.conf..637W.pdf</a></td><td>2.3MB</td></tr><tr bgcolor=#dddddd><td><a href="https://media.unpythonic.net/emergent-files/01598562608/1978-PTTI-v9-NTS-2.pdf">1978-PTTI-v9-NTS-2.pdf</a></td><td>1.7MB</td></tr><tr bgcolor=#eeeeee><td><a href="https://media.unpythonic.net/emergent-files/01598562608/Ashby2003_Article_RelativityInTheGlobalPositioni.pdf">Ashby2003_Article_RelativityInTheGlobalPositioni.pdf</a></td><td>460.8kB</td></tr><tr bgcolor=#dddddd><td><a href="https://media.unpythonic.net/emergent-files/01598562608/a088092.pdf">a088092.pdf</a></td><td>1.1MB</td></tr><tr bgcolor=#eeeeee><td><a href="https://media.unpythonic.net/emergent-files/01598562608/alley1983.pdf">alley1983.pdf</a></td><td>7.8MB</td></tr><tr bgcolor=#dddddd><td><a href="https://media.unpythonic.net/emergent-files/01598562608/ashby1979.pdf">ashby1979.pdf</a></td><td>2.9MB</td></tr></table><p>
Yet another Raspberry Pi Stratum 1 NTP server2019-06-06T12:19:03Z2019-06-06T12:19:03Zhttps://emergent.unpythonic.net/01559823543
There are lots of instructions for setting up a Stratum 1 NTP server
on your Raspberry Pi. A lot. After much research, I found a simple
configuration that uses a single ntp reference clock and does not involve
gpsd, but uses both NMEA and PPS for the most accurate timekeeping possible.
NMEA+PPS is a mode of NTP's "<a href="http://doc.ntp.org/4.2.8p10/drivers/driver20.html">Generic NMEA GPS Receiver</a>".
<p>Here's what worked for me:
<p>Start with a pi3 and raspbian stretch. Add a GPS with TTL-level PPS and 9600
baud NMEA outputs.
<p>Hook up you GPS: GND and +3.3V or +5V (according to the specifiics of your GPS)
to any matching pin, the GPS's TX output to the Pi's RX input on pin 10
of the header, and the GPS's PPS output to the Pi's pin 12. (You can hook
up your GPS's RX input to the Pi's TX output on pin 8 if you like, but I don't
think this is necessary)
<p>Using raspi-config, disable the serial console and enable the serial port
hardware.
<p>Manually edit /boot/config.txt to add: <tt>dtoverlay=pps-gpio</tt> —
If you have to (or prefer to) use a different pin for pps, you can apparently
specify it as <tt>dtoverlay=pps-gpio,gpiopin=##</tt>, where ## is the
internal numbering of the GPIO pins, not the number on the 40-pin header.
<p>Manually edit /etc/modules and add a line that reads <tt>pps-gpio</tt> — According to some sources, this step is not necessary.
<p>Install ntpd with apt-get.
<p>Delete all the content in /etc/dhcp/dhclient-exit-hooks.d/ntp, leaving an
empty file.
<p>Remove the file /run/ntp.conf.dhcp if it exists.
<p>Edit /etc/udev/rules.d/99-com.rules. On each of the two lines that ends
<tt>, SYMLINK+="serial%c"</tt>, append <tt>, SYMLINK+="gps%c"</tt>
<p>Create /etc/udev/rules.d/99-ppsd.rules with the content <tt>SUBSYSTEM=="pps", GROUP="dialout", MODE="0660", SYMLINK+="gpspps%n"</tt>
<p>In /etc/ntp.conf, add a stanza to access the GPS:
<pre>
# gps clock via serial /dev/gps0 and /dev/gpspps0
server 127.127.20.0 minpoll 3 maxpoll 3 mode 16 burst iburst prefer
fudge 127.127.20.0 refid GPS time2 +.250 flag1 1
</pre>
(leave the "pool" line(s) or other ntp server lines; if your pi doesn't
have a battery-backed RTC, you need a way to get the correct time initially,
before a GPS fix may be available!)
<p>"time2" doesn't seem critical with this setup, because the PPS time is
preferred over the serial reception time. "minpoll", "maxpoll", "burst"
and "iburst" may be superstitious and unnecessary.
<p>Reboot now and have a look at `ntpq -c peers`. You should see something
like this:
<pre>
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(0) .GPS. 0 l 1 8 377 0.000 -0.001 0.003
+ntp.u .GPS. 1 u 2 8 377 1.104 0.013 0.064
</pre>
<p>"GPS_NMEA" is selected as peer and is using PPS (this is what "o" in the
first column means). delay, offset, and jitter should all be extremely small
(Here, .001 is 1 microsecond). "ntp.u" is my other local stratum-1 NTP server.
The "+" indicates it's in good agreement with the local GPS. If you use pool,
you will see multiple lines here; some may have "+" and some may have "-".
<p>If something's not working, you will get, " " (blank), "-" or "x" next to
GPS_NMEA. If it's got "*" then NMEA is working but PPS isn't. Now you get to do things like debug whether the PPS signal is working properly according to ppstest, whether NMEA messages are actually coming in
at 9600 baud, etc. Or you can follow one of those other guides. :wink:
<p>Here's how the local time to GPS offset has looked over the last
10 hours or so — I find it awesome that my computer appears to be
synchronized to GPS to within ±5 microseconds almost all of the time:
<p><img src="https://media.unpythonic.net/emergent-files/01559823543/ntp-offset.png">
<p>Precision vs Accuracy: A Clock2019-06-03T01:17:09Z2019-06-03T01:17:09Zhttps://emergent.unpythonic.net/01559524629
<div style="float:right;clear:right"><!-- IMG_20190602_205835.jpg--><div class=albumouter style=width:306px id=><div class=albumimage style="width:306px;margin-left:0.0px;"><a href="https://media.unpythonic.net/emergent-files/01559524629/IMG_20190602_205835-medium.jpg" class="thickbox" rel="album" title="The clock, in all its glory"><img src="https://media.unpythonic.net/emergent-files/01559524629/IMG_20190602_205835-small.jpg" width=300 height=198></a><div ><div style="float: right" ><a href="https://media.unpythonic.net/emergent-files/01559524629/IMG_20190602_205835-medium.jpg">(M)</a><a href="https://media.unpythonic.net/emergent-files/01559524629/IMG_20190602_205835.jpg">(L)</a></div><a href="https://media.unpythonic.net/emergent-files/01559524629/IMG_20190602_205835.jpg">The clock, in all its glory</a></div></div></div>
</div>
<p>I was inspired by <a href="https://hop-picker.tumblr.com/post/51065757240">this watch face design</a> (I think that's the original version) and by the arrival
of a "OCXO", a very reliable time keeping circuit, to finally make an
electronic clock.
<p>Accuracy: Between hardware and software tuning, the OCXO keeps time with
an accuracy of possibly better than 100 microseconds per day (loses or gains
well less than a half second per year)
(Yes, I'm deliberately ignoring a lot about crystal aging here!)
<p>Precision: The time displayed is to the nearest minute, and the touchscreen
setting mechanism is (deliberately?) poor, making it hard to set the time
closer than +- 2 minutes or so. Oh, and it takes a good fraction of a second
to update the screen anytime it changes. (The best way to set it seems to be
to wait until a few seconds before 6AM/6PM and plug it in, since it boots with
that time showing)
<p><div style="float:right;clear:right"><!-- timelog.png--><div class=albumouter style=width:306px id=><div class=albumimage style="width:306px;margin-left:0.0px;"><a href="https://media.unpythonic.net/emergent-files/01559524629/timelog-medium.jpg" class="thickbox" rel="album" title="Estimated accuracy of the OCXO vs GPS: 60 microseconds per day?"><img src="https://media.unpythonic.net/emergent-files/01559524629/timelog-small.jpg" width=300 height=187></a><div ><div style="float: right" ><a href="https://media.unpythonic.net/emergent-files/01559524629/timelog-medium.jpg">(M)</a><a href="https://media.unpythonic.net/emergent-files/01559524629/timelog.png">(L)</a></div><a href="https://media.unpythonic.net/emergent-files/01559524629/timelog.png">Estimated accuracy of the OCXO vs GPS: 60 microseconds per day?</a></div></div></div>
</div>
The clock consists of:
<ul>
<li> A <a href="https://www.adafruit.com/product/2390">PyBoard</a> running micropython
<li> A <a href="https://www.adafruit.com/product/1591">touchscreen LCD</a> and controller
<li> A <a href="https://www.tindie.com/products/deBug67/10mhz-frequency-reference-ocxo-t/">10MHz OCXO frequency reference</a>
</ul>
.. all in a 3d printed enclosure that's not quite the right size.
<p><div style="float:right;clear:right"><!-- clock.gif--><div class=albumouter style=width:306px id=><div class=albumimage style="width:278px;margin-left:14.0px;"><img src="https://media.unpythonic.net/emergent-files/01559524629/clock.gif"><br><span>The dial as an animation (1 revolution = 12 hours)</span></div></div>
</div>
Along the way, I added an even more accurate time source to a Raspberry
PI (GPS with PPS) so that I could even measure the accuracy of the OCXO, and
discovered I even have a GPS module which was negatively affected by the GPS
rollover that occurred in April of this year (the second 1024-week rollover).
This leads to a surprising sequence of clock arithmetic, and finally gpsd
decides the GPS is returning a date sometime back in 1963.