Monday, October 15, 2018


I've decided that I might as well accept the Buddhist view of time: that time itself is an illusion and our conception of it is merely a measure. The only way we have to perceive time is in the relative order of events that take place, regardless whether time somehow exists independently of these events or not. All timekeeping ultimately depends on a frequency source - or oscillator - which is nothing but a generator of evenly spaced events. The number of events generated per second is the frequency of the oscillator, and is measured in Hertz.

(Clock with a 4Hz oscillator using a pendulum resonator and a deadbeat escapement.)

Every oscillator makes use of a resonator, some source of periodicity that we take from nature: the motion of the sun, the fall of a drop of water, the swing of a pendulum, the rotation of a balance wheel, the vibration of a quartz crystal, the hyperfine transition of a cesium atom. If something happens faster than the interval between the beats of that oscillator, the only way to measure that interval is to use an oscillator with a higher frequency, which may mean a different resonator: the transition of an aluminum atom or of a ytterbium atom. How do we use these oscillators? By treating each beat of the oscillator as an event, and counting the number of events that occur during the time interval we want to measure.

(Watch with a 6Hz oscillator using a balance wheel resonator and a lever escapement.)

Is there a maximum possible frequency? Physicists think so: the reciprocal of one Planck time, which is about 5.39 x 10-44 seconds. It's the amount of time it takes a photon to cross a Planck length. One Planck time is the shortest time interval physicists believe can meaningfully occur, the duration it takes for the fastest possible object to cover the shortest possible distance found in nature. My calculator tells me that such a hypothetical Planck-frequency oscillator beats at a frequency of about 1.85 x 1043 Hertz. That's a lot of Hertz.

(Slow motion deadbeat escapement creating the tick tock.)

What happens between the beats of this hypothetical Planck-frequency oscillator? The question has no meaning; we believe one Planck time is the smallest possible interval that can occur. Time might as well not exist between the beats of a Planck-frequency oscillator. If we want to talk about the time between any two events, we have to find a frequency source that generates events more frequently than the interval we want to measure - any other notion of time is purely an abstract concept - and there is nothing faster than a Planck-frequency oscillator. (I'm told there may actually be even shorter time intervals in the field of quantum gravity, but they are apparently impossible to measure; what this might mean is left as an exercise to the reader.)

(Snapshot of an oscilloscope on a 10MHz oscillator with a cesium atomic resonator.)

I didn't come to this notion by reading about the more esoteric aspects of physics (as much as I enjoy doing that). I did it by developing and debugging real-time firmware that shaped the emission rate of ATM cells on a SONET channel carried over an OC-3 optical fiber. By building a stratum-0 NTP server with a cesium reference oscillator. By assembling an educational model of a mechanical clock.

(Ytterbium lattice optical atomic clock at the NIST Boulder Labs.)

Tuesday, September 18, 2018

We have met the enemy, and he is us.

One of the side effects of having five GPS-disciplined NTP servers in your home - three home-brew, two commercial - is that you become sensitized to issues with the Global Positioning System.

The other day I was sitting at my desk in my home office looking at cat memes doing some bleeding edge research and development, when out of the corner of my eye I noticed that the GPS lock LED on the home-built clock on the right side of my desk wasn't blinking. I ssh-ed into it, poked around, and verified that all the software was running; the problem was with its GPS receiver. Then I noticed that the home-built clock on the left side of my desk has just lost GPS sync too.

I whipped my Herman Miller Aeron chair around to look at the two small commercial units on my lab bench. The 1PPS LED on the Time Machines TM 1000A had stopped blinking. While I was trying to wrap my poor old head around that, the tiny color LCD display on the Leo Bodnar Electronics LeoNTP right next to it lit up with a red warning message about GPS lock being lost.

My first inclination was to go down to the basement to prepare for the coming apocalypse. Instead, I exercised some rare (for me) restraint and sent a query to Time Nuts - a mailing list for folks even more obsessed with precision timing than I am (they do exist).

In short order, Graham in Austin Texas kindly pointed me to the FAA web site where one can look up NOTAMs, notices of issues possibly affecting aviation and pilots, one of the categories of which is outages in the Global Positioning System. Here's the specific NOTAM he pointed me to.
ZDV   DENVER (ARTCC),CO. [Back to Top] !GPS 08/260 (KZDV A0287/18) ZDV NAV GPS (WSMR GPS 18-20) (INCLUDING WAAS, GBAS, AND ADS-B) MAY NOT BE AVBL WI A 359NM RADIUS CENTERED AT 333345N1063840W (TCS054036) FL400-UNL, 311NM RADIUS AT FL250, 215NM RADIUS AT 10000FT, 223NM RADIUS AT 4000FT AGL, 169NM RADIUS AT 50FT AGL DLY 1830-2230 1809031830-1809082230
It took some fu on my part to decode it, but it wasn't that hard.

ZDV ARTCC is the Denver Air Route Traffic Control Center.

333345N1063840W is 33°33'45.0"N 106°38'40.0"W, the location at which the source of the GPS interference is centered, which is smack dab in the White Sands Missile Range in New Mexico. (For a good time, click on the Google Maps link I provided, drop into the satellite view, and drill down until you can see the parking lot where they parked their equipment.)

359NM is 359 nautical miles, an area which includes my home near Denver Colorado.

1809031830-1809082230 is 2018-09-03 18:30 UTC to 2018-09-08 22:30 UTC, which is the time window in which I noticed my clocks losing GPS.

GPS disruption has become enough of an problem that there is now a U.S. Coast Guard web site where you can report issues. Most of them appear to be either user error or product failures. But some of them are probably related to testing of deliberate GPS interference - either as a field tactic or to evaluate their ability to deal with it - by our own military. Or others.

Don't say I didn't warn you.

Monday, August 27, 2018

Practical Geolocation II

In Practical Geolocation I mentioned that I had ordered a GlobalSat BU-353W10 GPS receiver. Like most of the receivers I've tested, this device is a puck at the end of a USB cable. The puck contains all the active electronics including an amplified patch antenna.
N.B. If any of the images in this article appear funky, or if you just want to see a larger view, click on the image to be taken to another version. Or try the web version of the article which is accessible from the mobile version via a link at the bottom of my blog. I've noticed that the images in the mobile rendering of this article seem to tickle a bug in both Safari and Firefox on my iPhone, causing wackiness to ensue. This doesn't seem to be an issue on my iPad, or on my Mac. Your mileage may vary.

Like the Navlocate GR-803G I described in that previous article, the BU-353W10 is based on the Swiss-made U-Blox 8 chipset. U-Blox 8 has a number of advanced features I crave, like enhanced signal sensitivity, multiple RF stages, seventy-two channels, ensemble fixes based on both the U.S. GPS and the Russian GLONASS satellite constellations, and support for the proprietary UBX binary protocol. I've also had good experiences integrating and using earlier U-Blox chipsets board-mounted in prior embedded projects.

The BU-353W10 is a few dollars more expensive than the GR-803G, but is available from for US$45 with two-day shipping, where as I ordered the GR-803G from eBay and it was shipped from China.

The BU-353W10 is the third in a series of GlobalSat (formerly USGlobalSat) devices, and those models, the BU-353S4 and BU-353S4-5Hz, both based on the SiRF Star IV chipset, have worked flawlessly. (SiRF is now owned by Qualcomm.)

All of this made me kindly disposed towards this new GlobalSat device. What gave me pause regarding the BU-353W10 is all the warnings on both and on the GlobalSat web site about how the devices was specific to Windows 10 and not supported on MacOS or Linux. Even its model designation had a "W10" in its name. So I anticipated having a bit of a mystery to solve.

Since I'm not writing a detective novel, I'll just jump to the conclusion: the BU-353W10 worked just fine with my Hazer software. I haven't tested it with anything else, but I would expect it to work fine with the GPSd and Lady Heather open source tools I mentioned in that prior article, at least on a Linux host. I wondered what exactly Windows 10 required of its GPS receivers, but some web searching hasn't enlightened me in that respect. But I took a conservative approach to reverse engineering the BU-353W10, which I thought someone might find useful for the next under-documented GPS receiver that comes along.

I'm typically wary of new USB devices. So the first thing I did was plug the BU-353W10 into a USB port on a Raspberry Pi - a system whose entire microSD card I could easily reformat and reload with a new OS should the worse case scenario occur - and carefully watched the system log.

GlobalSat BU-353W10 syslog

The device enumerated on the USB bus, and its vendor and product identifiers, 1546 and 01a8 respectively, were exactly what I expected from the U-Blox 8 chip, and were the same as those reported by the enumeration of the GR-803G.

Like that earlier device, the BU-353W10 instantiates a /dev/ttyACM device. Many of the USB GPS devices I've tested instead instantiate as a /dev/ttyUSB device.

BU-353W10 dev

The latter is intended to represent a UART-over-USB device, while the Abstract Control Module (ACM) is more typically intended to be a modem-over-USB. I'm told that the reason many devices appear as ACM devices is that it's a simpler interface, and may place less requirements on the host computer. Other than the device name, I haven't had to make any changes to using either type of device in my Hazer software.

You will notice that the standard behavior is for the /dev/ttyACM0 device to only be usable by user root or members of group dialout. There are several ways to address this. The worst choice would be to run all your applications as root (but lots of embedded Linux projects do exactly that). The best would probably be to alter the rules in /etc/udev/rules.d to change the owner, group, and permissions of the /dev/ttyACM device to something more appropriate when the BU-353W10 enumerates as v1546p01a8 on the USB bus. But I chose instead to add my user, pi in this case, to the dialout group (something I had already done long ago).

BU-353W10 dialout

I could have next just fired up Hazer's gpstool. In retrospect, that would have worked. But while gpstool can log a lot of stuff, it ignores anything its NMEA and UBX state machines do not recognize. Since I was still suspicious of the device, I chose instead to fire up some tools from my Diminuto library that I find useful for reverse engineering serial-port-like devices: serialtool, phex, and dump.

serialtool is a Swiss Army-knife for serial devices. It supports several different kind of loopback tests, but in its most basic use it simply allows you to set the serial port parameters (including modem control) however you see fit, read from the device and write to standard output, and read from standard input and write to the device. serialtool would tell me anything and everything that the BU-353W10 was emitting.

phex (pronounced "fex") reads from standard input and emits whatever it finds to standard output, expanding any non-printable characters to ANSI C-style escape sequences, and handling the wrapping of the screen to whatever width you specify (defaulting, as usual, to eighty, in a continuing tribute to our punch card days).

For devices that produce mostly non-printable output, phex output is a little busy. dump produces a hexadecimal dump along with printable characters that will seem familiar to a lot of old timers.

Here is a snapshot of serialtool used with phex.

BU-353W10 phex

I didn't see anything untoward: typical NMEA sentences.

Here is a snapshot of serialtool used with dump.

BU-353W10 dump 1

Again, nothing unexpected: printable NMEA sentences terminated by a carriage return and a line feed.

Which you find more readable, phex or dump, will depend on the output of the device you are examining, and maybe what you're used to seeing in your own development efforts.
You will have already realized that these tools aren't specific to GPS. I developed them as part of Diminuto long ago for my embedded Linux reverse engineering, integration, and troubleshooting toolkit. The base functionality of these tools are C functions in the Diminuto library, so they can be called from other applications as well, as we'll see with gpstool below. Putting most of the heavy-lifting in a library, and building a relatively simple command line tool around it, facilitates testing by placing the business logic in the library - where it can be exercised by standalone unit test programs - and the user interface in the command line tool - where it can be used from scripts as a functional test. This has been my preferred development pattern in this domain for a long time.
Next step was to use the Hazer ublox8 functional test script. Since the BU-353W10 uses the U-Blox 8 chipset, we would expect this script, which talks to any U-Blox 8 device, to work. The script not only logs all of the output of the device, it sends binary UBX commands to the device to enable it to periodically emit binary UBX packets with additional and more detailed information than can be had just using the ubiquitous NMEA standard output. The script, which is implemented using gpstool, logs all of the input to and output from the device in phex-style format, including the binary UBX packets. (You can ask gpstool to emit UBX packets read from the device in dump-format as well if that's your preference.)

BU-353W10 ublox8

I let this run for a while and didn't see any complaints from gpstool.

The last step was to create and run a new bu353w10 functional test script... which, as it turns out, is actually identical to the gn803g functional test script. I did in fact try the gn803g script first and verified that it worked, before creating a new script specific to the BU-353W10. These scripts use the full screen feature of gpstool which uses ANSI escape sequences, and some output formatting trickery, to create a dynamically updating display.

BU-353W10 bu353w10

Here's the first time we notice something interesting. At the end of every line produced in this format is a timer value that tells you how long the data displayed has until it is considered stale and its output will be suppressed. The GR-803G GPS receiver updates the satellite view, reported by the NMEA GSV sentence, every second, so for that device this lifetime value sticks at the maximum of ten seconds I specified on the gpstool command line in the gr803g script.

But here, the timer decrements in the bu353w10 script's output until the BU-353W10 refreshes it by emitting more GSV sentences, apparently every five seconds. That's completely adequate for my purposes, but it is a difference between the GR-803G and the BU-353W10, two devices that otherwise seem pretty similar. I haven't tried it, but you should be able to use gpstool to send UBX commands to either device to change the frequency at which they emit GSV sentences. (Yeah, you totally can; see below.)

I also noticed that the GR-803G emits the NMEA VTG sentence, providing course over ground (COG) true bearings in decimal degrees, while the BU-353W10 does not. I did this by using gpstool to collect a minute of output, and then post processing the resulting data to find all the unique sentences generated. This is a lot simpler than it sounds.

gpstool -D /dev/ttyACM0 -b 9600 -8 -n -1 -L bu353w10.dat -v
# Wait for a minute and then control-C out of the program.
awk -F, '{print $1;}' < bu353w10.dat | sort | uniq

You can compute COG yourself from the differences in successive position fixes. It is also possible that you can use gpstool to send a UBX command to the BU-353W10 to enable VTG output; I haven't tried it (yet). (No, wait: I did; see below.)

I walked into this little project not knowing whether I'd be spending a morning or a few days getting the BU-353W10 to work. Or maybe it would never work. That's typical of the kind of tasks I am called upon to do. As it turns out, this task was almost a no brainer. Despite all the warnings regarding the support (or lack of it) of the BU-353W10, it was a simple matter to integrate it into Hazer. I wouldn't expect doing something similar with GPSd would be that different. But it was a good example of the kinds of tools I can bring to bear on learning how a new device works just minutes after unboxing it.

Update (2018-08-27)

You can easily alter the frequency of the GSV sentences and enable the emission of the VTG sentence just by adding a couple of -W command line parameters to gpstool to request a configuration change to the U-Blox 8 chip using the proprietary (but printable) $PUBX message.

gpstool -D /dev/ttyACM0 -b 9600 -8 -n -1 -E -t 10 \
    -W '$PUBX,40,GSV,0,0,0,1,0,0' \
    -W '$PUBX,40,VTG,0,0,0,1,0,0'

I've added those parameters to the bu353w10 functional test script and verified it by capturing the output data as described above.

BU-353W10 bu353w10 2

Friday, August 24, 2018

Practical Geolocation

Geolocation, via the Global Positioning System (GPS) or other satellite constellations, keeps cropping up in my line of work, whether I'm working on software for a cellular base station or an in-flight entertainment system for business aircraft. This won't come as a surprise to anyone. Nowadays we are all depending on smartphone apps like Google Maps or the navigation system in our vehicle dashboard to get us from place to place. And even if we somehow know where we're going without a vast infrastructure of global navigation satellite systems, mobile radio telecommunications, and Earth mapping from space, to help us, we're still relying on GPS for other services like precision timing, whether we realize it or not.

The good news is that it's never been easier to make use of what was once an exotic space-based technology available only to the military. As I have enumerated in the past, there is a slew of inexpensive, easily available, and perfectly serviceable GPS receivers, that can be straightforwardly integrated into your embedded application, via USB, serial port, or even wirelessly via Bluetooth. In this article, I'll reiterate the units I've found the most useful, and why, and the tools I've installed or developed to make use of them.


GlobalSat BU-353S4

USGlobalSat BU-353S4

The best thing about the BU-353S4 is that it's easily available: US$30 and change from, a few bucks more for two day shipping if you're really desperate. It uses the well regarded SiRF Star IV GPS chipset, has the ubiquitous Prolific chip as its serial-to-USB converter, runs at a modest 4800 baud (useable with the finicky real-time GPS feature of Google Earth Pro), and provides a position update once every second. It has forty-eight radio channels, but only one RF stage, so it only receives GPS (versus receiving both the U.S. GPS and the Russian GLONASS constellations).

If it weren't for the special features of the other receivers I'll describe below, the BU-353S4 might be the only GPS receiver I'd ever need. There is a similar model that reports five times a second, but you're going to pay significantly more for something you probably don't need unless, maybe, you are using it in an aircraft.

NaviSys Technology GR-701W

NaviSys Technology GR-701W

The key feature of the GR-701W that is rare amongst inexpensive GPS receivers is that it exports a one pulse per second (1PPS) timing signal via the Data Carrier Detect (DCD) line that is visible to software even over the USB interface. The 1PPS signal is syntonized to the GPS timing signal that is in turn syntonized to the network of atomic clocks in the Global Positioning System. While the USB interface jitters the 1PPS a bit, you can still build a completely serviceable GPS-disiplined stratum-1 Network Time Protocol (NTP) micro-server using not much more than the GR-701W, a Raspberry Pi, and some open source software.

For just geolocation applications, you can ignore the 1PPS, and you have a GPS receiver that is based on the excellent Swiss-made U-blox 7 chipset, also uses the Prolific serial-to-USB converter, runs at 9600 baud, and delivers an update once per second. The receiver has fifty-six radio channels but still just one RF stage.

I have ordered my GR-701W units for US$50 from a seller on Etsy who, as it turns out, is the project manager for the open source NTPsec project; I've used the NTPsec NTP daemon in a number of projects, including my own Cesium atomic clock.



I keep a GN-803G in my geolocation kit because it is the first relatively inexpensive USB GPS receiver I found that has multiple RF stages, so it receives and processes signals from both the U.S. GPS constellation and the Russian GLONASS constellation simultaneously. In fact, it computes an ensemble fix, using a mixture of satellites from both constellations, which should allow it to exploit the dynamic orbital geometry of both systems to maximize accuracy by minimizing the Dilution Of Precision (DOP), a measure of accuracy based on the spatial separation of the satellites: broader separation, resulting in lower DOP values, is better.

The GN-803G uses the advanced U-Blox 8 chipset, which natively provides a USB interface, runs at 9600 baud, and updates by default once per second. Like the U-blox 7 chipset used by the GR-701W above, the U-Blox 8 chipset supports the proprietary binary UBX protocol in addition to the standard ASCII NMEA protocol that is ubiquitous among GPS receivers. I have used my own tools to send UBX packets to the GR-701W to enable it to generate periodic UBX packets containing much more detailed information than is available via NMEA. This alone makes the GN-803G of interest to geolocation and precision timing experimenters.

The downside is that I have only found the GN-803G on eBay, shipping from China, albeit for a paltry US$25; it can take a while to get one. I've recently discovered the GlobalSat BU-353W10 - US$45 from - that, like the GN-803G, uses the U-Blox 8 chipset; I'll find out shortly whether it's a usable alternative to the GN-803G.

(2018-08-27: I did, and it is; see Practical Geolocation II.)
N.B. I do have a twinge of concern from time to time about ordering a USB device from who-knows-where and plugging it into one of my computers. I tend to first plug them into a Raspberry Pi and then carefully watch the system log.
Garmin GLO

Garmin GLO Bluetooth GPS Receiver

I include the Garmin GLO - a battery-operated GPS receiver that connects via Bluetooth - because it solves a problem that the USB-based receivers do not: I can easily use it with my Pixel C tablet. Most smart mobile devices come by GPS because of their cellular chipsets; WiFi-only devices like my Pixel C need a little help. Connecting the GLO, or any Bluetooth GPS receiver, to the Pixel C requires not just Bluetooth, but a Bluetooth GPS Android application that receives the NMEA sentences from the receiver wirelessly and forwards them via an internal "mock GPS" interface.

Garmin is pretty close mouthed about the chipset the GLO uses. But the device updates ten times per second, making it useful for speed daemons (and, I gather, private pilots). The GLO can be had from for about US$100.



The GPS daemon, a standard package available in all the usual Linux distributions like those based on Debian, includes not just software that reads and interprets NMEA sentences from multiple GPS devices concurrently, but a bunch of useful tools including both command-line and window-based clients. A snapshot of the xgps client is shown below.

gpsd client xgps

I've used GPSd in all of my GPS-disciplined timepieces, in conjunction with the NTPsec NTP daemon. It would be my go-to tool in any Linux-based production system needing geolocation or precision timing. I've never had to write my own client to the daemon (the NTPsec NTPd has a built-in interface), but I don't expect it would be hard to do so.

Lady Heather

Lady Heather is an open source software package used to monitor and evaluate GPS-disciplined frequency standards - that is, precision clocks that are disciplined to GPS time by a GPS receiver. It includes a flexible interface with a real-time display that provides a wealth of information - more than I currently understand - about the GPS receiver under test (but it sure is awesome to watch).


Of particular interest above is the map in the lower right that shows the positions over time of satellites used in the position fix. The large dark area at the top of the map is in the direction of the inside of my office. The rest of the map indicates satellites received through my office window. The other small dark spots suggest the position of obstructions like trees and buildings outside my office that block reception of satellites low on the horizon. I have found this map useful for GPS antenna placement.

I first used Lady Heather to test my NTP server based on a Chip-Scale Atomic Clock (CSAC). I've since stood up a Raspberry Pi with an LCD display and a GR-701W that sits on my desk, which uses Lady Heather to monitor the Global Positioning System, plus a script that uses tools in NTPsec to keep track of all six NTP servers running on my local network and compare them to the UTC(NIST) time that an ensemble of NTP servers at the U.S. National Institute of Standards and Technology are emitting.

("Lady Heather" is apparently a dominatrix that is a recurring character on the television series CSI: Crime Scene Investigation that takes place in Las Vegas. I've never watched CSI. I've been to Las Vegas many times, but have never checked out the CSI "ride" I've noticed at the MGM Grand resort. Maybe I'm missing something. Maybe next trip.)


Hazer, and an underlying library Diminuto, are my own C-based software tools that I've used to test and evaluate GPS receivers. I am fond of saying that I can only learn by doing. So when I wanted to really understand the stuff being emitted by GPS receivers and how to make use of it, I ended up writing my own code to deal with it. The result has turned out to be a useful toolkit.

Hazer is a library of functions that parse NMEA sentences and UBX packets. Because it was intended for embedded systems, it only uses library functions that are typically part of the standard C library (although I have only used it on Linux systems, so exactly how portable Hazer might actually be is open to debate). The Hazer distribution includes a suite of unit and functional tests, some of which make use of less typical Linux capabilities; these depend on my Diminuto library of Linux systems programming functions. Most of the functional tests make use of Hazer's gpstool, a sort of Swiss Army Knife for the Hazer library.

Here is a screen snapshot of gpstool running against a GN-803G.

GN803G and Hazer 8.0.0

The tool emits the latest NMEA sentence or UBX packet received from the device, the most recent sentence or packet transmitted to the device, the time and position information received from the device, and information about what satellites in which constellation were used to generate the solution, the quality of the solution, and information about each individual satellite currently being received (whether it contributed to the fix or not).

Each line has associated with it a timer that indicates when the information will expire and that is reset whenever the data associated with that line is updated; in this example I used a command line option to set the lifetime to ten seconds. This is done because although NMEA does a good job telling you what it is receiving, it isn't always good about telling you when it is no longer receiving something - for example, if the satellite lock is lost - which would place the current solution in doubt.

Each line also indicates from which satellite constellation that data was derived: GPS for the U.S. system, GLONASS for the Russian system, and GNSS (for Global Navigation Satellite System, the generic term for this capability) for an ensemble solution that includes data from more than one system.

gpstool can output data in a sequential log format, but the example above uses ANSI escape sequences to display data that is updated dynamically in a full screen format. It's a lot simpler than it sounds; the tool mostly uses some simple sequences to position the curser, erase the entire screen from there to the end, and then rewrite that entire part of the screen all at once. Thanks to a fast screen display, a persistence of vision effect, and some careful output formatting on my part, individual fields appears to update dynamically. Here is a video of about a minute of gpstool running in full screen mode.

I have found Hazer and gpstool useful for testing and evaluating GPS devices. I have also used it to integrate GPS devices in real-time with tools like Google Earth. For an example much simpler than the one I just cited, the second pair of numbers in the position line of gpstool

POS 39*47'39.07"N, 105*09'12.27"W   39.794186, -105.153411

has latitude and longitude in a decimal degree format that can be cut and pasted directly into either Google Earth or Google Maps.

Hazer has also been instrumental in my understanding how devices like the GR-803G compute and report ensemble fixes. For example, when the GR-803G reports active satellites for an ensemble fix, it emits two GSA sentences, both with the "talker" specified not as GPS or GLONASS but as the generic GNSS. This is ambiguous as to whether the satellites in both messages were used together to compute a position solution, or whether the second GSA message is an update/replacement to the first GSA message. It turns out it's the former. The satellites in each GSA message are all either GPS and WAAS satellites, or all GLONASS and WAAS satellites. Later versions of NMEA include an additional GSA field resolve this ambiguity. But on the GR-803G, Hazer infers this just from the satellite identifiers.

WAAS, for Wide Area Augmentation System, is a system devised by the U. S. Federal Aviation Administration to transmit additional corrective geolocation information from geosynchronous satellites like Inmarsat, based on measurements performed at fixed terrestrial GPS receivers at precisely known locations. Its purpose is to improve the accuracy of position fixes for commercial aircraft. This allowed the FAA to narrow the separation of "air lanes" used in commercial aviation in the United States, increasing the density of air traffic, and to provide accurate enough position fixes to be useful in take-off and landing.

WAAS is an example of a Satellite Based Augmentation System (SBAS). Many of the latest GPS chipsets are capable of receiving SBAS corrections from one or more systems. (Not too long ago on one flight, I happened to see a jet airliner zip by in the opposite direction so close I could almost see inside the cabin windows. I suddenly had a visceral appreciation for precision satellite navigation.)

I have tested Hazer with all the GPS devices I cited above, and many more.


You haz none. GPS receivers are available in a broad range of prices, capabilities, and hardware interfaces. There are all sorts of open source software packages available to make using them easy. Get your geolocation groove on.

Tuesday, July 31, 2018

We are all relying on GPS all the time whether we realize it or not.

On or around 2200 UTC on January 25 2016, what should have been a routine system administration task was being undertaken by the folks that manage the U.S. Department of Defense Global Positioning System (GPS) satellite constellation, formerly known as "Navstar". A GPS satellite identified as PRN 32 (its pseudo-random noise code number) or as SV 23 (its satellite vehicle number indicating its launch order) was being decommissioned. Parameters controlling how that satellite corrects from GPS time to Coordinated Universal Time (UTC) were being removed from a table that was sent as a routine update to all of the other GPS satellites.

But there was something special about SV 23. It was the first of the Block IIA generation of GPS satellites, launched on November 26, 1990. By virtue of its age - it was more than twenty-five years old - its SV index placed it in the lowest slot in the table. That tickled what I'm guessing was a Day One bug in the GPS software.

As a result, for nearly thirteen hours and forty-five minutes, until the problem was discovered and corrected, UTC time stamps transmitted by those satellites that had applied the update, and received by those GPS receivers that chose to use one of those satellites from whence to update its own tables in its own memory, were off by about 13.7 microseconds.

Doesn't sound like much, does it?

This event was described in the article "The World Economy Runs on GPS. It Needs a Backup Plan" [Paul Tullis,  Bloomberg Businessweek, 2018-07-25], and analyzed in detail by scientists at the U. S. Department of Commerce National Institute of Standards and Technology (NIST) in the paper "The effects of the January 2016 UTC offset anomaly on GPS-controlled clocks monitored by NIST" [Jian Yao et. al., Proceedings of the 2017 ION Precise Time and Time Interval Meeting, 2017-01-31]. The event tripped an alarm system at NIST designed to detect errors in the official NIST(UTC) time source - NIST being the official source for time and frequency in the United States - by comparing it to GPS; but when the alarm went off, it was GPS that had slipped.

Like all radio navigation systems, GPS relies on calculations with time for navigation. By computing its distance from a GPS satellite with an orbit known with very high accuracy, a GPS receiver knows that it is somewhere on a sphere whose radius is the distance between the satellite and the receiver. This distance is computed by the receiver by knowing the speed of light (with some adjustment for propagation delay in the atmosphere) and subtracting the timestamp received from a satellite from its own timestamp.

By doing this exact same calculation with another satellite, the receiver knows it is on the circle described by the intersection of two spheres. A third satellite reduces this to two points. A fourth satellite brings it to a single point.

But it's not exactly that simple: the clock in your GPS receiver (which for most of us, is our mobile phone) is nowhere near the same quality as the atomic clocks - cesium or rubidium clocks, rated for space flight - that is in every GPS satellite. And even if it were, it's not synchronized to GPS time, at least not the first time you turn it on.

So this solution for the intersecting spheres isn't a point; it's a volume. But by using a little math and a lot of compute cycles, your receiver can iteratively solve for your position by adjusting its clock in whatever direction makes this volume grow smaller. It continues to iterate, adjusting its clock, until it reaches the resolution of the GPS timestamps, a handful of nanoseconds. And at that point, two wondrous things have happened.

First, through this computation I just described known as trilateration, your GPS receiver now knows its position to within a few feet, because light travels about foot in a nanosecond.

Second, the cheap ass clock in your GPS receiver is now synchronized to GPS time. And by continuously recomputing the navigation solution, your receiver can be kept synchronized to GPS time, even as it drifts.

And it isn't just synchronized to GPS time; it is syntonized to GPS time: it is now a frequency source that is approximately in phase with the GPS atomic clocks. This is tantamount to getting every human being in the world to jump up and down at the same time.

But here's the thing: being off by 13.7 microseconds... that's 13700 nanoseconds (actually, it was 13696.03 nanoseconds, as it turns out). That's about a 13700 foot navigation error. That's over two and a half miles.

Okay, that's serious.

Well, in this particular case, not really, at least not for those that rely on GPS just for geolocation: the error was in the adjustment from GPS time (which is used for navigation) to UTC time (which is what our clocks care about). The GPS timestamps were unaffected, but the UTC time had slipped. That's why the alarm at NIST went off.

Imagine what would have hit the fan if the GPS timestamps had been off by that margin.

But GPS isn't just about navigation. Because GPS is usually such a reliable source of precision time and frequency, any system or application that relies on precise time or frequency now typically uses an inexpensive GPS receiver to serve as a time and frequency source. There was a time when the major telecommunication carriers like AT&T had their own atomic clocks used to provide network synchronization. But today, sitting here at the Palatial Overclock Estate, I have five precision time and frequency sources on my home network, in the form of GPS-disciplined clocks, with their GPS antennas sitting in windows, peering at the sky. Commercial atomic clocks cost tens of thousands of dollars; GPS receivers are tens of dollars; GPS-disciplined clocks, hundreds of dollars. Today, GPS is the common source for precision time and frequency.

So what relies on GPS for precision time and frequency, or for geolocation?

Everything you care about.

The internet. The mobile telephone network. Emergency communication systems. Radio and television broadcasters. Electrical utilities. Cable television. The banking system and stock exchanges (because the order of transactions depends on each being labeled with a highly precise timestamp). Aircraft. Advanced weapons systems.
"The U. S. Department of Homeland Security has designated 16 sectors of infrastructure as 'critical', and 14 of them depend on GPS." [Tullis]
It isn't just failures in the GPS system due to bugs or innocent mistakes. GPS can be hacked, spoofed, and trivially jammed. In some cases, with just a couple hundred bucks of commodity parts, a little ingenuity, and some open source software.

There is currently no backup to GPS. The Russians have their own global navigation satellite system - called GLONASS - with global coverage. But it is just as prone to failure, with or without malicious intent, as the U. S. GPS system. There has been talk about reviving Long Range Navigation (LORAN), the post-WWII era ground-based radio system that used hyperbolic navigation, that GPS replaced. LORAN transmitters are defensible, more powerful, more easily repairable, and less easily jammed. But that is at best a long-term (and expensive) solution. And it's not clear to me that it solves the time and frequency distribution need. Folks are working on a sort of GPS firewall that aims to detect when GPS signals are being spoofed. But we are a long way from having that sort of capability in our mobile phones. And some solutions require that you have an atomic clock on site as a backup for when GPS is unavailable. I'm probably the only person you know that has a cesium atomic clock in his living room.

I used to watch the television series The Walking Dead. The other day it occurred to me that its portrayal of an apocalyptic zombie-plague wasn't a bad metaphor for a suddenly GPS-denied world.

Thursday, July 19, 2018

When the Silicon Meets the Road

Test what you fly; fly what you test.
-- NASA aphorism

When you are responsible for maintaining a library of reusable software that contains components that deal with honest to goodness hardware peripherals, most or all of which don't exist on your build server, how do you unit test it? As an embedded developer with decades of experience under my ever lengthening belt, I deal with this quandary often. I've worked on projects that had a vast infrastructure to simulate the underlying hardware platform; maintaining that infrastructure was its own product development effort with its own unit testing issues. I've worked on projects that had part of a sizable test organization dedicated just to testing the software on development lab bench mules that were originally hardware prototypes. I've worked on projects that had no good long term approach. You probably have too.

One of the problems with any approach is the constant economic pressure not to maintain whatever test infrastructure existed once the project gets past one or two product releases and management turned its sights onto the next shiny new revenue producing thing. When it becomes time to fix some bugs and do a new release of the legacy product, the new engineer on the project - almost inevitably it is the new engineer on the project, sometimes a junior engineer tasked with proving themselves, in some group that might be euphemistically called something like "sustaining engineering" - is now faced with having to figure out all over again how to test their changes, on software they aren't familiar with.

I had to deal with this issue writ small when working on Diminuto, an open source (LGPL) library of C functions that I have been developing over the span of more than a decade. It is my go-to systems programming toolkit. These days it’s hosted on GitHub as com-diag-diminuto, but it's been around long enough to have been maintained using several different version control systems. It started out in 2008 as a collection of supporting code for a tiny (hence the name) ARMv4 embedded project using Buildroot, with a stripped down Linux kernel, uClibc, BusyBox, and not much else. The project pre-dates the existence of the Raspberry Pi, and even the BeagleBoard.

Over time I kept expanding Diminuto as my needs grew, and porting it to new - and generally less expensive yet more powerful - platforms as they became available, as well as to new Linux releases as they arose. Eventually, all or parts of Diminuto ended up inside a handful of shipping products that I helped my clients develop. While I’ve done time in Python, wrote hundreds of thousands of lines of embedded C++ using the STL, fielded loads of Bash scripts, and even hacked JavaScript as the need arose, most of my paying gigs continue to be lower level systems work in C, writing device drivers, daemons, utilities, and glue code that holds all the higher level stuff together that's written by application and user interface developers. Diminuto also provides the infrastructure for a bunch of my other personal projects, most of which are also hosted on GitHub.
(Added 2018-07-20) An issue with maintaining software libraries of reusable code intended for systems programming and embedded applications across multiple products is that the library is architecturally divorced from any one specific product. So while you may maintain a legacy product in a test lab for unit and functional testing, it may not be adequate to test all the features in a library because the product doesn't necessarily use all those features. So to really test a new library release, you might have to corral several otherwise unrelated test mules, if that's even possible. And even that might not be sufficient for acceptable test coverage. One reason this doesn't crop up more often - in my experience anyway - is that companies don't seem to see the value in such libraries, unless they come from somewhere else (e.g. open source). I suppose that's because, again, of the cost of maintaining them. That's another reason for Diminuto: I got tired of writing and debugging and testing and documenting the same proprietary closed source code over and over again (although, you know, paid by the hour) for different clients. Or, remarkably, sometimes for the same client, but that's a story for another time. And so, some or all of Diminuto now ships in several different products produced by completely unrelated organizations.
Diminuto has a bunch of modules, what I call features, that are designed to work together.

Some features are not much more than preprocessor macros, for example:
  • Critical Section (scoped POSIX thread mutex serialization);
  • Coherent Section (scoped acquire/release memory barriers);
  • Serialized Section (scoped spin locks); and
  • Uninterruptible Section (scoped blocked signals).
Some provide simpler interfaces to inherently complicated stuff:
  • IPC4 and
  • IPC6 (IPv4 and IPv6 sockets); and
  • Mux (multiplexing using the select(2) system call).
Some provide convenience interfaces that combine several operations into a single function call, sometimes atomically to make them thread safe:
  • I2C (I2C bus);
  • Log (logging API that works in kernel space or in user space, and which automatically directs log messages to the system log for daemons, or to standard error for applications);
  • Pin (general purpose I/O using the /sys file system GPIO interface);
  • Serial (serial port configuration).
Some implement interfaces that are more consistent and mutually interoperable than the native POSIX and Linux capabilities:
  • Frequency,
  • Time,
  • Delay, and
  • Timer (the usual time-related stuff but all using the same units of time).
Some implement functionality that is a bit complex in and of itself:
  • Modulator (software pulse width modulation or PWM using POSIX interval timers);
  • Controller (proportional/integral/derivative or PID controller);
  • Shaper (traffic shaping using a virtual scheduler); and
  • Tree (red-black tree).
Some are just useful to have:
  • Phex, pronounced "fex" (print non-printable characters); and
  • Dump (print a formatted dump of selected memory).
Having this collection of documented, pre-tested, reliable functions that handle the heavy lifting of the POSIX and Linux APIs that I routinely am called upon to use means I can rapidly toss together a usable working piece of C code without having to worry about whether I did the conversion between microseconds and nanoseconds for two different POSIX calls correctly.

Virtually all of the Diminuto features have unit tests that verify the correctness of the implementation. These unit tests are part of the Diminuto repository, and like the library itself, I would expect them to build and run on any modern Linux distribution on any processor architecture.

I'm a big believer in unit tests. But some of these features, like Pin, Serial, Modulator, and Controller, can only really be adequately tested using functional tests on actual peripheral hardware. Over the years, to test these features, I’ve built a series of hardware test fixtures. These range from simple custom wired connectors, to breadboards with ICs on them. When I work on these features, I pull the appropriate fixture out of a box, hook it up to the system under test (typically a Raspberry Pi), and run the functional test.


Why is this important? Because I want to know my generically-useful but hardware-related features work before I (or anyone using my library) deploy them in an actual product development effort. And if for some reason they don’t work in the project, I want to be able to back up and use my functional tests to verify basic sanity, and to help me see where the problem might actually be. Even if the bug turns out to be in my code, the functional tests at least help me determine what does work and indict what doesn’t work. The functional tests also serve as a living example of how I intend the Diminuto features to be used.

Here are a couple of CableMax USB-to-serial adapters, one with a hand-wired loopback, the other with a commercial loopback adapter. These make use of an FTDI USB-to-serial chip, which is pretty much the only brand I use these days for this type of device.


I use these to test the Serial feature and its ability to set baud rate, data bits, and stop bits using the lbktest functional test.

Here is a NaviSys GR-701W USB GPS dongle that supports one pulse per second (1PPS) signaling using the data carrier detect (DCD) modem control line.

NaviSys Technology GR-701W

I use it to test the Serial feature DCD support by reading NMEA sentences from the GPS receiver using the dcdtest functional test. As fringe as it may seem, I have several other projects, like com-diag-hazer and its own dependents, that rely specifically on this feature. It pays to verify its functionality before any regressions creep outside of Diminuto proper. Which is really the point of all the functional and unit tests.

Here are more two CableMax USB-to-serial adapters connected back to back with a null modem adapter in between.


I also use these to test the Serial feature, either between computers or even on the same computer using two USB ports, using Diminuto's serialtool utility.

Here is what my latest functional test breadboard looks like.

Diminuto Hardware Test Fixture

It consists of a Uctronics expansion board that connects the breadboard to the Raspberry Pi via a ribbon cable; four LEDs with built in resistors; two momentary contact buttons, one active high, the other active low with a pull up resistor; and an Avago APDS9301 ambient light sensor with an I2C interface. I also bring out the pins to the hardware console port on the Raspberry Pi.

The pintest functional test, based on the Diminuto's pintool utility, uses Mux and Pin to read the buttons and to write patterns to the LEDs. Pin, Mux, and the underlying Raspberry Pi GPIO controller, supports multiplexing GPIO pins using select(2).

The pwmrheostat functional test uses Pin and Modulator to control as many as four LEDs concurrently, all at different brightness levels.

The luxrheostat functional test uses Pin, Mux, Modulator, and I2C to control a single LED pointed at the ambient light sensor, turning the LED brightness up and down, while reading the light level.

The luxcontroller (formerly pidtest) functional test uses Modulator, Mux, Pin, and I2C to control the brightness of an LED and read its intensity on an ambient light sensor, and Controller to maintain a specified light level as the background illumination changes.

(I am in the process of adding a TI ADS1115 analog to digital converter or ADC, also with an I2C interface, to this breadboard to extend the testing of the Modulator software PWM feature and the Controller PID feature. I have a first cut at a adcrheostat and adccontroller functional tests.)

Here is a FTDI TTL-232R-3V3 USB-to-serial adapter that works with 3.3 volt logic-level signals, with logic clips at the end of the signal wires.


I use this to further test the Serial feature using the Raspberry Pi hardware console port that is accessible via the breadboard.

These test fixtures are pretty simple stuff. But they allow me to exercise the hardware-related features of Diminuto such that I have high confidence that I haven't done something boneheaded. When I'm not using them, these fixtures go back into the box and go up on the shelf.

When I'm thinking of adding another hardware-centric feature to Diminuto, one of the first things I decide is how I am going to test it: if I can do so with an existing fixture; if I need to add to an existing feature like the breadboard; if I need to build a new fixture; and how much that's going to cost. Sometimes I decide the cost isn't worth it, and forgo developing the feature in Diminuto at all, leaving it to a future client to pay for and maintain if its needed. Or maybe I just wait for technology to catch up.

Test what you ship; ship what you test.
-- Chip Overclock aphorism

Updated 2018-07-25

Here's a photograph of the breadboard after I added the ADC. It's getting complicated enough that I probably should actually generate an official schematic just for my own records if nothing else.


The adcrheostat and adccontroller functional tests now use Pin and Modulator to do PWM on a GPIO pin, and I2C to read the voltage on the pin from the ADC (the tiny blue board). The latter test uses Controller to implement a PID controller that strives to maintain a specified voltage. These tests are a minor variation on how luxrheostat and luxcontroller use instead an LED and an ambient light sensor (the tiny red board).

Tuesday, June 19, 2018

Clock Club

The first rule of Clock Club is: you cannot stop talking about Clock Club. 
Last week I was privileged to spend four days attending the 43rd Annual Time & Frequency Metrology Seminar at the National Institute of Standards and Technology at their laboratories in Boulder Colorado. NIST is one of the premier scientific and technology standards organizations in the world (they were formerly the National Bureau of Standards), and continually produces bleeding edge breakthroughs, many of which end up becoming commercialized into mainstream technology that changes our lives for the better.

Here are some Fun Facts To Know And Tell on the material presented by NIST scientists, and some photos of stuff I saw. Any bone headed remarks are strictly my fault, and are probably the result of my being just a humble software developer instead of a research physicist or an electrical engineer, or maybe just not taking good notes.

My electrical engineer and physicist friends would certainly have gotten even more out of this seminar than I did. Most of the people there were EEs or physicists, from other national labs, other time standards organizations, from commercial atomic clock manufacturers, etc. For example: one guy from the National Physics Laboratory (NPL), the U.K. equivalent to NIST; a woman who was a lieutenant in the Spanish navy (had served on a frigate) now working at Spain's Naval Observatory (which has the same role as the U.S. Naval Observatory, which provides the master time reference for the U.S. military, and is a reminder that our definition of time is central to navigation at sea and is still in part in the province of astronomers); a guy who worked for the Canadian Department of National Defense (equivalent to the civil service portion of the U.S. Department of Defense) in the organization that is responsible for instrument testing and quality, etc.

Oh, and some guys whose badges listed no organization, but wrote "DOD" on a sign up sheet, and told me they were from "Maryland". Past experience tells me they work for an intelligence agency. This is not an unusual encounter in my line of work; it happened all the time when I attended conferences while employed at the National Center for Atmospheric Research due to our common interests in high performance computing and mass storage systems. The pink I. M. Pei-designed NCAR Mesa Laboratory where I worked is barely visible in the photograph below in the distance above and to the right of the NIST Building 1 where the seminar was held.


The phrase I learned that I will be most likely to drop into conversations in the future: "clock trip". I knew this was done, but I didn't know this is what it was called: you synchronize/syntonize/phase-lock a rack-mounted commercial atomic clock, running on a big battery pack, to an atomic clock at one laboratory, then you put it on a cart/truck/plane/ship/etc. and take it to another laboratory, maybe far away, where you compare it to another atomic clock. This is old school, but it still done from time to time today, since it yields the best results. Mostly, "time transfer", as this procedure is generically known, is also done over dark fiber, geosynchronous satellites, or, most typically today, GPS. Everyone now compares their atomic clocks to GPS Time (GPST), which is synced ultimately to International Atomic Time (TAI).

NIST generates UTC(NIST) time. About once a month or so, the International Bureau of Weights and Measures (BIPM) in Paris publishes an announcement of how far UTC(NIST), and every other "national" time standard, diverges from standard Universal Coordinated Time (UTC). But this is all done after the fact and only about once a month. UTC is ultimately based on the variable rotation of the Earth (hence: leap seconds), the orbit of the Earth around the Sun, and our planet's relationship to distant stars and quasars; it's determined by astronomers over a long span of time. So UTC isn't really a "real-time"... time. In the U.S., when we synchronize our clocks, it isn't really to UTC. It's probably to UTC(NIST). Or, maybe, UTC(USNO), produced by the U. S. Naval Observatory (USNO), particularly if we're in the military. Or, more realistically, GPST. Most of the clocks/NTP servers I've built are "disciplined" to GPST, adjusted to approximately UTC by adding leap seconds; this is what all the cool kids do these days.

Cesium atomic clocks are noisy in the short term (jitter) - so they are imprecise - but averaged over long durations they are extremely stable - so they are accurate. Hydrogen maser atomic clocks are extremely precise (very low short term noise) but are inaccurate - one scientist said using a hydrogen maser was a "black art" because you would never be exactly sure what extremely stable frequency you would actually get until you turned it on (weird). So NIST, USNO, and others use an ensemble of multiple commercial cesium (Cs) clocks, the long term average of which is used to servo the output of an oscillator that is locked to a hydrogen maser clock. Below is a photograph of an broken commercial hydrogen maser clock sitting in a hallway; new, they go for around a quarter million dollars U.S.


The only way to measure the quality of a clock is with another clock. This is just as problematic as it sounds, particularly since really good clocks are measurably affected by not just environmental noise like vibration, thermal noise, and even quantum noise, but also by special and general relativistic effects. We spent almost an entire day on measuring and characterizing phase noise in clocks, which is really all about measuring phase differences between a clock you trust, and one you don't, and then processing the raw data by computing an Allan Deviation (ADEV, or AVAR for the Allan Variance). Because the measurement of phase differences is a time series and not a population, the normal statistical methods don't apply. Below is a photograph of the equipment we used for a hands-on demonstration of measuring and characterizing phase differences. One of the carts contained a high-precision oven-controlled quartz oscillator that is kept running on an uninterruptible power supply so that it stays in its "sweet spot". One of them also contained an atomic clock in the form of a rubidium (Rb) oscillator.


The latest "optical" atomic clocks - so called because their resonant frequency is in the visible light range instead of the microwave range like cesium or rubidium atomic clocks - have frequencies so high they can't be measured directly because electronics can't run that fast. So they have to have "optical frequency combs" that produce a lower, measurable, frequency - 10MHz or even a low as 1Hz a.k.a. 1PPS - that is locked to the higher optical frequency. Optical atomic clocks, still in the experimental stage today, are likely to eventually replace cesium atomic clocks as the definition of the second in the International System of Units (SI). That's one reason why labs at NIST may contain awesome.


One of the optical clock labs was officially surveyed to determine its position within a millimeter or so. Because an optical atomic clock is so accurate, general relativistic effects are measurable if it’s moved just a few centimeters vertically from the Earths mass. The clock depends on measurements of less than the width of a hydrogen atom. There's an official Geodetic Survey marker embedded in the concrete lab floor.


A form of quantum noise is from virtual particles popping into existence and then disappearing due to fluctuations in the vacuum energy. This actually happens and is detectable in optical atomic clocks. Some of these clocks work by trapping *two* ions - one quantum entangled to another - in a magnetic trap and stimulating one and measuring the atomic transition of the other. Sometimes another atom of the same type will wink into existence for a very short time and then disappear. I'M NOT MAKING THIS UP. Below is a photograph of a running ytterbium (Yb) lattice optical atomic clock. Note that the lab bench of one of the most advanced experimental optical atomic clocks in existence looks more or less like my lab bench, BUT WITH LASERS.


(I observe that this idea of entangling two atoms, "exciting" one and "interrogating" the other, is pretty much the same reason that historically the most accurate mechanical pendulum clocks had two pendulums, one slaved to the other.)

The latest optical clocks are so accurate and precise that they are being used to probe the "constant-ness" of certain values in physics - like the dimensionless fine-structure constant - that we think are constant, but have no theory that says why they must be constant. As we continue to make things smaller and smaller, and faster and faster, the measurement of such values will matter more and more. One of the NIST experiments involves comparing two different implementations of optical clock-type technologies and making very fine measurements of any differences in their results that may be affected by variation in electric field strengths. In the photographs below, you can see the green versus the blue LASERs, denoting different atomic resonant frequencies at use.



Because we can measure time far more accurately - several orders of magnitude better - than any other physical unit of measure, we can expect other SI units to eventually be defined in terms of time whenever possible. So these technologies have been used by NIST to develop measurement standards for other physical units. Below is a photograph of a ten volt (10V) reference standard made up of an array of superconducting Josephson junctions on semiconductor wafer (left) placed in carrier (right) that goes in cryogenic chamber. It's accurate to maybe twelve significant digits. One wafer is worth about US$50,000.


This is used in the instrument used below to calibrate volt meters. Well, maybe not your voltmeter. NIST has built quite a few of these instruments and sold them to various labs here and abroad. You can vaguely see the small cryogenically cooled chamber behind the screen in the lower left of the rack. The noise of the compressor for the cooler was a constant thumping in the room.


I wore a mechanical wristwatch each of the four days of this conference. It just seemed appropriate. I wasn't the only one. Another guy and I compared oscillator frequencies. Mine was twice as fast as his. I have watches with 4, 6, and 8 Hz oscillators, and even a vintage "fast beat" watch with a 10 Hz oscillator. The one I was wearing that day, shown below, has an 8 Hz mechanical oscillator. Compare that to your everyday quartz wristwatch... that typically has a 32,768 Hz quartz oscillator. Conventional atomic clocks oscillate in the gigahertz (microwave) range, while optical atomic clocks oscillate in the terahertz (visible) range. Future clocks will be "nuclear clocks", oscillating in the petahertz to exahertz (x-ray) range, "ticking" via transitions in the nucleus of an atom. I think maybe NIST wins the oscillator frequency challenge.

Rolex Oyster Perpetual Milgauss Automatic Chronometer

A big Thank You to NIST and its scientists that participated in the seminar and who were so generous with their time and expertise. Because, you know, ultimately, it's all about time and frequency.

Monday, May 28, 2018

Time Is Precious

Earlier this month I was fortunate to be included on a tour of the time and frequency facilities at the Boulder Colorado laboratories of the National Institute of Standards and Technology (NIST). I got to walk right up to the F-2 cesium fountain atomic clock, which, along with the earlier F-1, is the standard frequency reference for the United States.

NIST F-2 Cesium Fountain Clock

I always thought the F-2 ran all the time. Fortunately that's not true, or else we might not have been able to see it. NIST fires it up periodically to calibrate an ensemble of commercial atomic clocks, which do run all the time, and which we didn't get to see.

I also got to see a couple of the prototypes of the chip-scale atomic clock (CSAC) developed as a result of NIST and DARPA research projects.

Prototype Chip Scale Atomic Clock


I used a commercialized version of this same device in the stratum-0 NTP server that I built.

Like me, you may have read the book From Sundials to Atomic Clocks: Understanding Time and Frequency by NIST physicist James Jespersen and Jane Fitz-Randolph. But did you know Jespersen was part of a team that won an Emmy award for the invention of close captioning?


Also: a four hundred pound quartz crystal. Just a little bit bigger than the one in your quartz wristwatch.


On display in a hallway was an IBM radio clock: it's a high precision electro-mechanical pendulum clock with a radio that allows it to set itself according to the NIST time code transmissions.


Speaking of which, it only seemed appropriate this morning that I take a little jaunt up to see the WWV (short-wave) and WWVB (long-wave) transmitter towers just north of Fort Collins Colorado.


This is from where a time code is transmitted to an estimated fifty million radio clocks, including the WWVB radio clock that I built, in the continental United States. The time code is synchronized to a cesium atomic clock on site, which in turn is synchronized to the NIST master atomic clocks in Boulder Colorado.

Tuesday, May 22, 2018

An Easy Home-Brew Stratum-1 GPS-Disciplined NTP Server

This here is my latest, and simplest, home brew, GPS-disciplined, NTP server: "Candleclock" a.k.a. "O-4". If you wanted to leave out the battery-backed-up real-time clock and the LCD display, which are really just convenience features, you could put one of these together on your lunch break out of a Raspberry Pi (here, a 3 B+)


a NaviSys GR-701W USB GPS receiver which supports 1PPS

NaviSys Technology GR-701W

and some open source software. (The guy that sells the GR-701W on Etsy is the project manager of the NTPsec open source project!) The completely optional beautiful clear plastic stand is a leaflet holder from the local office supply store.