GNSS clocks prove to be invisible and indispensable
In the early 19th century, as the sun moved across Britain from east to west, people set their clocks to local mean time, so that noon in Greenwich would occur about 16½ minutes before noon in Plymouth. Back then, travel on foot, by horse, or by coach was slow and inconvenient, so having to adjust their pocket watch, for the few who even had one, was the least of travelers’ concerns.
However, with the advent of railway travel, keeping track of time differences became confusing and impractical. In 1845, Henry Booth, a railway businessman involved with the Liverpool and Manchester Railway, petitioned parliament for a “Uniformity of Time,” arguing that when “the great bell of St. Paul’s strikes ONE, simultaneously, every City clock and Village chime, from John of Groat’s to the Land’s End, strikes ONE, also.”
In addition to rail travel, advances in industrialization and automation also increasingly required time standardization, synchronization, and optimization. With the advent of satellite navigation, the requirement for accurate time reached the order of nanoseconds, because a signal delay of one nanosecond corresponds to roughly one foot of distance on the ground. This is why atomic clocks were one of the enabling technologies for GPS.
In turn, atomic clocks on GNSS satellites became the most convenient way to calibrate and synchronize local clocks on the ground and to meet the stringent timing requirements of financial institutions, communication and broadcast networks, power utilities, transportation networks, weather radars, and a variety of scientific, commercial, military and consumer systems. Even though computer networks use PTP and other synchronization protocols, they all ultimately tie back to GNSS timing receivers to synchronize them to a global clock. This has made GNSS timing receivers ubiquitous and indispensable. Yet, the T in PNT (positioning, navigation, and timing) is invisible to most people and often an afterthought even for many of us in the industry.
I discussed some of the challenges of GNSS timing with representatives of five companies:
- Mark Tommey, sales director, Precise Time and Frequency
- Paul Skoog and Eric Colard, senior technical engineers of product marketing, Microchip, frequency and time systems business unit
- Jeff Gao, GM of communications, enterprise and data centers, SiTime
- Farrokh Farrokhi, founder and president, etherWhere
- Beacham Still, director of business development and operations lead, SyncWorks
For the full transcripts of my interviews for this article, visit here.
Positioning vs. timing
The first step in using GNSS signals for time synchronization is to process them to extract pseudoranges in the same way as for positioning — except that the signal from a single satellite is usually sufficient, because the position of the phase center of the receiver’s antenna is determined once and for all when it is installed.
However, most timing applications require much more accurate timing than positioning applications. “In GPS, let’s say that position accuracy is one meter with a clear view of the sky,” said Farrokhi. “That translates to a few nanoseconds of error. To achieve that over, say, a 24-hour cycle requires much tighter jitter on the receiver. So, the challenge for a timing application is to do a much better job of removing sources of errors compared to positioning. In the past, a requirement of 20 ns jitter in timing may have been enough for many applications. However, as the communication systems’ bandwidth and throughput increase, the requirement for timing becomes more stringent. We must come up with new algorithms and new architectures to reduce jitter and improve accuracy.”
Another difference is that most timing receivers — such as those in a cellular base station — are stationary and connected to an antenna with a clear view of the sky. “There are methods to extract and remove most uncertainties and inaccuracies,” said Farrokhi.
“Since it’s not moving, many satellites feed into the equations that help you solve the math to get you very accurate timing,” said Skoog.
”Finally, most GNSS positioning applications don’t require holdover, while for GNSS timing “holdover is a universal requirement,” said Gao, “ranging from four hours, for an edge data center or a small facility, all the way to 24 hours for a large cluster of servers or, in some extreme cases, even 48 to 72 hours for deployment in or near a hostile environment, where you expect jamming and all those bad things to happen.”
Accuracy requirements
The main critical applications for GNSS timing can be roughly grouped by the…