Jeff Epler's blog

27 August 2020, 21:10 UTC

GPS and relativity


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. The ever-helpful leapsecond.com has a copy of an article from lsu.edu stating:
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 1012 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 1012, 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.
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.

An earlier document, NTS-2 Cesium Bean Frequency Standard for GPS states (errors mine)

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-9 with a resolution of approximately 3 × 10-12. 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-11. The relativistic offset was later added to the 10.23MHz requirement.
We might try to detect a hint of emotion in "The offset was …later added to the requirement".

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

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!

Alley: (again, errors mine)

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

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.

TODO: Actually read ashby1979.pdf and see if it adds information compared to any of the above.

Files currently attached to this page:

1977ptti.conf..637W.pdf2.3MB
1978-PTTI-v9-NTS-2.pdf1.7MB
Ashby2003_Article_RelativityInTheGlobalPositioni.pdf460.8kB
a088092.pdf1.1MB
alley1983.pdf7.8MB
ashby1979.pdf2.9MB

[permalink]

6 June 2019, 12:19 UTC

Yet another Raspberry Pi Stratum 1 NTP server


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 "Generic NMEA GPS Receiver".

Here's what worked for me:

Start with a pi3 and raspbian stretch. Add a GPS with TTL-level PPS and 9600 baud NMEA outputs.

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)

Using raspi-config, disable the serial console and enable the serial port hardware.

Manually edit /boot/config.txt to add: dtoverlay=pps-gpio — If you have to (or prefer to) use a different pin for pps, you can apparently specify it as dtoverlay=pps-gpio,gpiopin=##, where ## is the internal numbering of the GPIO pins, not the number on the 40-pin header.

Manually edit /etc/modules and add a line that reads pps-gpio — According to some sources, this step is not necessary.

Install ntpd with apt-get.

Delete all the content in /etc/dhcp/dhclient-exit-hooks.d/ntp, leaving an empty file.

Remove the file /run/ntp.conf.dhcp if it exists.

Edit /etc/udev/rules.d/99-com.rules. On each of the two lines that ends , SYMLINK+="serial%c", append , SYMLINK+="gps%c"

Create /etc/udev/rules.d/99-ppsd.rules with the content SUBSYSTEM=="pps", GROUP="dialout", MODE="0660", SYMLINK+="gpspps%n"

In /etc/ntp.conf, add a stanza to access the GPS:

# 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
(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!)

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

Reboot now and have a look at `ntpq -c peers`. You should see something like this:

     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

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

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:

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:

[permalink]

3 June 2019, 1:17 UTC

Precision vs Accuracy: A Clock


I was inspired by this watch face design (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.

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!)

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)

The clock consists of: .. all in a 3d printed enclosure that's not quite the right size.


The dial as an animation (1 revolution = 12 hours)
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.

[permalink]

All older entries
Website Copyright © 2004-2021 Jeff Epler