Every GNSS receiver faces the same two questions at startup: where am I, and what time is it? The second question matters far more than most people expect. A simple real-time clock, a component that costs almost nothing, can cut the time to first fix from a full minute down to just a few seconds.
Here is how that works.
The Basics: Fix, Ephemeris, and RTC
A fix means the receiver has calculated latitude, longitude, altitude, and its own clock error, which requires signals from at least four satellites.
To use those signals, the receiver needs the ephemeris: precise orbit data broadcast continuously by each satellite, used to compute a satellite’s position at a specific time. Downloading it takes about 30 seconds or more (depending upon reception), and it stays valid for roughly 2 to 4 hours before it must be re-downloaded.
The RTC (Real-Time Clock) keeps approximate time even when the device is off, running on a crystal oscillator with an optional backup battery. Unlike satellites with their atomic clocks, the RTC drifts slowly and does not stay synchronized; it is typically set once after a fix and drifts until the next one.
Why Time Is Everything in GNSS
GNSS positioning works by measuring signal travel time:
Distance = Speed of Light × Travel Time
At the speed of light, even tiny time errors translate into large distance errors. Beyond ranging, time is also what lets the receiver compute satellite positions from the ephemeris, predict Doppler shift, and reduce the signal search space.
Cold, Warm, and Hot Starts
How fast a receiver gets a fix depends on what it already knows at startup.
There are three startup types:
| Start type | RTC | Ephemeris | Search space | Time to first fix |
| Cold start | Not available | Not available | Large | 30 to 60 sec |
| Warm start | Valid | Expired | Medium | 10 to 30 sec |
| Hot start | Valid | Valid | Small | 1 to 5 sec |
How RTC Shrinks the Search
If the receiver knows the correct time, combined with its last known position and stored orbit data, it can compute where the satellites should be and predict the Doppler shift of their signals. That lets it search a much smaller frequency window and a much smaller time and code window. Less searching leads to a faster signal lock, and a faster lock leads to a faster fix.
Without a valid RTC, the receiver must sweep a wider time window and a wider Doppler range, and acquisition slows down significantly.
Common Misconceptions
A few points that often get mixed up:
The ephemeris is not downloaded on every startup. It is only downloaded when it has expired, when memory is lost, or on the very first startup.
The RTC does not replace the ephemeris, and it does not synchronize continuously with satellites. Each piece plays its own role.
The core concept ties it together:
Ephemeris + Time = Satellite position.
Satellite position + Signal timing = Receiver position.
The RTC simply makes the “Time” part available quickly.
The Bottom Line: Real Numbers
A hot start with a valid RTC and still valid ephemeris takes 1 to 5 seconds. A warm start, where the RTC and almanac are valid but the ephemeris has expired, takes roughly 10 to 30 seconds because fresh ephemeris must be downloaded. A cold start with no valid time, no ephemeris, and no usable almanac takes 30 to 60 seconds or more.
The value of an accurate RTC shows up in two ways. When valid ephemeris is still in memory, a good RTC timestamp is what makes a hot start possible at all, turning what would otherwise be a 30-plus-second reacquisition into a 1-to-5-second fix. Even when the ephemeris has expired, knowing the correct time keeps the receiver in warm-start territory rather than forcing a full cold-start search. In practice, that can mean saving 20 to 50 seconds, sometimes more.
It is worth being precise about what the RTC alone buys you. Time recovery is necessary but not sufficient: an accurate RTC only delivers a near-instant fix when valid ephemeris is also present. If the ephemeris has expired, the receiver still has to download it before it can fix, so the RTC’s benefit is bounded by whether that orbit data is current.
For battery-powered and duty-cycled devices, where every second of radio-on time costs energy, those saved seconds add up quickly across thousands of wake cycles.
If you’re building a GNSS device and struggling with slow fix times, we’d be happy to help. Feel free to Contact Us for GNSS hardware design, embedded firmware, and low-power system integration services.
