Real time synchronisation of a free-running atomic clock time base with UTC using GNSS signals for application in experimental physics

This paper demonstrates the first real-time application of a GNSS-based correction method to synchronize free-running Rubidium and Caesium atomic clocks with UTC, achieving a residual time difference within ±15 ns and eliminating apparent drift.

The Gist

The Big Picture: Keeping Time with a Master Clock

Imagine you are trying to coordinate a massive, global event where thousands of people need to clap their hands at the exact same millisecond. If everyone uses their own watch, some will be fast, some slow, and the result will be a mess.

In the world of particle physics (specifically for a giant experiment called Hyper-Kamiokande in Japan), scientists need to do something similar. They need to detect tiny particles (neutrinos) traveling hundreds of kilometers. To figure out exactly where and when these particles arrive, the clocks at the start of the journey and the end of the journey must be perfectly synchronized to UTC (Coordinated Universal Time), the world's official time.

The challenge? The clocks they use (Atomic Clocks) are incredibly precise, but they aren't perfect. Over time, they drift. A cheap clock might drift by a second in a year; a fancy one might drift by a second in a century. For this experiment, they can't afford even a tiny drift. They need to stay within 100 nanoseconds (that's one-billionth of a second) of the official time.

The Problem: The "Free-Running" Clock

Usually, scientists connect their clocks directly to a satellite signal (GPS) to keep them on time. But the authors of this paper wanted to try something different. They wanted to use a "free-running" atomic clock.

Think of this like a musician playing a solo. They are playing beautifully on their own, but they aren't listening to the conductor. If they drift off-key, they don't know it until it's too late.

The goal of this paper was to prove that you can let the clock play its own solo, but use a "conductor" (GPS signals) to whisper corrections to the musician in real-time, keeping them perfectly in sync without ever stopping the music.

The Solution: The "GPS Whisperer" Method

The team at a lab in Paris (LPNHE) set up an experiment to test this "whispering" method. Here is how they did it:

1. The Musicians (The Clocks): They used two types of atomic clocks:

   • The Budget Option: A Rubidium clock (like a reliable, affordable wristwatch). It tends to drift a bit faster and unpredictably.
   • The Luxury Option: A Caesium clock (like a high-end, expensive grandfather clock). It is incredibly stable and barely drifts.

2. The Conductor (The GPS): They had a GPS receiver on the roof of their building. This receiver constantly checks the "official time" from satellites.

3. The Conductor's Notes (The Correction):

   • Every 16 minutes, the GPS receiver measures the difference between the atomic clock and the satellite time.
   • A computer program (running on a laptop) looks at the last few measurements. It draws a straight line through them to predict: "Okay, the clock is drifting 5 nanoseconds per hour. In the next hour, it will be off by X amount."
   • The computer then calculates a "correction" and applies it to the clock's data instantly.

The Results: A Perfect Harmony

They ran this test for about two weeks with the Rubidium clock and nearly three months with the Caesium clock.

• Without the fix: The Rubidium clock would drift by 100 nanoseconds in just one day. The Caesium clock would take about two weeks to drift that far.
• With the fix: Both clocks stayed within ±15 nanoseconds of the official time.

The Analogy: Imagine you are walking down a hallway.

• The Clock: You are walking, but you have a slight limp that makes you veer left.
• The GPS: A friend standing on a balcony sees you veering.
• The Correction: Instead of stopping you to fix your leg, your friend shouts, "Take a tiny step right!" You adjust your step instantly. You keep walking forward without stopping, but you stay perfectly straight.

Why This Matters for Physics

This is a game-changer for experiments like Hyper-Kamiokande.

• Robustness: If the GPS signal gets blocked (like during a storm or if the antenna breaks), the system doesn't crash. The clock keeps running, and the computer just waits for the signal to come back to update the correction.
• Real-Time: They proved this works live. They didn't have to wait until the end of the experiment to fix the data. The data is correct the moment it is recorded.

The Catch (and the Fix)

There was one small hiccup. The computer takes a tiny fraction of a second to calculate the correction.

• The Rubidium Clock: Because it drifts so fast, the GPS receiver sometimes gets confused if the time difference gets too big (over 500 microseconds). It "jumps" to reset, which creates a glitch in the data. The team realized that for a 20-year experiment, the Rubidium clock might need a software update to nudge its frequency occasionally to prevent these jumps.
• The Caesium Clock: This clock is so stable that it would take hundreds of years to drift enough to cause a jump. For long-term experiments, this "luxury" clock is the safer bet.

The Bottom Line

The scientists proved that you don't need to constantly tie your atomic clock to a satellite to keep it accurate. You can let it run free, listen to the satellites occasionally, and apply a tiny, real-time correction.

It's like having a self-driving car that knows its own speed but occasionally checks a map to correct its course, ensuring it arrives at the destination with perfect timing, every single time. This method is now ready to help physicists catch neutrinos from across the universe with pinpoint accuracy.

Technical Summary

1. Problem Statement

In experimental particle physics, particularly in long-baseline neutrino experiments (e.g., Hyper-Kamiokande) and multi-messenger astrophysics, precise time synchronization to Coordinated Universal Time (UTC) is critical.

• Requirements: Experiments often require synchronization accuracy better than 100 ns to resolve specific event structures (e.g., neutrino spills with 600 ns bunch spacing).
• Current Limitations: Traditional methods discipline the master clock frequency directly to GNSS signals. However, this approach lacks flexibility and is vulnerable to temporary GNSS signal loss or receiver failures.
• The Challenge: The authors aim to validate a method where the atomic clock runs free-running (undisciplined), and the time stamps of recorded events are corrected in real-time using GNSS data. This offers greater robustness but requires a correction algorithm capable of handling clock drift without introducing significant latency or error.

2. Methodology

The study employs a correction method that extrapolates clock drift based on GNSS measurements, implemented within a real-time data acquisition framework.

Experimental Setup

• Location: Laboratoire de Physique Nucléaire et des Hautes Energies (LPNHE), Paris.
• Clocks Tested:
  1. Rubidium (Rb) Clock: SRS FS725 (low-cost, exhibits random walk and linear frequency drift).
  2. Caesium (Cs) Clock: Oscilloquartz OSA3235B (magnetic, high stability, no apparent frequency drift).
• Reference: UTC(OP) (French official realization of UTC) distributed via the T-REFIMEVE network using White Rabbit (WR) switches.
• GNSS System: Septentrio receiver with an antenna on the roof, providing time comparisons against the atomic clock.
• Data Acquisition: MIDAS software ecosystem managing front-ends for the frequency counter, GNSS receiver, and correction logic.

Correction Algorithm

1. Data Acquisition: The GNSS receiver measures the time difference between the atomic clock and GNSS time every 16 minutes (CGGTTS format).
2. Linear Fitting: The system performs a linear fit on the last $N$ measurements to determine the clock's drift rate (slope $s$) and offset ($o$) relative to UTC.
   • Optimization: The window size $N$ is tuned to the clock type.
     • For Rubidium: $N \approx 10\text{--}30$ (to avoid fitting over the random walk characteristic time).
     • For Caesium: $N = 100$ (leveraging the higher stability of the GNSS signal over longer integration times).
3. Real-Time Application:
   • A Python front-end updates the fit parameters whenever new GNSS data arrives.
   • A "Correction" front-end reads the current slope and offset from the database.
   • When a counter measurement ($t_{clock} - t_{UTC}$) is recorded, the correction $\Delta t = s \cdot D + o$ is applied immediately, where $D$ is the measurement date.
4. Implementation: The system runs on a standard laptop, introducing a processing delay of approximately 1 second, which is negligible for the physics application but introduces "dead time" at high event rates.

3. Key Contributions

• First Real-Time Validation: While the method was previously proven in post-processing (Ref. [3]), this work demonstrates its feasibility and efficiency in real-time (online) operation.
• Dual-Clock Comparison: The study validates the method on two distinct atomic clock technologies with different stability profiles (Rb vs. Cs), proving the algorithm's adaptability.
• Robustness Analysis: The paper addresses critical failure modes, specifically the GNSS receiver tolerance (±500 µs). It details how the system handles "1 ms jumps" in the receiver's PPS signal when the clock drift exceeds the receiver's tolerance, ensuring these artifacts do not corrupt the correction.
• Optimization for Long-Term Experiments: It highlights the trade-offs between using low-cost Rb clocks (requiring frequent frequency adjustments to prevent drift accumulation) versus high-stability Cs clocks (ideal for 20+ year experiments like Hyper-Kamiokande).

4. Results

• Synchronization Accuracy:
  • Both clocks achieved a residual difference from UTC(OP) within ±15 ns.
  • Standard Deviation: 2.8 ns for the Rubidium clock and 2.4 ns for the Caesium clock.
  • Drift: No apparent residual long-term drift was observed in the corrected signals.
• Stability (Allan Deviation):
  • Rubidium: The correction successfully stabilized the quadratic drift of the free-running clock.
  • Caesium: The correction improved long-term stability (averaging times > $8 \times 10^4$ s) by aligning the signal with the superior stability of the GNSS reference, overcoming the Cs clock's flicker noise limitations at long integration times.
• Performance Limits:
  • The Rubidium clock showed a 100 ns drift in ~1 day without correction.
  • The Caesium clock showed a 100 ns drift in ~14 days without correction.
  • The system successfully handled the 10-second measurement interval for Rb and 1-second interval for Cs, though the 1-second rate approached the processing limit of the current setup.

5. Significance

• Feasibility for Hyper-Kamiokande: The results confirm that the proposed method meets the <100 ns synchronization requirement for the Hyper-Kamiokande experiment's long-baseline program, which needs to open data-taking windows for neutrino spills arriving 295 km away.
• Operational Flexibility: By keeping the clock free-running, the system is more robust against GNSS outages. The clock continues to function accurately based on the last known drift parameters until GNSS signals are restored.
• Scalability: The method allows for the use of lower-cost atomic clocks (like Rubidium) in high-precision applications if managed with real-time correction, though the authors recommend the more stable Caesium clocks for multi-decade experiments to minimize the risk of GNSS receiver "jumps" and the need for manual frequency intervention.
• Future Optimization: The paper identifies that reducing the database I/O latency (e.g., using manalyzer tools) is necessary to support the high event rates (>50,000 events in seconds) expected during supernova neutrino bursts.

In conclusion, the paper successfully demonstrates a robust, real-time correction framework that enables free-running atomic clocks to maintain UTC synchronization at the nanosecond level, a critical enabler for next-generation particle physics and astrophysics experiments.