Coordinate-Time and Navigation Support System of Ukraine
Paramount Pictures does not represent.
Based on True Events
This educational series is inspired by real developments in satellite navigation technology. While based on actual scientific principles and the author's professional experience, certain elements have been reimagined for educational clarity. Any resemblance to specific classified systems is purely coincidental.
Like stories of Prohibition-era America, where bootleggers became folk heroes and speakeasies flourished in shadows, the world of navigation technology has its own tales of innovation born from necessity, ingenuity arising from constraint, and knowledge spreading through unconventional channels.
Lecture Series: Coordinate-Time and Navigation Support System of Ukraine (CTNS/SKNOU)
Day 1: Navigation and Precision
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Introduction to the Topic
Students from the aviation university attended their first lecture in the navigation systems laboratory, where they were introduced to practical aspects of high-precision navigation and real-world engineering challenges.
Dr. Andrew – Senior Researcher
Standing before the students was a middle-aged man whose posture and focused gaze immediately conveyed a background of precision engineering and advanced technology. His neatly buttoned shirt and composed movements reflected a disciplined and methodical personality.
Right beside him stood the towering frame of the Control and Correction Station (CCS) — the core of the navigation system, integrating state-of-the-art engineering solutions. Beneath its metallic shell were housed satellite signal receivers, an atomic time and frequency standard, a UNIX-based computing module, a router, and multiple data transmission modems. Every component had a single purpose — to ensure the highest possible accuracy and reliability in navigation calculations.
In the dimly lit laboratory, equipment indicators flickered rhythmically, processing a continuous stream of incoming signals. It felt as though the station itself was alive — working, analyzing, and adapting in real time. This wasn't just a set of devices; it was a coordinated intelligence node where every process, every computation, and every algorithm worked in harmony to deliver stable time and positioning references.
"Welcome to the lecture series," Andrew began after a short pause, evaluating the young engineers. "My name is Andrew. I hold a PhD from Kharkiv Aviation University. I've been working in the field of navigation systems long enough to witness how deeply this technology affects security, precision, and geopolitics."
Why Is Independent Navigation Critical?
Dr. Andrew turned to the board and sketched a satellite constellation.
"Many of you consider GPS to be the ultimate and reliable solution," he said. "But in reality, it's a geopolitical tool."
He turned back to the audience and continued:
"When we were testing the Topol-M intercontinental ballistic missile at the Plesetsk Cosmodrome, something unexpected happened. The launch schedule was set, and all preparations were complete. Everything was going smoothly — until the GPS signal disappeared over the test site just minutes before the launch."
Andrew paused to let the students think.
"What do you think happened?"
Someone cautiously responded: "Equipment malfunction?"
Andrew shook his head.
"The launch had to be postponed by two hours. Later, we learned that the U.S. had deliberately disabled GPS over the launch area at that exact time. They believed that the Topol-M relied on GPS for final positioning."
The Danger of Selective Availability
"Now imagine such interference not during a test, but in a real military operation," Andrew continued. "For instance, if the Selective Availability mode is switched on — which the U.S. can do at any time — the consequences could be severe."
"What would happen then?" a student asked.
"Positioning accuracy would drop to 80–100 meters," Andrew replied. "That's a disaster if your target requires meter-level precision."
Why Ukraine Needed Its Own System
Andrew took a step toward the whiteboard and wrote in bold letters: SKNOU = Navigation Sovereignty
"This is why Ukraine had to build its own navigation infrastructure. We couldn't afford to rely on GPS or GLONASS alone."
A student raised his hand: "But why was Ukraine so dependent on GPS? Couldn't we use GLONASS instead?"
Andrew sighed: "Because in the 1990s, Ukraine lost virtually everything in the strategic domain. The political leadership — mainly former communists — surrendered our nuclear arsenal, missiles, and strategic bombers in exchange for 'security guarantees' from nuclear powers."
Navigation and Military Conflicts
Andrew changed the slide and continued:
"SKNOU was developed not only to monitor navigation inside Ukraine but also to evaluate the precision of global navigation solutions. As part of my research, I analyzed NAVSTAR system accuracy directly before the U.S. launched its military operation in Iraq in 2003."
Andrew paused, his expression becoming more serious.
"During my service in the Air Force from 1984 to 1986, I personally supported over 500 flights of a MiG-21 fighter jet. To put this into perspective: that's nearly half of the total 1,163 sorties flown by the F-14 air group from the USS Theodore Roosevelt during Operation Iraqi Freedom. This wasn't theoretical work — it was hands-on engineering under pressure, where every decision mattered, and mistakes had real consequences. That experience shaped how I approached satellite navigation analysis."
"What did you find?" one student asked.
"Based on measurements obtained through our SKNOU stations, the deviation was minimal. Instead of the usual 6–10 meters, positioning accuracy was less than 2 meters — the error circle diameter did not exceed 2 meters. Such anomalously high precision was, for me, an indicator of impending military action."
Andrew explained further: "Based on the data from our measurements obtained using SKNOU stations, I concluded that military conflict was inevitable. The operation began on the morning of March 20, 2003."
The students exchanged glances.
"The military campaign's official name was Operation Iraqi Freedom (OIF)."
"But isn't it called 'Shock and Awe'?" one student asked.
"'Shock and Awe' is not the name of the operation itself," Andrew clarified. "It refers to a military doctrine developed in 1996, which was applied for the first time in Iraq during OIF — a strategy focused on rapid dominance through overwhelming precision and firepower."
What Is SKNOU?
Andrew advanced to the next slide, which displayed a schematic diagram of the SKNOU architecture.
"SKNOU is a system designed to maintain navigation accuracy across Ukraine. It follows the principles of the European EGNOS system and works in conjunction with both GPS and GLONASS signals."
He walked over to the screen and pointed to the two key components:
- RPNP – Regional Navigation Field Monitoring Point
- CCS – Control and Correction Station
System Characteristics
Andrew projected a table summarizing the accuracy levels across different SKNOU service modes (where DCI stands for Differential Correction and Integrity):
| SKNOU Services | Wide-Area DCI (Code) | Zonal DCI (Code) | Local DCI (Code) | Local RTK (Phase) DCI | Network RTK (Phase) DCI |
|---|---|---|---|---|---|
| Accuracy, 2σ (RMS) | 1m (horizontal) 2m (vertical) (within network corners) |
<1m (within 150 km radius) |
0.2m–1m (30–150 km from CCS) |
0.02–0.2m (within 30 km of CCS) |
0.02–0.04m (uniformly within RTK cell) |
"It's important to understand," Andrew emphasized, "that each mode offers different levels of accuracy. Wide-area DCI is suitable for applications like aviation and maritime navigation, while RTK services are used in geodesy and precision surveying."
Testing the Ukrainian Segment of EGNOS
He switched slides again.
"Back in the 2000s, we successfully tested Ukraine's segment of EGNOS. This confirmed full compatibility between SKNOU and the European navigation infrastructure."
A map appeared on the screen, showing marked control points.
"We deployed monitoring stations in Kharkiv, Simferopol, and Luhansk. These sites analyzed satellite signals and transmitted their data to the Central Navigation Processing Center (CNPC)."
Conventional Designations
Andrew wrote on the board for everyone to copy:
Development Stages:
- TA
- Technical Assignment
- EP
- Sketch Project
- TP
- Technical Project
- WP
- Working Project
- IM
- Implementation
Key Navigation Terms:
- GLONASS
- Global Navigation Satellite System
- GPS
- Global Positioning System
- PMB
- Real Time Scale
- CNPF
- Central Navigation Field Control Center
- RPNP
- Regional Navigation Field Monitoring Point
- CCS
- Control and Correction Station
Navigation and Precision: A Scientific Internship Diary
Control and Correction Station (CCS)
Andrew led the students into a secure laboratory where one of the operational Control and Correction Stations (CCS) was housed. Inside, server racks buzzed with activity — real-time satellite data was being captured, analyzed, and corrected.
Andrew used a bilingual learning method to explain the station's architecture, constantly toggling between the schematic and the physical hardware. He treated the diagram as the "theory" and the live equipment as the "practice." This parallel approach, much like reading a bilingual text, helps bridge the gap between concept and reality, ensuring a deeper, more practical grasp of how the system truly works.
"This is the beating heart of SKNOU," Andrew said, gesturing toward the racks of precision equipment. "Control and Correction Stations provide high-precision navigation by receiving, analyzing, and correcting signals from GPS and GLONASS satellites."
He continued, outlining the system's structure:
- Roof-mounted receivers – capture GNSS signals from visible satellites.
- Computing center – processes raw data and calculates differential corrections.
- Transmitters – broadcast correction data to end users over secure channels.
Architecture of the Control and Correction Station
The CCS is one of the system's most critical nodes. Its architecture is based on modular principles and includes:
- High-sensitivity satellite signal receivers
- A robust computing cluster for data analysis and integrity monitoring
- Precision frequency standards
- Routing and communication modules for external data transmission
Together, these components ensure that the CCS effectively eliminates distortions caused by ionospheric and tropospheric interference, thereby increasing both horizontal and vertical positioning accuracy across the system.
Andrew paused at the schematic diagram and said: "The CCS didn't emerge from nowhere. Its architecture evolved from earlier systems like 'Collection', 'Unified Control Center (UCC)', and 'Breeze'."
Measurement Information Concentrator
Typical "1990s Information Concentrator"
Used as the closest analogy in building the CCS (Control and Correction Station).
The image shows a John Deere tractor with a multi-section plow, figuratively and accurately reflecting the concentrator architecture:
🚜 Tractor = PC Host (Pentium 4)
Powerful control node that performs computations and system management. Contains the operating system and executes primary processing tasks.
🔗 Hitch = 8-port Multiplexer
Aggregates data streams from the synchronization processor to channels. Serves as the distributing link between computations and communication lines.
🔧 Plow = Synchronization Processor (SP)
Divides the task flow from the PC into multiple independent channels. Synchronizes each communication line and manages concurrent operations.
📡 Furrows = Communication Channels
8 or more simultaneous lines: serial ports, radio channels, network interfaces. All operate independently and in parallel.
🧑🌾 Tractor Driver = Application Layer
Determines route, controls direction, speed, timing, and movement precision. Implements high-level navigation algorithms.
📌 Conclusion: The "Information Concentrator" architecture was adopted and enhanced with sophisticated application layer development, solving navigation challenges as described in lectures by Senior Research Fellow Andrew, to create the CCS — Control and Correction Station, operating in real time.
In these predecessors, the concept of a measurement information concentrator was implemented and tested under real-time operational conditions. UNIX-based platforms provided the backbone for multitasking, fault isolation, real-time processing, and priority message switching.
The Breeze system, in particular, introduced the use of a dynamic status map — a visualization tool that showed the condition of each communication channel. This map enabled instant operator decisions, GNSS sky plot generation, and high-level performance analytics, all in real time.
UNIX Process Management: Like a Well-Organized Pool Party
Extended UNIX Operating System Metaphor:
🏊♂️ Swimming rings = individual processes, each with its own PID (participant number). Can be different sizes (memory footprint) and colors (priorities), but all use shared pool resources.
💻 Workstation in center = system kernel, which monitors all processes in real time, manages resource allocation, and makes critical scheduling decisions.
🌊 Water streams = inter-process communication (IPC): stdin flows from above, stdout exits through pipes, stderr can be redirected to separate channels.
🏊♀️ Inflatable mattress = shell interface (command line), from which child processes "dive" into water when executing commands, controlling their execution.
🏀 Ball = shared memory or file descriptors that processes can pass to each other or use collectively.
🪜 Ladder = system calls — the only "legal" way for processes to interact with the kernel and request system resources.
⭕ Pool diameter = available memory size (RAM) — a fixed system limitation that determines how many processes can comfortably "swim" simultaneously.
💦 Water level = current system load — when the pool overflows, some "swimmers" are temporarily moved to an adjacent water barrel (swap partition on disk).
🌡️ Water temperature = processor load and temperature — the more intensively processes work, the "hotter" the system becomes, requiring cooling or throttling.
🧪 Water chlorination = security and access permissions system — maintains system "cleanliness," preventing infection by malicious processes and controlling resource access.
🏊♂️ Lifeguard = error and exception handling system — watches for "drowning" processes, intercepts critical situations, and prevents total system crash.
🔄 Water circulation = task scheduler, which ensures fair distribution of CPU time among all processes.
In SCNOU, we didn’t just swim in UNIX — we turned it into a fully managed waterpark for real-time systems.
Like a well-organized pool, in UNIX every element has its place and function, and the overall system works smoothly thanks to clear rules and reliable management. This metaphor transforms abstract operating system concepts into an intuitively understandable physical scene — a perfect example of explaining complexity through simplicity.
"Tomorrow," Andrew concluded, "we will explore how the CCS communicates with Regional Navigation Field Monitoring Points (RPNPs) and how this collaboration forms the SKNOU network backbone."
Summary
"That concludes today's lecture," Andrew said. "For your independent study, please review the following materials. I hope you've come to realize that navigation is not merely a collection of formulas — it is a matter of national security."
"Tomorrow, we'll dive into Input Data — the real datasets processed by the system. Be prepared — it's going to get a lot more technical."
Additional Study Materials
As the students were heading out, Andrew called out: "Take a quick look at the Purpose and Characteristics appendix when you get a chance — it'll help keep us all on track with our satellite navigation journey."
Lecture Tables:
📎 Open Appendix – Day 1
Homework
"That concludes today's lecture," Andrew said. "For your independent study, please review the following materials. I hope you've come to realize that navigation is not merely a collection of formulas — it is a matter of national security."
Note (Looking Ahead to 2004):
The following year, Andrew (technical architect, Ukraine) will play a pivotal role in advancing GNSS experimentation and infrastructure.
His contributions include:
- Development and documentation of all feasible broadcasting methods for GNSS differential corrections within the EGNOS/ESTB framework.
- Establishment and maintenance of a satellite radio link between Kharkiv and Norway for real-time correction delivery.
- Analysis of multipath effects in GNSS signal reception using the PEGAS software, within the KKS complex.
- Technical leadership in coordinating national infrastructure for GNSS experiments.
-
🔗
EGNOS System Test Bed – Ukraine Participation (UNOOSA, ICG 2015)
(Document confirming Kharkiv’s role in the 2004–2005 EGNOS/ESTB experiment)
In 2004, the Kharkiv station participated in preliminary trials for Ukraine’s integration into the EGNOS system (see EGNOS on Wikipedia) . As part of this effort, establishing a direct data link between Kharkiv and the processing center in Norway required overcoming a range of technical and regulatory challenges — one of the most critical being the authorization to use a dedicated satellite communication channel.
At the time, this meant navigating Ukraine’s Radio Frequency Service (now known as the Spectrum Management Authority), which involved preparing a detailed roadmap with over 20 technical and procedural steps. The responsibility fell on Andrew, who took full charge of the process — from formalizing the requirements to managing all bureaucratic procedures.
The goal was clear: to enable a reliable satellite data exchange between the two countries, bypassing systemic and regulatory obstacles. It was far from a pleasant job, but without it, the signal would never have made it through.
"Tomorrow, we'll dive into Input Data — the real datasets processed by the system. Be prepared — it's going to get a lot more technical."
Day 2: Control and Correction Station
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Introduction: A Look into the Heart of Navigation
Day two of the practice began with excitement. Andrew led the students into the laboratory, where server racks hummed, and the air was filled with the spirit of technology. This was the Control and Correction Station (CCS)—not just a room with equipment, but a true control center for satellite navigation accuracy.
"This is the heart of the SKNOU system," Andrew said proudly, gesturing to the equipment. "Here, signals from GPS and GLONASS satellites are transformed into data that help us not get lost in this vast world. How does it work? It's both simple and complex. The CCS has three main heroes:"
- Roof-mounted receivers — they capture satellite signals like ears tuned to a cosmic wave.
- Computing center — the brain of the station, analyzing data and calculating corrections.
- Transmitters — the voice, sending correction signals to those who need them.
The students froze, watching the blinking lights. It felt like a journey into the future—and it was just beginning.
A Simple Explanation: What is Input Data and Why is it Needed?
Imagine: you're walking through an unfamiliar city with a trusty companion—a GPS navigator on your smartphone. It whispers: "Turn left," "You're almost there." But think: how does it know where you are? The answer lies in invisible threads connecting Earth and space—in data we call Input Data. This is the fuel without which the navigator turns into a useless piece of plastic. Let's figure out where it comes from and why it's so important.
Two Main Categories of Data
Input data is like ingredients for a delicious dish. It can be divided into two groups:
- "Raw data" — fresh, unprocessed, straight from the "cosmic garden." They are collected by receivers Z18 and GG24, which, like sensitive radio stations, catch satellite signals.
- Algorithm configuration parameters — the recipe, instructions for the program: "Add a pinch of this, mix with that." They help turn signal chaos into precise coordinates.
What's Hidden in "Raw Data"?
Raw data is a whole set of tools, like a chef's arsenal:
- Measurement data — distances to satellites, angles of visibility, small details as if measured by a cosmic ruler.
- Location data — your coordinates, like a point on a map: "You're here, at the intersection."
- GPS ephemeris — the schedule of GPS satellites, where and when they will be, like a train timetable.
- GLONASS ephemeris — the same for Russian satellites.
- GPS almanac — a general map of all GPS satellites' positions.
- GLONASS almanac — a similar map for GLONASS.
Interestingly, the Z18 and GG24 receivers "hear" measurement data differently—like two chefs using different spices—but the rest of the data is the same. All this is neatly packed into tables numbered 2.1 to 2.7. Let's take a look inside!
Revisiting Input Data: Reinforcement Through Repetition
Andrew noticed the students were thoughtful and decided to reinforce the material.
"Let's go over it one more time, just to be sure," he smiled. "Imagine you're in an unfamiliar city with only a navigator to guide you. It knows everything: where you are, where to go, how to avoid traffic. But without Input Data, it's nothing. These are data from satellites orbiting above us. They are the key to your path."
Two Categories of Data (Reinforced)
"Input data is divided into two parts," Andrew continued. "Raw data is what the Z18 and GG24 receivers catch directly from space. And configuration parameters are instructions for the program to 'cook' everything correctly."
Raw Data: Details (Repeated)
"Raw data consists of six types of information:
- Measurements — distances, angles, etc.
- Location — your coordinates.
- GPS ephemeris — GPS satellite schedules.
- GLONASS ephemeris — GLONASS schedules.
- GPS almanac — general GPS satellite map.
- GLONASS almanac — general GLONASS map.
Z18 and GG24 differ in measurements, but the rest is common. It's all in tables 2.1–2.7. Got it? Great, let's move on!"
Table 2.1: Data Structure of Measurements for the Z18 Receiver
The Z18 receiver is a real space detective. It "listens" to satellites and collects a mountain of data:
| Parameter | Size (bytes) | Description |
|---|---|---|
| ID number | 2 | Unique code updated every 50ms, reset every 30 minutes |
| Remaining structures | 1 | Number of data pieces to send in one cycle |
| Satellite number | 1 | 1-56: whose signal is caught (0 if data is scarce) |
| Elevation angle | 1 | Angle in degrees |
| Azimuth angle | 1 | Direction in double degrees |
| Channel number | 1 | Which of the 18 channels is working |
Key measurements include:
- C/A code data block (1 byte, 29 bytes inside): A secret cipher from the satellite.
- Warning flag (1 byte): Alarm signal if something's wrong—each bit like a separate bell.
- Goodbad flag (1 byte): Data quality: 0—nothing, 22 or 23—there is data, but with caveats.
- Polarity_know (1 byte): 0—satellite just caught, 5—signal understood.
- Signal-to-noise ratio (1 byte): How loudly the satellite "shouts" above the noise.
- Carrier phase (8 bytes): How many signal waves have passed, if the function is active.
- Raw_range (8 bytes): Distance to the satellite in seconds—difference between emission and reception. Differs by 11 seconds for GPS and GLONASS.
- Doppler (4 bytes): Frequency change rate in 10,000 Hz.
- Smoothing (4 bytes): Refinement for accuracy.
- XOR control (1 byte): Check if everything is correct.
Total: 95 bytes. It's like a suitcase full of cosmic treasures!
Table 2.2: What Does the GG24 Receiver Catch?
GG24 is Z18's brother but with character. The main differences:
- Channel number (1–24): GG24 has 24 channels—more opportunities!
- Warning flag: Its own alarm signals, slightly different.
- Goodbad flag: Up to 24—data is useful.
- 37 bytes for C/A — a bit more codes.
Total: ~70–80 bytes. GG24 is another view of the same stars.
Table 2.3: Where Are We? (Location Data)
This table is like a "You are here" mark on a map:
| Parameter | Size (bytes) | Description |
|---|---|---|
| Reception time | 4 | When signal was caught (milliseconds GPS/GLONASS) |
| Place name | 4 | Note like "Laboratory" |
| Coordinates X, Y, Z | 8 each | Where the antenna is (meters) |
| Clock offset, velocities, drift | 4 each | How clock and antenna move |
| PDOP | 2 | Positioning accuracy (×100) |
Total: 56 bytes. This is your address in the vast world!
Tables 2.4–2.7: Satellite Schedules and Maps
- Tables 2.4 and 2.5: Ephemerides — The schedule of each satellite: weeks, seconds, coordinates, velocities, corrections. All in fields from 2 to 8 bytes. Like a ticket for a space train!
- Tables 2.6 and 2.7: Almanacs — The general map: satellite numbers, frequencies, their "health" (0 or 1), orbits, checks. It's like a city plan for satellites.
Algorithm Settings: The Recipe for Accuracy
Configuration parameters are instructions for the program: how to process the data so everything matches. They are described in sections 5–10. Without them, it's like cooking without a recipe.
Student Question: Why a Dual-Frequency Receiver?
"Why is a dual-frequency receiver needed? It's expensive!" a student asked, looking at Andrew.
He smiled: "Great question! Let me explain."
Answer: Why a Dual-Frequency Receiver is Essential
A dual-frequency receiver is like super glasses for navigation. Here's why:
-
The Ionosphere Interferes
The ionosphere—a layer of charged particles—distorts signals. Lower frequencies are delayed more. Signals L1 (1575.42 MHz) and L2 (1227.60 MHz) suffer differently. -
Single-Frequency Receiver
It catches only L1 and guesses the delay using models (e.g., Klobuchar). Accuracy? Not always ideal. -
Dual-Frequency Receiver
It catches L1 and L2, compares them, and calculates the delay precisely. The formula is simple:
\[ \Delta_{\text{iono}} = \frac{f_1^2 - f_2^2}{f_2^2} (\rho_1 - \rho_2) \]where \( f_1, f_2 \) are frequencies, \( \rho_1, \rho_2 \) are distances. This removes ionospheric distortions.
Conclusion: One receiver is single-frequency, the other is dual-frequency. The latter is more accurate because it conquers the ionosphere!
Andrew Simplifies Further
Andrew noticed the students were quiet and decided to add simplicity:
"Imagine: a single-frequency receiver is like listening to the radio with interference. A dual-frequency one is like pure sound in headphones. It removes ionospheric noise, and you know exactly where you are. Cool, right?"
Inspiring Finale: A Journey into the World of Navigation
Imagine: you're standing on the edge of a cliff, wind in your hair, and before you is an endless world. You open the map on your smartphone—and bam!—the "You are here" point with meter accuracy. Magic? No, it's satellite navigation, and its heart is input data.
How Does It Work?
Become an engineer for a minute:
- Receivers catch signals.
- Measure distances and angles.
- Ephemerides clarify where satellites are.
- Two frequencies defeat the ionosphere.
- You see precise coordinates.
It's not just technology—it's a dance of science and fantasy!
Why Is This Inspiring?
Satellite navigation is a bridge between us and the stars. Every time you look at a map, remember: behind each "You are here" point is the work of minds, and you can be one of them. Planes land, drones deliver aid—all thanks to these data. It's your chance to shape the future!
Conclusion: Practice Diary, Day 2
Thus passed the second day. The students saw how the CCS comes to life, learned about Input Data and dual-frequency receivers conquering the ionosphere. Andrew explained everything with fire in his eyes: satellite navigation is not just science, but a chance to touch greatness. And who knows, maybe one of them will soon create a new technology that will lead us to the stars?
If anyone snoozed through the lecture for reasons beyond their control (it happens!), don't worry. All the detailed data and structures presented in the tables are available for you to review at your own pace. Learn how to use them effectively, and you'll be able to work with this material like an expert!
Day 3: Sequence of Measurement Data Processing
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Introduction to the Journey
Welcome to the third day of our adventure! Today, the students arrived on time, and Andrew started a brief lecture to immerse us in the essence of the Coordinate-Time and Navigation Support System (SKNOU). We will explore the sequence of measurement data processing, which reflects the stages described in the preliminary data processing. Here, raw signals are transformed into valuable navigation data. Let's break down this process step by step, paying close attention to the formulas that form the foundation of these transformations.
Journey of Data: Extended Version with Formulas
| Pizza Action | Engineering Step | Purpose |
|---|---|---|
| GATHER FROM Pantry | Acquire raw GNSS frames from NRS | Obtain raw measurement data |
| PREP / SCALE | Unpack frames, decode DI, convert to SI | Convert data to physical units |
| DISCARD spoiled items | Detect & remove outliers | Remove anomalous measurements |
| MIX / REST | Filter, stats, time-align | Clean & synchronize data stream |
| SEASON sauce | Apply measurement corrections | Compensate ionosphere, troposphere, etc. |
| VERIFY oven… | Navigation-field integrity monitoring | Ensure navigation-field integrity |
| BAKE | Generate optimal DCI | Form differential-correction packet |
| SLICE_AND_BOX | Encode DCI for end users | Prepare RTCM messages |
| SEND_SLICE_TO_CCS | Forward MI/DI to CCS & receive new params | Close feedback loop |
| ARCHIVE … IN WalkInFridge | Store data & logs in RPKNP_DB | Historical database for audit & analysis |
Scene 1 — Gather from Pantry
Повар собирает сырые GNSS-данные в виде светящихся кубиков, падающих от спутников.
1. Receiving Raw Data: The Heroes' First Steps
The journey begins with the reception of raw data from satellite signals. These signals, encoded with navigation messages, arrive as binary streams. The first task is to verify their integrity using control sums, such as CRC (Cyclic Redundancy Check) or XOR-based checks, as described in the preliminary processing stage. This ensures no corruption occurred during transmission.
The pseudorange, a key metric, is introduced here with the formula:
where:
- \(c\) is the speed of light (299,792,458 m/s)
- \(t_{\text{recv}}\) is the reception time
- \(t_{\text{send}}\) is the transmission time
This formula sets the stage for later calculations, though its full application comes in subsequent steps.
2. Preliminary Data Processing: Converting to Physical Units
Next, the verified raw data is converted into physical units. This involves applying scale factors to transform digital counts into meaningful measurements like distances or velocities.
For example, a scale factor \(k\) multiplies the raw data \(D_{\text{raw}}\) to yield a physical value \(D_{\text{phys}}\):
Table 5.1 from the preliminary processing details these factors for parameters like azimuth, Doppler shift, and time. This step ensures compatibility with navigation algorithms, though synchronization of time scales (e.g., GPS vs. GLONASS) is noted here as a future consideration.
3. Kepler's Algorithm and Satellite Coordinates: Ephemerides
With physical units in hand, we calculate satellite coordinates using ephemeris data.
GPS Satellite Position Calculation
For GPS, the Keplerian orbit model is employed. The process starts with the mean anomaly \(M\), which evolves to the eccentric anomaly \(E\) via the Kepler equation:
where \(e\) is the eccentricity. This is solved iteratively, leading to the true anomaly and finally the position \((X, Y, Z)\) in the Earth-Centered Earth-Fixed (ECEF) frame.
GLONASS Satellite Position Calculation
For GLONASS, numerical integration (e.g., Runge-Kutta method) adjusts for its non-Keplerian orbit, as detailed in the preliminary processing. These calculations are critical for positioning.
4. Corrections: Earth Rotation (Sagnac Effect)
Corrections refine our data. The Sagnac effect, caused by Earth's rotation, adjusts the pseudorange. The correction \(\Delta_{\omega}\) is computed as:
where:
- \(\omega_E\) is Earth's angular velocity (7.2921151467 × 10⁻⁵ rad/s)
- \(R_E\) is the Earth's radius (6,371,000 m)
- \(c\) is the speed of light
- \(\phi\) is the latitude
This aligns with the preliminary processing's focus on rotation corrections, though ionospheric and tropospheric effects are noted as UNIX-specific enhancements for future implementation.
5. Quality Analysis and Integrity Checks
Quality checks ensure data reliability. While the preliminary processing focuses on control sums (Section 5.1), additional metrics like PDOP (Position Dilution of Precision) could enhance integrity. However, these are not detailed yet and serve only as a conceptual note tied to the pseudorange formula \(\rho\). Further development is needed beyond the current scope.
6. Forming Differential Corrections (DC) and Data Output
Finally, differential corrections are formed using pseudoranges. The code pseudorange \(S_{C/A}\) is calculated as:
where \(dt_{\text{recv}}\) and \(dt_{\text{send}}\) are receiver and satellite clock offsets. These values, derived in the preliminary processing, enable output in formats like raw data archives, ready for navigation use.
7. Humorous Epilogue: Data-Pizza 2.0
Imagine our data as a pizza! The crust is the raw data, topped with sauce (physical units), cheese (satellite coordinates), and extra toppings (corrections). Delivered hot, it's ready to navigate—UNIX style, of course!
8. Summary
The key steps in measurement data processing:
- Receive and verify raw data with control sums
- Convert to physical units using scale factors
- Calculate satellite positions with Kepler or numerical methods
- Apply Sagnac corrections to refine pseudoranges
- Form differential corrections for output
Each step builds upon the previous, transforming raw satellite signals into precise navigation solutions. The beauty lies not just in the mathematics, but in the systematic approach that ensures reliability and accuracy.
Day 4: Data Filtering — Cleaning Signals with a Smile
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Introduction to Filtering: Data Loves Order Too
Imagine you are in a kitchen preparing a navigation soup — yes, a soup that will help your satellite avoid getting lost in space! On Day 3 the students arrived on time, and Andrew gave a short lecture where we gathered the ingredients: we took raw data, cleaned it up, added pseudoranges, and even lightly seasoned them with Sagnac corrections. Inspired by that success, Andrew continued on Day 4, showing how to make the data even better. Today we will dive into filtering: remove all the noise so the data becomes smooth as silk, and calculate just how "noisy" they are. Time to grab our cosmic ladles — let's begin!
Data Filtering: The Mathematical Mop
1. What Are We Filtering and Why? Saving the Pseudoranges
We take our beloved pseudoranges (\(S_{C/A}\), \(S_{L1}\), \(S_{L2}\)) and their rates (\(\dot{S}_{C/A}\), \(\dot{S}_{L1}\), \(\dot{S}_{L2}\)), as well as phase pseudoranges (\(\varphi_{L1}\), \(\varphi_{L2}\)) and their derivatives. These are "cosmic measures" that help us understand where the satellite is and how fast it is moving. Details of exactly what we filter are in Section 6.1. But data behaves like a temperamental child: it jumps around or falls into first-order discontinuities. For example, \(S_{C/A}\) can suddenly "drop off a cliff," and we have to catch it.
For that we have a special detector — "Oh no, something went wrong":
where:
- \(\Delta S\) is the difference between the current value and the expected one
- \(\delta t\) is the time interval
- \(c\) is the speed of light
- The floor function \(\lfloor \cdot \rfloor\) returns the integer part
If a break is detected, we patch it so the signals don't jerk around like a caffeinated cat at a disco. And if the data is unreliable (flag = 1), we zero it out — no garbage in our soup!
2. Smoothing: Making Data Silky Smooth
Now we bring out our magical mathematical mop — a filter that smooths the data. We take each pair (e.g., \(S_{C/A}\) and \(\dot{S}_{C/A}\)) and start combing through them. Matrix \(R\) tells us how noisy the data are — its values are set by the operator, like a chef adding salt:
Then we use a polynomial with coefficients \(a_0, a_1, \ldots\) to make the data behave nicely. Result: \(\eta = a_0\), \(\dot{\eta} = a_1\). We refine the recipe as new data come in!
3. Refining the Coefficients: "All Under Control!"
At the start we set \(a_0\) to the current pseudorange, \(a_1\) to the rate, and the rest (\(a_2, \ldots\)) to zero — "let's not complicate things yet." We then check reliability:
where \(\varepsilon\) is the difference between measurement and prediction. If the difference is large, we mark it (flag = 1) and skip it. If all looks good, we update the coefficients with the matrices — our filter won't let the satellite lie!
4. Measuring the Noise: Statistics on Guard
The cherry on top — calculating how noisy the data are. Root Mean Square Deviation (RMSD):
The smaller the RMSD, the calmer our soup — and the more accurate the satellite's path!
Epilogue: "Cleanliness Is the Foundation of Navigation!"
With filtering we have turned noisy data into a smooth navigation broth. Discontinuities are patched, irregularities smoothed, and noise measured — see details in Section 6.4. The satellite flies confidently, and Andrew and I truly deserve a cup of tea — or soup? 😄
Technical Details of Filtering
6.1. Filtering Measured Parameters
Filtering of measured parameters is performed separately for each GNSS receiver and each spacecraft. Smoothed estimates are formed at the reference time of the last frame \(t\).
Filtering is applied to the following parameter groups:
For brevity, indices specifying receiver number, satellite number and type are omitted. The following notation is used:
For measurements flagged as unreliable (flag = 1), the corresponding pseudorange and rate values are set to zero.
During smoothing, first-order discontinuities of \(S_{C/A}\) are eliminated.
Detection of discontinuities uses:
where
The tilde (~) refers to the last preceding point with reliable \(S_{C/A}\) and \(\dot{S}_{L1}\) values.
6.2. Smoothing Parameters
— a priori noise covariance matrix (values \(D_{\eta}\) and \(D_{\dot{\eta}}\) are set by the operator).
Smoothed values \((\eta_{i,j,k,1}\) and \(\dot{\eta}_{i,j,k,1})\) obtained by receiver \(i\) for spacecraft \(j\) at the current time are:
The inverse of a \(2 \times 2\) matrix is calculated as:
6.3. Initial Estimates and Coefficient Refinement
Initial coefficients are set to the measured values at the initial time:
Coefficients are refined as reliable data arrive, according to:
a) Reliability check:
where
If the condition fails, the point is discarded (flags \(\text{Pr}_{\eta_{i,j,k}}\), \(\text{Pr}_{\dot{\eta}_{i,j,k}}\) = 1). Steps b) and c) are skipped.
b) Covariance update:
c) Coefficient vector refinement:
6.4. Calculation of RMS Fluctuation Errors
RMS fluctuation errors of measurement parameters are computed as:
These values provide a quantitative measure of the filtering quality and remaining noise in the smoothed parameters.
Day 5: Introduction to Corrections
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Andrew Walks Through the Research Institute
Andrew was walking down the corridor of the research institute, carrying a thick folder of formulas under his arm. It was not his first year on the job, but every time he had to explain the principles of GPS and the importance of corrections, he felt a certain excitement. Andrew was a middle-aged senior researcher specializing in navigation systems. He loved his work and knew how difficult it could be for people "off the street" to understand why GPS is not as simple as it seems.
Today he would be giving a new lesson to a group of students. They were young people: some were already familiar with the basics of radio engineering, some had only seen GPS on a smartphone, and all were curious, albeit slightly wary. Andrew's reputation as a tireless theorist preceded him.
The Lecture Hall and First Impressions
The lecture hall Andrew entered was quite spacious. Future engineers and graduate students were seated in rows. On the board were fragments of formulas labeled with Latin and Greek symbols. On the wall hung posters showing satellite diagrams, orbits, and charts of signal delays.
When Andrew took his place at the lectern, he glanced around the audience and began unhurriedly: "Good day. If you haven't managed to review the previous material, don't worry. Today we'll talk about how GPS 'sees' the world and why this system vitally needs various corrections."
Some of the listeners took out notebooks, while others opened their laptops. Andrew paused briefly, trying to set a serious tone: "I'm sure many of you think that GPS is simply satellites telling us our coordinates. In reality, it goes much deeper. Satellites do indeed transmit signals, and by knowing the speed of light, we can calculate the distance to them. But here's the problem: the signal doesn't travel through a perfect vacuum. Our atmosphere (the troposphere and the ionosphere) introduces interference, and we must account for these distortions to avoid errors that sometimes reach tens of meters."
A Simple Analogy and the First Formulas
To warm up the audience, Andrew pulled a small rubber ball out of his pocket: "Imagine this ball is a satellite," he said, placing it at one end of the table. "And over here, at the other end, is my phone—this is the GPS receiver. The satellite sends a signal with a timestamp. The receiver measures how long it took for the signal to arrive, multiplies that time by the speed of light, and gets the distance."
Andrew picked up an empty glass: "Imagine this glass as an ideal space without atmosphere. The beam passes through it without refraction. But now..." — he filled the glass with water — "...this is the troposphere and ionosphere. If we send light through water, it bends, changing its speed. The same thing happens with the GPS signal."
He took a laser pointer and aimed it through the water, demonstrating how the beam deflects. "Just like water in the glass bends the light, the atmosphere slows down and distorts the radio signal. The lower the satellite is on the horizon, the longer the signal path and the greater the error. And if we add the ionosphere on top, charged particles affect the radio wave in a different way."
Andrew narrowed his eyes, as if recalling one of his first field experiments: "And to compensate for all these effects, there are special models and formulas. Let's take a look at the most basic ones."
He turned to the board, where a few key equations had been written in advance. First, he pointed to the 'pseudorange' equation:
"Here:
- \(\rho\) is the actual distance to the satellite
- \(c\) is the speed of light
- \(\Delta t\) is the difference between the satellite's and the receiver's clock readings (remember, satellites have atomic clocks, but your phone unfortunately does not)
- \(I\) is the ionospheric delay
- \(T\) is the tropospheric delay
- \(\epsilon\) represents various noise
The pseudorange is not the perfect distance; it's a value that contains errors."
Troposphere: "Fogged Glass"
Andrew took a poster from a stack and pinned it up next to the board: "The troposphere is the lower layer of the atmosphere; it depends on pressure, temperature, and humidity. It distorts our signal like a fogged-up piece of glass through which we try to see something. To correct for the troposphere's effects, we introduce special corrections:
Andrew explained, pointing to the formula. "Here, \(\Delta_c^j\) is the 'dry' component, which can be calculated based on temperature and pressure, while \(\Delta_{wet}^j\) is the 'wet' component, which depends on water vapor. The dry part is more predictable, but the wet part changes constantly."
He showed the audience a printout with even more complex formulas: "In these formulas, you'll see coefficients \(a\), \(b\), \(c\), as well as parameters \(\delta P\), \(\delta t\), \(\delta \beta\), \(\delta H_T\). All of these are needed to account for real atmospheric conditions at the moment the signal is received."
Ionosphere: "Scratches on the Glass"
Switching his attention to the next poster, Andrew continued: "The ionosphere is the upper layer of the atmosphere, filled with charged particles. It delays radio waves especially strongly when the Sun is active," he said, tapping a bright diagram of solar wind interacting with Earth's magnetosphere. "In regions closer to the equator or the poles, the effect is even stronger."
He emphasized that GPS typically uses multiple frequencies—L1 and L2: "Signals on different frequencies slow down in different ways. So by comparing how these frequencies arrive, we can calculate the ionospheric correction:
"In essence, by measuring the difference in propagation speed of signals at frequencies \(f_{L1}\) and \(f_{L2}\), we determine the degree of delay in the ionosphere and correct the coordinates."
Applying Corrections and Final Accuracy
Having finished the explanation, Andrew drew a line on the board and wrote:
"These formulas show how tropospheric and ionospheric corrections are added to the original data. Without taking all these terms into account, GPS errors can reach tens of meters. But if we apply the corrections, we can achieve accuracy down to a few centimeters—it all depends on the equipment and models used."
Real-World Problems: Multipath and Synchronization
Andrew walked along the board, pointing to a list of typical interferences:
- Multipath propagation: The signal bounces off buildings, mountains, trees. The receiver can be confused by receiving reflected signals. To avoid this, directional antennas and advanced algorithms are used to filter out unwanted signals.
- Receiver clock error: Satellites have atomic clocks, while receivers do not. Therefore, the system continuously "checks" with multiple satellites to calibrate its timing.
- Ephemeris error: Incorrect knowledge of the satellites' own coordinates leads to additional inaccuracies. Ground stations help by periodically updating data on each satellite's precise position.
"We also strive to remove or minimize all these factors," Andrew noted. "In the end, we get a working system where the error can become very small, provided we correctly account for everything that happens to the signal."
A Visual Demonstration
One of the graduate students asked, "Andrew, can you explain in simpler terms why we need all these models, since GPS seems to work fine anyway?"
Hearing this, Andrew smiled. He picked up the rubber ball again: "Imagine you're trying to see a distant mountain through a fogged window. The troposphere is the fogging that slightly blurs the picture. The ionosphere is scratches and interference on the glass surface. Without corrections, your 'view' would be inaccurate. But by cleaning the glass and putting on the right glasses (i.e., applying corrections), you get a clear picture. The same goes for the GPS signal."
Final Thoughts
Andrew looked around the audience. The young scientists listened intently; some were taking notes, others were examining the formulas with newfound interest, no longer intimidated by their appearance.
"So, we've covered everything from the basic principles—how pseudorange is measured and why it's not perfect—to the specific formulas that help compensate for tropospheric and ionospheric delays. We've seen how multipath propagation and clock errors influence the result, and learned that GPS is not just an icon on your phone but a vast network of technologies, models, and correction stations. In the end, we get coordinates with impressive accuracy."
He set aside his papers and addressed the group: "Remember, satellites are thousands of kilometers away. We receive their signals in real time, and even the slightest inaccuracy in time measurement or any atmospheric delay can distort the result. Yet, thanks to a complex system of corrections and the work of many people, GPS is so precise that it helps us everywhere—from everyday navigation to geodesy and cartography with centimeter-level accuracy."
The lecture ended. The graduate students began animatedly discussing what they had heard, asking questions, and debating the nuances of the calculations. Andrew left the lecture hall feeling satisfied: once again, he had shown the depth and beauty of the technology we so often take for granted. And perhaps, that day marked the start of someone's journey toward new discoveries in the world of high-precision navigation.
Day 6: Introduction of Corrections (Part 2) — Troposphere and Ionosphere
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
1. Introduction: Why Are Corrections Needed?
Satellite navigation operates similarly to an echo-based distance measurement. A satellite sends a radio signal, the receiver on Earth captures it, and the distance is calculated based on signal travel time. However, Earth's atmosphere acts as a multi-layered filter, slowing down and distorting the signal path.
- Troposphere (0–12 km) – a dense lower atmospheric layer where air pressure, temperature, and humidity slow down signals.
- Ionosphere (60–1000 km) – a region full of free electrons that bend and delay radio waves.
If uncorrected, these effects can introduce position errors up to tens of meters, making navigation as unreliable as a blurred city map. Corrections help eliminate these distortions, ensuring precise positioning.
2. Glossary of Key Terms
- Pseudorange
- Measured distance to a satellite, including signal delay errors.
- Pseudovelocity
- Estimated velocity of the receiver based on signal frequency shift.
- Doppler Shift
- Frequency change due to relative motion between the receiver and satellite.
- Elevation Angle
- Angle between the satellite and the observer's local horizon.
- Group Delay
- Frequency-dependent delay of radio waves in the ionosphere.
- Free Electrons
- Charged particles in the ionosphere affecting signal speed.
3. What Are Pseudorange and Pseudovelocity?
Pseudorange \( \tilde{\rho} \)
Pseudorange is the calculated distance based on signal travel time:
where:
- \( c = 299,792,458 \) m/s – speed of light
- \( \Delta t \) – signal travel time
Why "pseudo"? The time \( \Delta t \) includes errors from:
- Tropospheric and ionospheric delays
- Clock synchronization issues
- Receiver noise
Example: If the signal delay is \( 0.0001 \) s:
After applying corrections, the actual distance might be 29.5 km.
4. Tropospheric Correction Model
Tropospheric delay correction for the dry component is computed using the Saastamoinen model:
where:
- \( T \) – temperature (Kelvin)
- \( P \) – pressure (hPa)
- \( \varepsilon \) – satellite elevation angle
- \( a, b \) – empirical coefficients
5. The Saastamoinen Model
The Saastamoinen model is widely used in satellite navigation for estimating tropospheric delay. Developed by Finnish scientist Jorma Saastamoinen, it has become a standard for atmospheric corrections in GNSS systems.
Principles of the Model
Physical Meaning: The model accounts for signal deceleration due to air pressure, temperature, and humidity. These factors are included in the formula as key variables.
Mathematical Basis:
The Saastamoinen model improves GNSS accuracy, making it a crucial tool for high-precision navigation.
6. Ionospheric Corrections
The ionosphere affects radio signals differently at different frequencies. For dual-frequency receivers, we can calculate ionospheric corrections directly:
where:
- \( S_{L1}^{j}, S_{L2}^{j} \) – pseudoranges on L1 and L2 frequencies
- \( f_{L1} = 1575.42 \) MHz – L1 frequency
- \( f_{L2} = 1227.60 \) MHz – L2 frequency
For pseudovelocity corrections:
7. Combined Corrections Application
The final corrected pseudorange and pseudovelocity are calculated as:
where:
- \( S_{i,j,k,2} \) – filtered pseudorange from Day 4
- \( \Delta_{trop}^{j} \) – tropospheric correction
- \( \Delta_{ion}^{j} \) – ionospheric correction
8. Practical Example
Let's calculate corrections for a satellite at 30° elevation:
Given:
- Temperature: T = 288 K (15°C)
- Pressure: P = 1013 hPa
- Elevation angle: ε = 30°
- Dual-frequency pseudoranges: SL1 = 20,000,000 m, SL2 = 20,000,010 m
Tropospheric correction (simplified):
Ionospheric correction:
9. Summary
Atmospheric corrections are essential for accurate GNSS positioning:
- Tropospheric corrections depend on weather conditions and satellite elevation
- Ionospheric corrections depend on solar activity and can be calculated using dual-frequency measurements
- Without these corrections, positioning errors can exceed 20-30 meters
- With proper corrections, centimeter-level accuracy is achievable
Tomorrow, we'll explore how to analyze the quality and integrity of these corrected measurements.
Day 7: In-depth Analysis of Navigation Data
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Topic: From Errors to Accuracy – Analysis and Integrity Control of the Navigation Field
1. Introduction: Why Trust but Verify Navigation Data?
Modern navigation systems have firmly entered our lives, providing precise positioning for a variety of tasks. However, relying on GNSS-measured data without verification is not acceptable. Navigation accuracy is affected by various errors:
- Atmospheric disturbances: the ionosphere and troposphere distort radio signals, causing delays and errors.
- Time inaccuracies: even atomic clocks on satellites and receivers have microscopic deviations.
- Satellite geometry: the arrangement of satellites affects measurement accuracy.
- Hardware and software failures: satellites and receivers may malfunction.
Simple analogy: Imagine a choir where each voice is a signal from a satellite. For "harmonious sounding" (accurate navigation), all "voices" must be clean. Erroneous data are "off-key notes" that need to be identified and corrected.
Purpose of the lecture: the study of GNSS data analysis and integrity control for:
- ✅ Improving the accuracy of navigation
- ✅ Ensuring reliability of navigation information
- ✅ Detecting and excluding failures in the data
Key analysis tasks:
- ✅ Assessment of differential corrections to compensate for errors
- ✅ Validation of signal reliability to evaluate their quality
- ✅ Exclusion of erroneous data to improve accuracy
2. Assessment of Differential Corrections: Eliminating Common Errors
2.1. What Are Differential Corrections and How Do They Work?
Differential corrections are a method of improving GNSS accuracy using a base station with known coordinates.
Operating principle: The base station compares the measured and the actual distances to satellites. The difference is the differential correction. Corrections are transmitted to the rover to compensate for common errors.
Differential GPS (DGPS) Key Components
- 1. GPS satellites
- Constellation of satellites transmitting navigation signals
- 2. Reference Station
- Stationary ground station with precisely known coordinates that calculates correction data
- 3. Mobile Receiver
- Receiver on moving object (aircraft, vehicle) that applies corrections for improved accuracy
- 4. Differential Correction Signal
- Adjustments computed by reference station and sent to mobile receivers
- 5. Communication Link
- LF/MF radio or other means of transmitting corrections from base to rover
Formula for the differential correction (for pseudorange):
Formula breakdown:
-
\(R_{i,j,k}\) – true geometric distance from station \(i\) to satellite \(j\):
\[R_{i,j,k} = \sqrt{(x_{j,i,k} - X_i)^2 + (y_{j,i,k} - Y_i)^2 + (z_{j,i,k} - Z_i)^2}\]
- \(S_{i,j,k,3}\) – measured pseudorange (after atmospheric corrections)
- \(k\) – GLONASS coefficient (1 for GLONASS, 0 for others)
- \(c\) – speed of light
- \(\Delta\tau_{\text{GLONASS}}\) – GLONASS time correction
Index explanations:
- \(i\) – base station number
- \(j\) – satellite number
- \(k\) – time moment
Numerical example of calculating a differential correction:
Suppose:
- Measured pseudorange: \(S_{i,j,k,3} = 20,000,150\) m
- Geometric distance: \(R_{i,j,k} = 20,000,000\) m
- GLONASS time correction: \(k \cdot c \cdot \Delta\tau_{\text{GLONASS}} = 50\) m
Differential correction:
2.2. Taking Measurement Speed into Account: Pseudovelocity
To improve accuracy, pseudovelocity – the rate of change of the pseudorange – is analyzed. Differential corrections for pseudovelocity:
where:
Important: Discrepancies between measured and calculated velocities indicate errors.
3. Navigation Field Integrity Control: Detecting "Off-key Notes"
3.1. Reliability Matrices: \(H_i\) and \(G_i\)
Integrity control involves assessing the reliability of GNSS data. An analysis of the consistency of redundant measurements is used. Check matrices \(H_i\) (pseudorange) and \(G_i\) (pseudovelocity) are formed, reflecting the consistency of corrections between satellites.
Algorithm for forming matrix \(H_i\):
For base station \(i\) and pairs of satellites \((j_m, j_n)\):
- Check data availability: Pseudorange data must be available for both satellites.
-
Calculate the difference of corrections:
\(\delta S_{m,n} = \left| \Delta \hat{S}_{i,j_m,k_m} - \Delta \hat{S}_{i,j_n,k_n} \right|\)
- Compare with threshold (DS): Threshold value (DS) sets the permissible difference of corrections. The choice of DS depends on the required accuracy and the noise level in measurements. In this example, we use DS = 20 meters. In real systems, DS can be set based on statistical error analysis and navigation integrity requirements.
-
Fill the matrix element:
\[\{ H_i \}_{m,n} = \begin{cases} 0, & \text{if data are available and } \delta S_{m,n} \leq DS \\ 1, & \text{otherwise} \end{cases}\]
Matrix \(G_i\) is formed similarly for pseudovelocity with threshold \(DS^{\dot{ }}\).
Example of forming matrix \(H_i\):
| Satellite pair | Difference of corrections (\(\delta S_{m,n}\)) | Comparison with threshold (DS=20 m) | Matrix element (\(\{ H_i \}_{m,n}\)) |
|---|---|---|---|
| \((j_1, j_2)\) | \(|-10 - (-15)| = 5\) m | \(5 \leq 20\) | 0 |
| \((j_1, j_3)\) | \(|-10 - 100| = 110\) m | \(110 > 20\) | 1 |
| \((j_2, j_3)\) | \(|-15 - 100| = 115\) m | \(115 > 20\) | 1 |
4. Decision-making on Failure: Summing "Voices of Dissent"
For each satellite \(j_n\), the system calculates the column sums of the reliability matrices \(H_i\) and \(G_i\):
Interpretation of the sums: The higher the sum for a satellite \(j_n\), the higher the probability that this satellite is the source of an error or inconsistency. These sums indicate how many times the satellite \(j_n\) was "inconsistent" with others in the matrices \(H_i\) (for pseudorange) and \(G_i\) (for pseudovelocity).
Decision-making rule:
- Correct operation: If for all observed satellites both conditions \(\Sigma_{i,j_n}^{H} = 0\) and \(\Sigma_{i,j_n}^{G} = 0\) hold, then all satellites are considered operational, and the navigation field is deemed reliable.
- Detected errors: If at least one satellite \(j_n\) satisfies \(\Sigma_{i,j_n}^{H} \neq 0\) or \(\Sigma_{i,j_n}^{G} \neq 0\), then this satellite is considered suspicious and is excluded from further navigation calculations.
Example of Matrix Interpretation:
| Satellite | \(j_1\) | \(j_2\) | \(j_3\) | Column Sum \(\Sigma_{i,j_n}^{H}\) |
|---|---|---|---|---|
| \(j_1\) | - | 0 | 1 | 1 |
| \(j_2\) | 0 | - | 1 | 1 |
| \(j_3\) | 1 | 1 | - | 2 |
Analysis of Table Data:
- For satellite \(j_1\): \(\Sigma_{i,j_1}^{H} = 1\)
- For satellite \(j_2\): \(\Sigma_{i,j_2}^{H} = 1\)
- For satellite \(j_3\): \(\Sigma_{i,j_3}^{H} = 2\)
If the matrix \(G_i\) (not shown) has all zero sums (\(\Sigma_{i,j_n}^{G} = 0\)), then satellite \(j_3\) is the most likely to be erroneous and is excluded.
Integrity Control Algorithm:
- Start of the integrity control algorithm.
-
For each base station \(i\):
- Form the \(H_i\) matrix based on pseudorange corrections
- Form the \(G_i\) matrix based on pseudovelocity corrections
- Compute the column sums \(\Sigma_{i,j_n}^{H}\) and \(\Sigma_{i,j_n}^{G}\)
-
Decision-making:
- If all satellites satisfy \(\Sigma_{i,j_n}^{H} = 0\) and \(\Sigma_{i,j_n}^{G} = 0\), they are considered reliable
- If any satellite has a nonzero sum, it is marked as erroneous and excluded
- End of the integrity control algorithm. The final navigation solution is computed using only the remaining reliable satellites.
5. Final Conclusions: Achieving Accuracy through Analysis
- 📌 Differential corrections compensate for common errors, increasing accuracy
- 📌 Integrity control identifies erroneous data, ensuring reliability
- 📌 Reliability matrices objectively assess measurement quality
6. Questions for Students: Check Your Understanding
- Why is it impossible to rely on raw GNSS data without analysis?
- How does the atmosphere affect measurements, and how do corrections help?
- What other integrity control methods exist (e.g., RAIM)?
💬 Advice from Andrew: Be the quality controller in the satellite "choir"! Check each "voice" to achieve the "pure sound" of accurate navigation. "Trust, but verify!" Good luck!
Day 8: Generation of Corrections to the Time Scale
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
1. Introduction: Why Do We Need Time Corrections?
Andrew starts the lecture with a question:
"What do you think will happen if the clocks on satellites and ground stations differ by even a few nanoseconds?"
Some students shrug, but one replies: "There will be errors in determining coordinates?"
Andrew nods: "Correct! If the time scale of a navigation system deviates, the error in coordinate calculations can reach several meters, and in extreme cases, even kilometers. For high-precision navigation, this is unacceptable. That's why we generate corrections to the time scale to ensure all clocks in the system run in sync."
Today's lecture will cover:
- ✓ Why do different time scales exist?
- ✓ What mathematical methods are used to calculate and compensate for these discrepancies?
- ✓ How are corrections practically generated to align time scales in navigation systems?
2. Time Scales and Their Discrepancies: Why Don't Clocks Sync?
2.1. What Time Scales Are Used in Navigation?
Andrew draws a schematic representation of time scales on the board:
Time Scales of GPS, GLONASS, and UTC (Linear Scale)
Time Scale: ------------------------------------------------------------------->
GPST: |---------------------|---------------------|---------------------|-------
| | | |
1980.01.06 1990 2000 2020 Present Time
GPS Time (GPST)
GLONASST: |---------------------|---------------------|---------------------|-------
| | | |
Linked to UTC 1990 2000 2020 Present Time
GLONASS Time (GLONASST)
UTC: |---------------------|---------------------|---------------------|-------
| | | |
Universal Time 1990 2000 2020 Present Time
UTC (Coordinated Universal Time)
Why are these scales different?
- ✓ Different atomic clock references
- ✓ Signal transmission delays
- ✓ Relativity effects (General Relativity)
Solution: Apply corrections to align time scales.
3. How Are Time Scale Corrections Generated?
3.1. Mathematical Model for Time Corrections
Andrew explains the mathematical model behind time corrections:
The equation for time corrections is given as:
Explanation of terms:
- \(S^{[10]}\) – Measured time signal parameters
- \(R\) – Calculated satellite distances
- \(A\) – Correction coefficient matrix
- \(\Delta \tau_1, \ldots, \Delta \tau_L\) – Time scale differences
- \(K_{\text{GLONASS}}\) – Factor accounting for GLONASS-GPS difference
- \(\Delta \tau_{\text{GLONASS}}\) – GLONASS system time offset
3.2. Solving the Equation
To find time corrections \(\Delta \tau\), we solve the system:
Key components:
- \(c\) – Speed of light (299,792,458 m/s)
- \(V^{-1}\) – Inverse covariance matrix
- \(W\) – Weight matrix that adjusts for data quality
3.3. How Is Accuracy Verified?
If any diagonal element of \(V^{-1}\) exceeds \(10^8\), that parameter is considered unreliable and remains unchanged.
4. Practical Example
Let's consider a simple case with 2 stations and GPS/GLONASS:
Given:
- Station 1 time offset: \(\Delta \tau_1\) (unknown)
- Station 2 time offset: \(\Delta \tau_2\) (unknown)
- GLONASS system offset: \(\Delta \tau_{\text{GLONASS}}\) (unknown)
- Measured pseudoranges contain timing errors
The system solves for all three unknowns simultaneously, ensuring consistent time across the network.
5. Discussion and Student Questions
After the lecture, students start asking questions:
Michael: "If GPS satellites have atomic clocks, why do we still need to correct them?"
Andrew: "Great question! Even atomic clocks, which are incredibly precise, experience drift over time due to relativistic effects—changes in time caused by speed and gravity, as described by Einstein's theory of relativity. For instance, GPS satellites move at about 14,000 km/h (3.9 km/s), causing their clocks to slow down by around 7 microseconds per day due to special relativity. At the same time, they're 20,200 km above Earth, where gravity is weaker, making the clocks run faster by about 45 microseconds per day due to general relativity. Combined, this results in a net drift of 38 microseconds per day. Since radio signals travel at the speed of light (299,792,458 m/s), that 38 microseconds translates to a position error of about 11.4 km per day! Additionally, environmental factors like solar radiation, temperature changes, and magnetic fields in space can cause minor clock shifts. That's why we need to constantly apply corrections to keep GPS accurate."
Anna: "Can we use quantum clocks in satellites to make corrections unnecessary?"
Andrew: "That's a forward-thinking question! Quantum clocks are a cutting-edge technology—unlike the cesium atomic clocks in GPS, which are accurate to about 1 nanosecond per day, quantum clocks use optical transitions in atoms like ytterbium and can be accurate to 1 second over billions of years. They're incredibly promising for improving timekeeping! However, they won't eliminate the need for corrections entirely. The relativistic effects I mentioned—caused by the satellite's speed and Earth's gravity—still apply, no matter how precise the clock is, requiring those 38 microseconds per day adjustments. Plus, quantum clocks aren't yet practical for large-scale deployment in satellites. They require complex setups, like ultra-low temperatures and significant power, which are hard to manage in a satellite's compact environment. But in the future, they could reduce how often we need to sync clocks, making systems even more reliable."
Daniel: "How does NASA handle time correction for Mars missions where there are no GPS satellites?"
Andrew: "Excellent question! For Mars missions, NASA can't rely on GPS because there's no satellite network like Earth's. Instead, they use a combination of techniques. First, spacecraft carry their own ultra-stable atomic clocks, similar to those in GPS, and correct for relativistic effects based on their orbit and Mars' gravity—Mars' weaker gravity (about 38% of Earth's) causes a different time dilation effect, around 0.6 milliseconds per day less than on Earth. Second, NASA uses the Deep Space Network (DSN)—a global array of radio antennas—to send precise time signals from Earth and track the spacecraft's position with two-way ranging. This allows them to calculate time offsets with an accuracy of microseconds. Finally, for surface rovers like Perseverance, they sync with orbiting Mars satellites (e.g., Mars Reconnaissance Orbiter), which provide local navigation data. It's a complex dance, but it works!"
Sophia: "Could future laser clocks in deep space eliminate the need for time corrections?"
Andrew: "That's a fantastic forward-looking question! Laser clocks, such as those being developed by NASA and ESA, use optical lattice techniques to achieve even greater precision than quantum clocks. They rely on stabilized laser frequencies interacting with atomic transitions, achieving accuracies far beyond what is possible with traditional atomic clocks. However, even with their precision, they can't eliminate the need for time corrections. The fundamental reason remains the same—relativistic effects. The motion of a spacecraft and variations in gravitational potential will still cause shifts in time, meaning corrections will always be necessary. That said, laser clocks could significantly improve the stability of deep-space navigation, reducing the need for frequent adjustments."
6. Conclusion: Why Is This Important?
Andrew concludes the lecture:
- 📌 Navigation accuracy depends on precise time correction
- 📌 Generating corrections ensures synchronization between GPS and GLONASS
- 📌 Mathematical methods minimize errors and maintain system integrity
Discussion Questions:
- ✓ Why can't we trust raw GPS time without verification?
- ✓ How does relativity impact clock synchronization?
- ✓ Could laser communication improve timing accuracy?
Andrew smiles: "We'll discuss these topics in more detail in the next lecture. See you then!"
Day 9: Formation of Differential Correction Data and Quality Control
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Introduction
Greetings, inquisitive minds! Welcome to Day 9 of our exciting course! We find ourselves in the year 2003, and today we will dive into the heart of satellite navigation to thoroughly study the process of forming differential correcting information (DCI) and the methods of controlling its highest quality. Imagine you are using a GPS navigator in your car or on a research vessel, and it determines your location with an accuracy of a few meters! Behind this technology, already changing our lives, lies a complex symphony of mathematical algorithms and fundamental laws of physics. Our goal today is to reveal these secrets step by step, guiding you through the labyrinth of formulas to the summit of understanding. Are you ready for new intellectual discoveries? Then let's go, onward to knowledge!
Historical Reference: How Accuracy Became Reality
Before delving into the technical details, let us take a brief historical excursion. The GPS system officially began with the launch of the first Navstar 1 satellite in 1978, starting a global navigation revolution. However, the early days of GPS were far from perfect: atmospheric delays and the drift of atomic clocks on the satellites reduced accuracy to tens of meters. In the 1980s, engineers developed Differential GPS (DGPS), significantly improving accuracy—to just a few meters. By the early 1990s, DGPS was widely used in marine navigation and geodesy. In 1995, GPS achieved full operational capability, and in 2000 the United States disabled Selective Availability (SA), making the signal more accurate for civilian users. Today, in 2003, we see how GPS and GLONASS are beginning to change the world, from marine navigation to the first automotive GPS systems!
9.1. Calculating Differential Corrections in Telemetry Navigation Information
So, the starting point of our journey is the interaction between navigation space vehicles (NSV)—GPS, GLONASS, INMARSAT satellites—and receiver-navigation stations (RNS) on Earth. NSVs emit signals, and RNS units capture them. But these signals are far from ideal: the atmosphere distorts them, and even though the satellites' atomic clocks are very precise, they still have microscopic deviations. Differential corrections are our tool to say, "Enough chaos! Let's fix this navigation confusion!"
The process of computing DCI in telemetry navigation information (TNI) is akin to tuning an orchestra before a concert: a strict algorithm synchronizes all the elements to within fractions of a millisecond, ensuring the harmonious 'sound' of accurate navigation.
9.2. Forming Estimates of Differential Corrections
Imagine a coordinated team of satellites (NSV) and ground stations (RNS) working in unison. For each satellite-station pair, we calculate corrections, referencing the GPS time scale (GPST). Why GPST? Historically, it serves as the established reference, providing a single point of reference. A key factor is the signal's passage through the troposphere and ionosphere, where charged particles and water vapor act like "traffic jams," delaying radio waves and introducing errors. Here are the formulas that help us compensate for these effects:
For pseudoranges (distances measured to the satellite, including errors):
For pseudospeeds (the rate of change of distance):
Let us break down what is happening here:
- \(S^{[2]}\) — a vector of measured pseudoranges corrected for atmospheric distortions using the coefficients \(\alpha_{i,j}\). Think of these coefficients as "atmospheric glasses," allowing the signal to "see" through interference!
- \(\dot{S}^{[2]}\) — a vector of pseudospeeds, also corrected.
- \(R\) and \(\dot{R}\) — the ideal distances and speeds computed from coordinates: \(R_{i,j} = \sqrt{(x_j - X_i)^2 + (y_j - Y_i)^2 + (z_j - Z_i)^2}\).
- \(A\) — the geometry matrix describing the positioning of satellites and stations. In a real system, its dimensionality is determined by the number of NSV-RNS pairs (\(L \times L\)).
- \(K_{\text{GLONASS}}\) — a coefficient for taking into account GLONASS-specific features (1 for GLONASS, 0 for GPS), reflecting differences in time scales.
- \(\Delta \tau_i\) and \(\Delta \dot{\tau}_i\) — time and frequency corrections for clock synchronization.
These formulas are a navigation puzzle! We solve it using the least squares method, minimizing errors.
9.3. Smoothing Estimates of Differential Corrections
Having obtained the "raw" estimates, we smooth them out, taking into account the registration time \(t_{z-count}\):
where
Here, \(t_1\) is the time in seconds, which we break down into hours and a remainder, rounding with a 0.6-second step—like setting an alarm with a convenient interval! \(\frac{R_{i,j,k}}{c}\) is the signal transit time (\(c = 299,792,458 \,\text{m/s}\)).
Numerical example: Let \(\Delta S_{i,j,k} = 10 \,\text{m}\), \(\Delta \dot{S}_{i,j,k} = 0.1 \,\text{m/s}\), and \(\left(t_{z-count} - (t_i - \Delta \tau_i - \frac{R_{i,j,k}}{c})\right) = 2 \,\text{s}\). Then:
9.4. Analysis and Quality Control of Corrections
Now let's check the quality! If we have only one estimate from an RNS, we accept it with \(Health_{i,j} = 0\) and a standard deviation \(\sigma_{i,j,k}\). But if two or more estimates are available, we conduct a statistical analysis. We calculate the standard deviation:
where the weighted mean is:
For speeds, it is analogous:
Numerical example: Suppose the estimates are \(\Delta \hat{S}_{1,j,k} = 10\,\text{m}\), \(\Delta \hat{S}_{2,j,k} = 11\,\text{m}\), \(\Delta \hat{S}_{3,j,k} = 12\,\text{m}\), and \(\zeta S_{i,j,k} = 0\). Then:
The "10−10 secret": This coefficient in the denominator is a "lifeline." If \(\sigma S_{i,j,k,2} = 0\), then \(10^{-10}\) prevents division by zero—like a shim under a wobbly chair!
We compare \(\sigma_{\Delta \hat{S}_{j,k}}\) with the threshold \(\sigma_{\max \Delta S}\). If \(\sigma_{\Delta \hat{S}_{j,k}} < \sigma_{\max \Delta S}\), the corrections are reliable (\(Health_{j,k} = 0\), \(\zeta S_{i,j,k} = 0\)). If we detect anomalies (\(\left|\Delta \hat{S}_{i,j,k} - \Delta \bar{S}_{j,k}\right| > 2 \cdot \sigma_{\Delta \hat{S}_{j,k}}\)), we set \(\zeta S_{i,j,k} = 1\) and repeat the analysis.
9.5. Checking Acceptable Value Limits
We verify that the corrections do not exceed physical limits:
Why these values?
- 10,485.44 m: The threshold is based on typical maximum errors, including ionospheric delays and clock offsets up to 3 ms (\(3 \times 10^{-3} \times 299,792,458 \approx 899,377 \,\text{m}\)). Factoring in filtering and system constraints, the maximum is 10,485.44 m.
- 4.064 m/s: Approximately the speed of a walking human. If the speed correction is larger, the satellite is "running away" unphysically!
If the condition is not met, \(Health_{j,k} = 1\) — that satellite is marked as unhealthy.
9.6. Additional Control with a Monitoring Receiver
A monitoring receiver (MR) with known coordinates is our "golden standard." We use the Newton-Gauss method to verify the corrections:
Newton-Gauss iterations example:
- Step 1: Initial approximation: \(\overrightarrow{\widetilde{\Theta}}_0 = [0, 0, 0, 0, 0]^T\)
- Step 2: First iteration: \(\Delta \overrightarrow{\widetilde{\Theta}}_1 = [100 \,\text{m}, 50 \,\text{m}, 200 \,\text{m}, 0.001 \,\text{s}, 0.0001 \,\text{s/s}]^T\), error: \(\sqrt{100^2 + 50^2 + 200^2} = 229.1 \,\text{m}\)
- Step 3: Second iteration: \(\Delta \overrightarrow{\widetilde{\Theta}}_2 = [10, 5, 20, 0.0001, 0.00001]^T\), error: 22.9 m
- Step 4: After 5 iterations: \(\Delta \overrightarrow{\widetilde{\Theta}}_5 = [0.005, 0.002, 0.008]^T\), error: \(\sqrt{0.005^2 + 0.002^2 + 0.008^2} \approx 0.0095 \,\text{m} < \varepsilon_{\Theta} = 0.01 \,\text{m}\). Stop! Accuracy achieved: 0.95 cm!
Lecture Conclusion
You have learned how differential corrections turn "noisy" signals into accurate coordinates, as if assembling a puzzle from thousands of measurements. In 2003, DCI was already actively used in marine navigation (for example, for precise vessel positioning), in geodesy for map creation, and in the first automotive GPS navigators from companies like Garmin and Magellan, just starting to appear in cars. These technologies pave the way to a future where satellite navigation will become an integral part of our lives.
Question to Ponder: What happens to accuracy if the ionosphere increases its influence (e.g., due to a solar flare)? What measures can be taken? Until next time in the world of science and technology!
Glossary
- Pseudorange
- The measured distance to a satellite, including errors
- Pseudospeed
- The rate of change of that pseudorange
- Relativistic effects
- Changes in time due to gravity and velocity (Einstein's theory). Atomic clocks on satellites (rubidium/cesium, stability \(10^{-13}\)) correct for these effects
- NSV
- Navigation Space Vehicles: GPS, GLONASS, INMARSAT satellites
- RNS
- Ground tracking stations (Receiver-Navigation Stations)
- \(\varepsilon_{\Theta} = 1\,\text{cm}\)
- The accuracy target for the Newton-Gauss method
- Newton-Gauss method
- An iterative method for coordinate refinement
Day 10: Message Formation for Transmission to the CKNPU
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
How to Talk to Satellites so the CKNPU Understands
A hands-on engineer's lecture. No fluff. Only structure, logic, and engineering insight.
Introduction
Good afternoon, colleagues.
Today's topic is not just about data transfer. It is about how to build a dialog between a measurement network and a central node—a dialog that leaves no room for misunderstanding, a dialog where each message is a brick in the edifice of precision navigation.
📡 Context
We operate a Control and Correction Station (CCS) running in real time, built on synchronous measurements. It sees satellites, measures, filters, and forms messages. Everything that happens is formalized thinking turned into a binary structure.
On the other end is the Central Kalman Navigation-Processing Node (CKNPU). Its job is to gather every piece of the mosaic, process it, make decisions, and refresh the navigation picture for everyone.
✉️ Message Exchange: Good Engineering Postal Style
We transmit not just bits. We send messages with clear labeling, guaranteed synchronization, and strict processing logic. This is not a stream of consciousness. This is a system. This is... a concentrator.
Messages are letters: each with its envelope, address, and content. The CKNPU is not a mind reader. It understands only when everything is by the book, by the standard, at the right moment—discarding anything not validated by the mask.
📋 Message Types
At our disposal are 64 message types (0–63). Yet, in true engineering fashion, we use only those that have proven their necessity.
🛰 Type 1 — NKA Mask
Who is on the line? The message says: "Here is the list of satellites I see and trust." All other messages depend on it. It is like a meeting attendee list: if you're not on the list, you have no voice. The CKNPU relies on this list when processing all subsequent data.
📐 Types 2–5 — Code Measurements
Raw, cleaned, processed, and smoothed data.
- Pseudorange
- Pseudovelocity
- Total carrier phase
- Quality indicators
And all of it is bound to the NKA mask.
🔧 Types 7–10 — Phase Measurements
High-precision data on L1 and L2. Centimeter-level measurements—exactly what you need for landing an aircraft in fog.
🌤 Types 30–32 — Atmosphere, Station Coordinates, Status
Weather, CCS coordinates, and its internal status—everything required for correct data interpretation.
📊 Normalization: How to Fit Giants into a Pocket
Pseudorange can be tens of millions of meters. Sending directly? Impossible. We scale it. Multiply by a coefficient, drop the fraction. Everything becomes integers:
normalized_value = floor(physical_value × coefficient)
Each bit knows its place. Not a single extra byte.
🔄 Synchronization — The Heart of Transmission
The NKA Mask is the main actor. Every message carries a mask issue identifier. It tells the CKNPU: "This data belongs to the satellite set captured in mask #2."
Mismatch — data are ignored. Change the actors but keep the old script, and the play will fall apart.
📦 Transmission Cycle — A Day in the Life of a Station
- Determine visible satellites. The CCS figures out who is visible and usable.
- Send the NKA Mask (Type 1). "Today we're working with GPS-5, GPS-12, and GLONASS-3."
- Transmit measurements (Types 5, 9, etc.). Every second—updates tightly bound to the mask.
- The CKNPU receives. Sorts, filters, applies differential corrections.
🌍 Why It Matters
You are not merely transmitting data. You are building trust between the network and the center. You make sure that:
- millions of passengers land on time;
- the tractor holds its line perfectly straight;
- surveyors distinguish hills from houses with centimeter precision.
And all that—thanks to one well-designed messaging system.
🎓 Finale
Someone might say, "It's just packets of data."
We know: it's an engineering dialog where every bit matters.
And it is you—engineers—who make this dialog possible.
Let's sum up, said Andrew:
The CKNPU system is not just an architecture; it is a sophisticated mathematical engine, implemented at the application level of an information concentrator in a priority-based messaging network. These solutions ran in computing systems that operated for years without a restart, delivering and processing messages in real time. Reliability was achieved not by abstraction, but by engineering discipline, where every message was the result of meticulously crafted logic.
We call this the "Ukrainian algorithm."
(Pause. A few seconds of silence. The audience rises. Applause swells—first reserved, then louder. Not for the oratory, but for the precision, for the engineering truth.)
Until next time. We'll talk about how these messages become coordinates—and how not to lose precision in a digital world.
Day 11: Forming Messages in RTCM SC-104 Format
Lecturer: Dr. Andrew, Senior Researcher, Navigation Systems Laboratory
Date: March 2003
Part 1: Forming Messages in RTCM SC-104 (up to 2003)
Topic: Forming Messages in the RTCM SC-104 Format
Goal: Study the structure, message types, and application of the RTCM SC-104 format up to 2003.
Introduction
Andrew: Good afternoon, dear students! Today we will dive into the world of satellite navigation and examine the RTCM SC-104 format — the international standard that, in the late 1980s and 1990s, helped make GPS more accurate. Imagine it as a "letter with instructions" for GPS receivers, describing corrections to improve accuracy from 10 meters down to 1 meter. We will study its structure, the key message types, and examples of its application up to 2003. In the second part of the lecture, we will move on to what happened to this standard after 2004.
Brief conclusion: RTCM SC-104 is the basis of differential GPS correction up to the early 2000s.
General Structure of RTCM SC-104 Messages
Andrew: All messages in the RTCM SC-104 format are built on the same principle and are transmitted in 30-bit words. This ensures standardization and simplifies data processing. Each message begins with two standardized header words, followed by an information section whose content depends on the message type. Think of the message as a parcel: the header is the address and the stamp, while the content is the correction data.
| Word | Parameter | Bits | Range | Description |
|---|---|---|---|---|
| 1 | Preamble | 8 | 01100110 |
"Hello, I am an RTCM message!" |
| Message Type | 6 | 1–64 | Indicates what is inside (e.g., corrections) | |
| Station ID | 10 | 0–1023 | Number identifying the station | |
| Check Bits | 6 | — | Checksum for error checking | |
| 2 | Modified Z-count | 13 | 0–3599.4 s | Start time of the frame (0.6 s step) |
| Sequence Number | 3 | 0–7 | Order in the message chain | |
| Frame Length | 5 | 0–31 | Number of words in the message | |
| Station Integrity | 3 | See description | Station health status | |
| Check Bits | 6 | — | Another checksum | |
| 3–33 | Information Section | — | Depends on message type | Main data |
Andrew: Let us break down each field of the first and second words that make up the message header in more detail.
First Word:
- Preamble (8 bits, bits 1-8): Always the fixed bit sequence
01100110. It serves to identify the start of a new RTCM message by the receiver. Think of it as a "postal stamp" so the receiver knows an RTCM message has begun. - Message Type (6 bits, bits 9-14): Determines what type of information is transmitted in the message. There are many message types; values range from 1 to 64. It is like a note on the envelope saying "Urgent," "Personal," "Invoice," etc.
- Station ID (10 bits, bits 15-24): Identifies the specific reference station from which the message is being sent. Ranges from 0 to 1023, allowing over a thousand different stations.
- Check Bits (6 bits, bits 25-30): Part of the error-checking mechanism. They verify whether the data was distorted during transmission.
Second Word:
- Modified Z-count (13 bits, bits 1-13): Indicates the start time of the next frame and serves as a time reference for the parameters of the message. The step is 0.6 seconds, and its range is 0–3599.4 seconds.
- Sequence Number (3 bits, bits 14-16): Used for frame synchronization, helping the receiver track the sequence of messages, ranging from 0 to 7.
- Frame Length (5 bits, bits 17-21): Indicates the size of the message in 30-bit words. A value of "0" indicates that the frame length is 2 words (i.e., only the header).
-
Station Integrity (3 bits, bits 22-24): Conveys the operational status of the reference station:
- Values 0–5: Used by the service provider
- Value 6: No observed transmissions from the station
- Value 7: Station is not operational
- Check Bits (6 bits, bits 25-30): Another set of check bits for error checking.
Visualization (conceptual description): Imagine an RTCM SC-104 message as a train. The first "car" is the preamble (the locomotive, signaling the start). The second car is divided into sections: "Message Type," "Station ID," "Modified Z-count," etc. Cars from the third to the thirty-third are the "Information Section" (the freight cars with the useful data: corrections, coordinates, etc.). Each car ends with check bits (ensuring the cars are not lost and remain intact).
Example: A message starts with the bit sequence 01100110 000001 (preamble + message type "GPS Differential Corrections" – Type 1). It is like an address on a parcel, stating that it contains GPS corrections.
Brief conclusion: RTCM SC-104 messages have a strict and clear structure, enabling reliable data transmission and correct interpretation by the receiver.
RTCM SC-104 Message Types
Andrew: The RTCM SC-104 format supports up to 64 different message types. Each type is intended for transmitting a particular type of information. Let us examine the most important message types that were actively used up to 2003.
| Type | Content | Usage |
|---|---|---|
| 1 | GPS Differential Corrections | Improves GPS positioning accuracy |
| 3 | Reference Station Position in WGS-84 | Transmits station coordinates |
| 5 | GPS Integrity Information | Monitors and evaluates the health of GPS satellites |
| 18 | Uncorrected Carrier Phase Measurements | High-precision geodesy, scientific research |
| 19 | Uncorrected Pseudorange Measurements | Accurate distance measurements |
Detailed Review of Key Message Types
Type 1: GPS Differential Corrections
Andrew: Type 1, "GPS Differential Corrections," is, without exaggeration, the "workhorse" of the RTCM SC-104 standard. This message type is used to transmit differential corrections that significantly improve GPS positioning accuracy.
| Parameter | Bits | Range | Step | Description |
|---|---|---|---|---|
| Scale Factor (FS) | 1 | 0–1 | — | Indicates the corrections scale |
| UDRE | 2 | 0–3 | See table below | User Differential Range Error |
| Satellite ID (IDS) | 5 | 1–32 | — | GPS satellite number (PRN) |
| PRC | 16 | ±655.34 m or ±10485.44 m | 0.02 m or 0.32 m | Pseudorange Correction |
| RRC | 8 | ±0.254 m/s or ±4.064 m/s | 0.002 m/s or 0.032 m/s | Range Rate Correction |
| IOD | 8 | — | — | Issue of Data identifier |
Key parameters explained:
-
UDRE (User Differential Range Error): A two-bit field indicating the estimated reliability and accuracy of the differential correction:
- 0: UDRE ≤ 1 m (Highest accuracy)
- 1: 1 < UDRE ≤ 4 m (High accuracy)
- 2: 4 < UDRE ≤ 8 m (Medium accuracy)
- 3: UDRE > 8 m (Low accuracy)
-
Scale Factor (FS): Defines the scale for pseudorange (PRC) and range rate (RRC) corrections:
- FS = 0: PRC step = 0.02 m, RRC step = 0.002 m/s (High accuracy, smaller range)
- FS = 1: PRC step = 0.32 m, RRC step = 0.032 m/s (Lower accuracy, larger range)
- PRC (Pseudorange Correction): A 16-bit field with the differential pseudorange correction value. Example: If FS = 0 and PRC = 100, then the correction is 100 × 0.02 m = 2 m.
Practical Example: In 1995, surveyors actively used Type 1 messages for high-precision land measurements. Using differential corrections of Type 1 improved GPS positioning accuracy from about 10 meters to around 1 meter or better, opening new possibilities for cadaster work and land management.
Type 3: Reference Station Position in WGS-84
Andrew: Type 3 is for transmitting the precise coordinates of the reference station antenna in the WGS-84 geocentric coordinate system.
| Parameter | Bits | Step (m) | Range (m) |
|---|---|---|---|
| X Coordinate | 32 | 0.01 | ±21,474,836.47 |
| Y Coordinate | 32 | 0.01 | ±21,474,836.47 |
| Z Coordinate | 32 | 0.01 | ±21,474,836.47 |
Practice Assignment
Andrew: To consolidate the material, here is a small practical task.
Task: Suppose you received the following start of an RTCM SC-104 message of Type 1:
- Preamble:
01100110 - Message Type:
000001(Type 1 – GPS Differential Corrections) - Z-count (modified): binary
0011111010000, corresponding to the decimal value 1008 - Scale Factor (FS) = 0 (from the information section)
- Pseudorange Correction (PRC): binary corresponding to the decimal value 50
- Satellite ID (IDS) = 5, which corresponds to PRN 5
Question: Based on these data, calculate the pseudorange correction in meters.
Solution:
- FS = 0 means the PRC step is 0.02 m.
- The PRC value is 50.
- Pseudorange correction = PRC × step = 50 × 0.02 m = 1 m.
Answer: The pseudorange correction for PRN 5 is 1 meter.
Self-Check Questions (Part 1)
- What does the modified Z-count in RTCM SC-104 messages represent? Calculate the modified Z-count value in bits for a time of 1200 seconds.
- Why are there check bits in every word of an RTCM SC-104 message? Provide an everyday analogy where data integrity control is used.
- How do you calculate the pseudorange correction (PRC) for a Type 1 message if FS=1 and the PRC value in bits corresponds to decimal 200? Indicate the scale step and the units.
- How do you determine the geographic coordinates of a reference station from a Type 3 message if the X-coordinate in bits corresponds to decimal 100000? Indicate the scale step and the units.
- What does an SNR (signal-to-noise) value of 40 dBHz mean in a Type 5 "GPS Integrity Information" message? What range of SNR values is typical for Type 5 messages?
Part 2: Evolution of RTCM SC-104 from 2004 to the Present
Goal: Study the evolution of RTCM SC-104 after 2003 and its replacement by modern standards.
Introduction
Andrew: We have examined the RTCM SC-104 format in detail as it was used up to the early 2000s. However, technology does not stand still, and by 2004 it became clear that RTCM SC-104 was becoming obsolete. A need arose for a more accurate, compact, and universal standard, one that could support new satellite systems such as GLONASS and offer higher positioning accuracy. Imagine: if RTCM SC-104 is a reliable but outdated paper map, then RTCM 3.x is a modern smartphone GPS navigator with constantly updated maps and traffic information.
Transition to RTCM 3.x and Modern Standards
Andrew: Starting in 2004, the more advanced RTCM 3.x standard (including various versions like RTCM 3.0, 3.1, 3.2, 3.3) replaced RTCM SC-104. RTCM 3.x became the main standard for transmitting differential corrections and other GNSS data.
| Parameter | RTCM SC-104 (up to 2003) | RTCM 3.x (from 2004) | Comment |
|---|---|---|---|
| Correction Accuracy | 0.02 m step (Type 1) | Up to 0.001 m or better | 20+ times more accurate! |
| GLONASS Support | Limited, via Type 31 | Full support, same as GPS | Universal. Supports all modern GNSS |
| Message Size | Up to 33 (30-bit) words | More compact binary format | Efficiency. Smaller data volume |
| Extensibility | Limited, fixed message types | Flexible, modular | Adaptability. Easy to add new types |
| Compatibility | GPS-oriented | Multi-GNSS (GPS, GLONASS, Galileo, BeiDou) | Modern Systems. Multi-constellation support |
Andrew: As the comparison table shows, RTCM 3.x is a significant step forward compared to RTCM SC-104. The improvements cover almost every key characteristic of the standard.
Practical Example: In the 2010s, with the proliferation of drones, the RTCM 3.x standard played a key role in providing highly accurate navigation. Drones using RTCM 3.x for differential corrections can achieve centimeter-level accuracy—essential for aerial photography, mapping, and precision agriculture. RTCM SC-104 could not offer that level of accuracy and functionality.
Modern Use of RTCM Standards
Andrew: Today, RTCM SC-104 has been almost entirely phased out. Modern GNSS receivers, software, and differential correction services are geared toward RTCM 3.x standards. However, it is important to note that the principles laid out in RTCM SC-104 formed the foundation for developing RTCM 3.x and other modern GNSS data transmission protocols.
Case: Imagine you are an engineer in a company developing precision agriculture systems. To achieve centimeter-level accuracy in controlling agricultural machinery, you must use RTK (Real-Time Kinematic) or PPK (Post-Processed Kinematic) technologies. In both cases, differential correction data is transmitted in RTCM 3.x format. Using RTCM SC-104 in modern precision agriculture would be inefficient and would not meet the required accuracy and functionality.
Practice Assignment (Part 2)
Andrew: To better understand the difference in efficiency between RTCM SC-104 and RTCM 3.x, let us solve the following problem:
Task: Calculate and compare the approximate volume of data required to transmit differential corrections for 8 GPS satellites using:
- RTCM SC-104, Message Type 1: Assume that sending corrections for one GPS satellite in Type 1 requires an average of 32 bits (information part only, excluding the header). Calculate the total data volume for 8 satellites, adding the size of the RTCM SC-104 header (the first two words).
- RTCM 3.x: Assume that RTCM 3.x can transmit the same data for these 8 satellites in half the size because of more efficient binary formatting and encoding. Calculate the data volume for RTCM 3.x.
- Evaluate the savings in bits and percentage when using RTCM 3.x compared to RTCM SC-104.
Solution:
-
RTCM SC-104:
- Information for 8 satellites: 8 × 32 bits = 256 bits
- Header size (2 words × 30 bits/word) = 60 bits
- Total RTCM SC-104 data volume: 256 + 60 = 316 bits
-
RTCM 3.x: Assumed 2 times more compact:
- 316 bits / 2 = 158 bits
-
Savings:
- Bit savings: 316 - 158 = 158 bits
- Percentage savings: (158 / 316) × 100% = 50%
Answer: Using RTCM 3.x in this example reduces the data volume by about 50% compared to RTCM SC-104, a significant advantage in bandwidth-limited transmissions.
Self-Check Questions (Part 2)
- Why did RTCM SC-104 become outdated and get replaced by RTCM 3.x? List the main drawbacks of RTCM SC-104 in the context of modern GNSS requirements.
- How did the RTCM 3.x standard improve the accuracy of differential corrections compared to RTCM SC-104? Provide examples of quantization steps for corrections in both standards.
- Name three examples of modern systems and technologies that actively use the RTCM 3.x standard for GNSS data transmission.
- What are the key differences in GLONASS support between RTCM SC-104 and RTCM 3.x? How does RTCM 3.x achieve multi-GNSS compatibility?
- How does a more compact RTCM 3.x message format affect transmission speed and overall GNSS system efficiency? Describe the benefits of compact data transmission in modern applications.
Discussion with Interested Students
Andrew: Now let us move on to a discussion and consider some questions that will help connect the material to real-world applications and modern trends in GNSS technology.
Question 1: In which areas of autonomous systems could RTCM SC-104 have been used before 2003, despite its limitations compared to modern standards? Provide examples and justify your opinion.
Answer (option): Even though RTCM SC-104 provided about 1-meter positioning accuracy, which is not very high by modern standards, it could have been used effectively in early autonomous systems where that level of accuracy was sufficient. For instance, in the first experimental autonomous vehicles from the 1980s and 1990s, RTCM SC-104 might have been utilized for basic GPS correction, enabling lane-keeping and rudimentary navigation. Another example could be early agricultural systems or some forms of land monitoring, where a meter-level accuracy was enough to perform simpler tasks.
Question 2: Why do you think RTCM 3.x became the de facto standard for modern high-precision GNSS instead of some other format? Which key advantages allowed RTCM 3.x such widespread adoption?
Answer (option): RTCM 3.x has become the leading high-precision GNSS standard due to several key advantages:
- High accuracy: Supports more precise corrections, down to centimeter-level accuracy.
- Multi-GNSS compatibility: Complete support for major constellations (GPS, GLONASS, Galileo, BeiDou), making it universal.
- Compactness and efficiency: Binary format and efficient encoding methods produce smaller messages and faster data transfer.
- Flexibility and extensibility: A modular structure and new message types allow the standard to evolve and adapt to new technologies.
- Wide industry support: Backed by RTCM (Radio Technical Commission for Maritime Services), an authoritative international body, and supported by GNSS equipment manufacturers and software developers worldwide.
Question 3: Are there current use cases where RTCM SC-104 might still be justified, despite being outdated? Provide examples, if any.
Answer (option): In today's high-precision GNSS environment, RTCM SC-104 use cases are extremely limited. However, one might find certain niche or legacy scenarios where it could still be acceptable or even advantageous, for instance:
- Obsolete systems: Some older monitoring or control systems introduced in the 1990s or early 2000s might still operate with hardware that only supports RTCM SC-104. Replacing it could be economically unfeasible, and maintaining SC-104 might be a temporary solution.
- Educational purposes: For teaching the fundamentals of differential GPS and correction protocols, RTCM SC-104 can be instructive due to its simpler structure compared to RTCM 3.x.
- Specialized low-dynamics, low-accuracy needs: In some niche applications where high accuracy isn't critical and movement is minimal (e.g., monitoring static objects over large areas), using RTCM SC-104 might be sufficient, especially if older, inexpensive hardware is available.
Andrew: In conclusion, although RTCM SC-104 played an important historical role in developing differential GPS, it has essentially yielded to more modern and capable standards like RTCM 3.x, offering the accuracy, reliability, and functionality required by a wide range of current GNSS applications.
Conclusion
Andrew: This concludes our lecture. Today, we examined the RTCM SC-104 format in detail: its structure, key message types, and usage up to 2003. We also looked at the standard's evolution and the transition to RTCM 3.x, the dominant standard in today's GNSS industry. I hope you found this lecture both informative and useful.
Key Takeaways:
-
RTCM SC-104 (up to 2003):
- Provided differential corrections with ~0.02 m precision (Type 1)
- Was the foundation of differential GPS in the 1990s and early 2000s
- Had limited GLONASS support and lower efficiency than modern standards
-
RTCM 3.x (from 2004 to present):
- Offers differential corrections down to ~0.001 m or better
- Is now the de facto standard for high-precision GNSS
- Provides full multi-GNSS support (GPS, GLONASS, Galileo, BeiDou, etc.), compactness, flexibility, and scalability
Andrew: Thank you for your attention and active participation. I hope the knowledge gained will be helpful in your future work and research in satellite navigation.
End of Lecture.
Reference Materials
Lectures provide the conceptual understanding necessary to master the subject, while reference materials contain detailed technical data, including formulas and structured tables. They allow for quick access and use of the required information, significantly saving time when studying satellite navigation.
Reference materials are based exclusively on publicly available sources, scientific publications, and open technical standards. They are intended for educational purposes, comply with international practices for disseminating technical information, and ensure data reliability. For accuracy verification, you can refer to the provided list of references.
Each lecture corresponds to one page of reference material, allowing students not only to study the theoretical foundation but also to delve into calculations and technical details as needed.
Why This Massive Literature List?
You are looking at a curated collection of over 160 foundational references in satellite navigation. This list is not meant to overwhelm you — it reflects the true scale of the field. If you were to study everything here from scratch, it could take a lifetime.
That’s exactly why the Ukrainian Algorithm was created: a velvet path that begins with clear, engaging, scientific lectures and leads you step-by-step to rigorous mathematical applications. The lectures build intuition; the applications bring equations. Together, they form a complete journey — from signal processing and integrity monitoring to generating precise corrections.
Once you’ve walked this path, this reference list will no longer intimidate — it will guide. This is not a wall. It’s a door. And the key is now in your hands.
Note on Attribution
These materials are provided openly, with no restrictions, licensing requirements, or obligations. The author requests no personal recognition, citation, or attribution. There is only one humble and sincere wish:
If you find value in these lectures, applications, or the mathematical foundations they provide,
please refer to them simply as part of the "Ukrainian Algorithm."
This phrase does not honor a person — it honors a way of thinking, a commitment to mathematical integrity, and a nation’s contribution to the future of global navigation.
Recommended Literature for In-Depth Study
This list complements the Ukrainian Algorithm — a structured learning path through lectures and applications — and invites you to set sail on your own.
Day 1 — The Beginning: Navigation & Precision
- Januszewski, J. (2011). Satellite Navigation Systems: Signals, Measurements, and Performance (2 ed.). Springer.
- Misra, P., & Enge, P. (2021). Global Positioning System: Signals, Measurements, and Performance (3 ed.). Ganga-Jamuna Press.
- NovAtel Inc. (2023). An Introduction to GNSS: A Primer in Using Global Navigation Satellite Systems for Positioning and Autonomy (3 ed.). Hexagon. (novatel.com)
- United Nations Office for Outer Space Affairs. (2013). Global Navigation Satellite Systems Education Curriculum. Author. (unoosa.org)
- Bhatta, B. (2021). Global Navigation Satellite Systems: New Technologies and Applications (2 ed.). CRC Press. (EU Agency for the Space Programme)
- Ceruzzi, P. E. (2018). GPS. MIT Press.
- Pike, D. (2018). The History of Navigation. Pen & Sword Maritime.
- Grewal, M. S., Weill, L. R., & Andrews, A. P. (2020). Global Navigation Satellite Systems, Inertial Navigation, and Integration (4 ed.). Wiley.
- Groves, P. D. (2013). Principles of GNSS, Inertial and Multisensor Integrated Navigation Systems (2 ed.). Artech House.
- European Union Agency for the Space Programme. (2020). GNSS User Technology Report 2020 (Issue 1). Publications Office of the EU. (EU Agency for the Space Programme)
- Langley, R. B. (1999). Dilution of precision. GPS World, 10(5), 52–59.
- Parkinson, B. W., & Spilker, J. J. (Eds.). (1996). Global Positioning System: Theory and Applications (Vol. I). AIAA.
- Petrovski, I. G., & Tsujii, T. (2012). Digital Satellite Navigation and Geophysics. Cambridge University Press.
- Basara, B. (2017). GNSS for Vehicle Control. Springer.
- Hofmann-Wellenhof, B., Lichtenegger, H., & Wasle, E. (2008). GNSS – Global Navigation Satellite Systems: GPS, GLONASS, Galileo, and More. Springer.
Day 2 — The Heart: Control Station & Data Flow
- Hofmann-Wellenhof, B., Lichtenegger, H., & Wasle, E. (2021 repr.). GNSS – GPS, GLONASS, Galileo, and More. Springer.
- Radio Technical Commission for Maritime Services. (2001). RTCM 10401.2: Standard for Differential Navstar GPS Reference Stations and Integrity Monitors. RTCM. (ge0mlib.com)
- Department of Defense. (2022). Navstar GPS Space Segment/User Segment Interfaces (IS-GPS-200 Rev N). U.S. Space Force. (gps.gov)
- Department of Defense. (2022). Navstar GPS L5 Interfaces (IS-GPS-705 Rev J). U.S. Space Force.
- Department of Defense. (2022). Navstar GPS L1C Interface Specification (IS-GPS-800 Rev D). U.S. Space Force.
- Teunissen, P. J. G., & Montenbruck, O. (Eds.). (2017). Springer Handbook of Global Navigation Satellite Systems. Springer.
- Grewal, M. S., Weill, L. R., & Andrews, A. P. (2020). Global Navigation Satellite Systems, Inertial Navigation, and Integration (4 ed.). Wiley.
- Kaplan, E. D., & Hegarty, C. J. (2020). Understanding GPS/GNSS: Principles and Applications (3 ed.). Artech House.
- European Space Agency. (2019). GNSS Data Processing, Volume I (TM-23/1). ESA Communications.
- Pennsylvania State University. (2024). GEOG 862: GPS/GNSS for the Control Segment [Course materials].
- Russian Federation Ministry of Defense. (1998). Global Navigation Satellite System GLONASS Interface Control Document (Ver. 4.0).
- European Commission & EUSPA. (2023). Galileo Open Service Signal-in-Space Interface Control Document (Issue 2.1).
- China Satellite Navigation Office. (2019). BeiDou Navigation Satellite System Signal-in-Space ICD: B1C. Author.
- Cabinet Office, Government of Japan. (2020). QZSS Interface Specification (IS-QZSS-100).
- Indian Space Research Organisation. (2017). NavIC (IRNSS) Signal-in-Space ICD (Ver. 1.1).
Day 3 — The Pipeline: Data Processing Sequence
- Strang, G., & Borre, K. (2020 repr.). Linear Algebra, Geodesy, and GPS. Wellesley-Cambridge Press.
- Leick, A., Rapoport, L., & Tatarnikov, D. (2015). GPS Satellite Surveying (4 ed.). Wiley.
- Teunissen & Montenbruck (2017). Handbook of GNSS.
- Borre, K. (2003). A Software-Defined GPS Receiver: A Simple Approach. Aalborg University Press. (gps.gov)
- Sanz Subirana, J., Juan Zornoza, J. M., & Hernández-Pajares, M. (2013). GNSS Data Processing, Volume 1: Fundamentals and Algorithms. ESA Communications.
- Petovello, M. G. (2015). Real-time GNSS signal processing. GNSS Solutions, 29(3), 43-48.
- Goltz, T., et al. (2025). GDA: GNSS Data Analysis Software (Pre-release).
- Langley, R. B. (1997). GPS receiver system noise. GPS World, 8(6), 40-45.
- European Space Agency. (2020). GNSS Data Processing, Volume II: Advanced Algorithms (TM-23/2).
- National Geodetic Survey. (2024). OPUS Projects GNSS Manual (Ver. 2.3).
- UNAVCO. (2023). TEQC Reference Manual (Rev. 2023-04).
- Takasu, T. (2024). RTKLIB Version 2.4.4 Manual. RTKLIB Consortium.
- International GNSS Service. (2023). IGS Analysis Center Guidelines (Ver. 2.0).
- Bundesamt für Kartographie und Geodäsie. (2023). Ntrip Caster Toolkit (Ver. 2.0). (rtcm.myshopify.com)
- European Space Agency. (2024). Clock and Orbit Combination Handbook (EDM-PNT-003).
Day 4 — The Cleansing: Signal Filtering
- Brown, R. G., & Hwang, P. Y. C. (2019). Introduction to Random Signals and Applied Kalman Filtering (5 ed.). Wiley.
- Gelb, A. (Ed.). (2019 repr.). Applied Optimal Estimation. MIT Press.
- Groves, P. D. (2013). Principles of GNSS, Inertial and Multisensor Integrated Navigation Systems (2 ed.). Artech House.
- Zarchan, P. (2015). Fundamentals of Kalman Filtering (5 ed.). AIAA. (unoosa.org)
- Kaplan & Hegarty (2020).
- Spilker, J. J. (1996). Modulation and demodulation. In GPS: Theory and Applications (Vol. I, pp. 121-161). AIAA.
- Borre, K., Fernández-Hernández, I., López-Salcedo, J. A., & Bhuiyan, M. Z. H. (Eds.). (2022). GNSS Software Receivers. Cambridge University Press. (Cambridge University Press & Assessment)
- Shen, Y., & Liu, X. (2024). Adaptive robust Kalman filtering for multi-GNSS integration. Sensors, 24(2), 1234-1258.
- Li, Y., Li, B., & Zhang, X. (2022). Joint estimation of observation and process noise in GNSS data processing. Remote Sensing, 14(22), 5890.
- Maybeck, P. S. (1994). Stochastic Models, Estimation, and Control (Vol. 1). Academic Press.
- Bar-Shalom, Y., Li, X. R., & Kirubarajan, T. (2001). Estimation with Applications to Tracking and Navigation. Wiley.
- Grewal, M. S., & Andrews, A. P. (2015). Kalman Filtering: Theory and Practice (4 ed.). Wiley.
- Li, X., Zhang, X., & Ge, M. (2023). Multi-GNSS phase-bias estimation with robust stochastic modelling. GPS Solutions, 27(4), 102.
- Institute of Navigation. (2022). Proceedings of ION GNSS+ 2022: Advanced Filtering Techniques.
- NavtechGPS. (2021). Kalman Filter and Integration—Annotated Bibliography. NavtechGPS.
Day 5 — The Epic: Atmospheric Corrections (I)
- Kleusberg, A., & Teunissen, P. J. G. (Eds.). (2019). GPS for Geodesy (3 ed.). Springer.
- Leick, A. (2021). GPS Satellite Surveying (5 ed.). Wiley.
- Seeber, G. (2003). Satellite Geodesy (2 ed.). de Gruyter.
- Radio Technical Commission for Maritime Services. (2021). RTCM 10415.0: Ionosphere/Troposphere Delay Models. RTCM.
- Boehm, J., Niell, A., Tregoning, P., & Schuh, H. (2006). Troposphere mapping functions for GPS processing. Journal of Geodesy, 80(7), 352-363.
- Bassiri, S., & Hajj, G. A. (1993). Higher-order ionospheric effects on the GPS observables. Journal of Geophysical Research, 98(B10), 16721-16727.
- Li, M., Zhao, Q., Li, X., & Zhang, K. (2023). Tropospheric and ionospheric modelling using multi-GNSS time series. Remote Sensing, 15(4), 1-22.
- Radicella, S. M., Nava, B., & Coïsson, P. (2008). Ionospheric models for GNSS single-frequency range delay corrections. Física de la Tierra, 20, 165-191.
- International Earth Rotation and Reference Systems Service. (2020). IERS Conventions (2020) (Chap. 9). IERS.
- International GNSS Service. (2024). Global Ionospheric Maps Products Handbook (Ver. 3.0).
- Spilker, J. J. (1996). Signal structure and performance characteristics. In GPS: Theory and Applications (Vol. II, pp. 57-119). AIAA.
- Komjathy, A. (1997). Global Ionospheric Total Electron Content Mapping Using the Global Positioning System. University of New Brunswick.
- Schaer, S. (1999). Mapping and Predicting the Earth's Ionosphere Using the Global Positioning System. University of Bern.
- Radio Technical Commission for Aeronautics. (2022). DO-229F: MOPS for GPS/SBAS Airborne Equipment. RTCA.
- European Space Agency. (2024). Navipedia: Tropospheric Delay.
Day 6 — The Epic: Atmospheric Corrections (II)
- Kleusberg & Teunissen (2019).
- Leick (2021).
- Defraigne & Baire (2011).
- European Space Agency. (2024). Navipedia: Galileo Tropospheric Model.
- Kaiser, J., & Böhm, J. (2025). Empirical modeling of tropospheric delays with uncertainty quantification. Geoscientific Model Development, 18, 1487-1512.
- Radicella, S. M., & Leitinger, R. (2001). The NeQuick ionospheric model. ESA Bulletin, 106, 54-56.
- Klobuchar, J. A. (1987). Ionospheric time-delay algorithm for single-frequency GPS users. IEEE Transactions on Aerospace and Electronic Systems, 23(3), 325-331.
- Yue, X., Schreiner, W., Kuo, Y., & Zeng, Z. (2024). Global ionospheric maps from multi-GNSS observations. GPS Solutions, 28(2), 32.
- Feltens, J. (2011). Real-time interpolation of global ionospheric maps for precise point positioning. Journal of Geodesy, 85(12), 761-770.
- Jin, S. (2023). GNSS meteorology: Recent progress and future perspectives. Advances in Atmospheric Sciences, 40(5), 731-753.
- Wang, H., & Zhao, Q. (2024). Real-time multi-GNSS tropospheric gradient estimation. GPS Solutions, 28(1), 19.
- Hernández-Pajares, M., Sanz Subirana, J., & Juan Zornoza, J. M. (2011). The NeQuick model for Galileo single-frequency users. IEEE Transactions on Geoscience and Remote Sensing, 49(10), 3375-3384.
- International GNSS Service. (2023). Ionosphere Working Group Annual Report 2023.
- Nava, B., Coïsson, P., & Radicella, S. M. (2011). Comparative study of ionospheric models for single-frequency GNSS users. Annals of Geophysics, 54(2), 189-201.
- Hernández-Pajares, M., Juan, J. M., Sanz, J., & Garcia-Rigo, A. (2018). Evolution of dual-frequency ionosphere-free GNSS processing toward multi-frequency PPP. Journal of Geodesy, 92(2), 163-179.
Day 7 — The Analysis: Deep Dive
- Kaplan & Hegarty (2020).
- Leick et al. (2021).
- Pullen, S., & Enge, P. (2017). GNSS Data Analysis and Performance Monitoring. Artech House.
- Li, B., Zhang, Z., & Miao, W. (2024). GNSS Real-Time Kinematic Positioning: Theory and Applications. Springer. (SpringerLink)
- Ochieng, W. Y. (2003). Integrity monitoring for GNSS positioning. Navigation, 50(2), 97-105.
- German Aerospace Center. (2024). GNSS Performance Monitoring Portal (Ver. 4.2).
- Gao, Y., & Chen, K. (2025). Satellite autonomous integrity monitoring using inter-satellite links. Advances in Space Research, 77(3), 612-624.
- International GNSS Service. (2024). SPS Performance Analysis Reports.
- NASA Goddard Space Flight Center. (2025). CDDIS GNSS Data and Product Archive (Release 5.0).
- Bundesamt für Kartographie und Geodäsie. (2023). NtripCaster Toolkit (Ver. 2.0).
- European Space Agency. (2021). EGNOS Performance Reports 2020.
- Sanz Subirana, J., Juan Zornoza, J. M., & Hernández-Pajares, M. (2014). GNSS Data Processing, Volume 2: Advanced Algorithms and Applications. ESA.
- Teunissen, P. J. G. (2015). Integer least-squares theory for ambiguity resolution. Journal of Geodesy, 89(6), 361-386.
- Blanch, J., Walter, T., & Enge, P. (2015). Protection level equations for advanced RAIM. Navigation, 62(4), 279-290.
- International Civil Aviation Organization. (2020). Annex 10, Volume I: Radio Navigation Aids (Amend. 90).
Day 8 — The Synchronization: Time Scale Corrections
- Defraigne & Baire (2011).
- Lewandowski & Azoubib (2020).
- International Telecommunication Union. (2022). Report ITU-R TF.2511-0: Content and Structure of Time Signals to Be Disseminated by GNSS. ITU. (ITU)
- Petit & Jiang (2008).
- Hanson (2019).
- Guier & Weiffenbach (1997).
- National Institute of Standards and Technology. (2024). One-Way GNSS Time Transfer (Technical Note 2190).
- International Earth Rotation & Reference Systems Service. (2024). Rapid UT1-UTC via GNSS.
- Matsakis, D. N. (2015). USNO GPS time operations. In ION GNSS+ 2015 Proceedings (pp. 1020-1027).
- Tavella, P., Petit, G., & Planchon, O. (2016). GNSS time transfer in the Galileo age. Metrologia, 53(2), 400-410.
- Rochat, P., Agius, D., & Bauch, A. (2014). High-performance GNSS time transfer with multi-frequency receivers. GPS Solutions, 18(2), 209-220.
- Weiss, M. A., & Sistla, A. (2021). GNSS-based time synchronization for 5G networks. IEEE Communications Magazine, 59(9), 42-47.
- Jiang, Z., Defraigne, P., & Huang, Y. (2022). Multi-GNSS PPP for time and frequency metrology. GPS Solutions, 26(2), 34.
- Bauch, A., Piester, D., & Fujieda, M. (2020). Remote comparison of atomic clocks via GNSS. Metrologia, 57(6), 065008.
- Defraigne, P. (2017). GNSS time and frequency transfer. In Springer Handbook of GNSS (pp. 1235-1279). Springer.
Day 9 — The Differential: Correcting Information
- Pullen & Enge (2020).
- Van Sickle (2023).
- Radio Technical Commission for Maritime Services. (2001). RTCM 10402.3: Differential GNSS Services. RTCM.
- Radio Technical Commission for Maritime Services. (2010). RTCM 10403.1: Differential GNSS Services, Version 3.1. RTCM. (ge0mlib.com)
- Hofmann-Wellenhof et al. (2008). Reference-station networks.
- International GNSS Service. (2024). Monitoring Working Group Reports.
- EOS Positioning Systems. (2024). SBAS Differential Correction Service White Paper.
- Hurn, J. (1993). Differential GPS Explained (Rev. 1995). Trimble Navigation.
- U.S. Coast Guard. (2000). GPS & DGPS Made Easy (3 ed.). USCG.
- RTKLIB Consortium. (2024). RTKLIB 2.4.4 Manual.
- Li et al. (2024). GNSS RTK: Theory and Applications.
- Gao & Chen (2025). Multi-constellation anomaly detection for DGPS. GPS Solutions, 29(2), 45.
- Institute of Navigation. (2025). Quarterly GPS SPS Performance Report.
- National Marine Electronics Association. (2023). NMEA 2000 Annex A: GNSS Differential Corrections.
- NovAtel Inc. (2021). PPP vs RTK: Choosing the Right Solution (White Paper).
Day 10 — The Communication: Message Formation
- Kaplan & Hegarty (2020).
- Leick (2021).
- Spilker (1996).
- International GNSS Service. (2023). Receiver Independent Exchange Format (RINEX) Version 4.00. IGS. (files.igs.org)
- Janssen, V. (2024). Understanding the RINEX format. GPS World, 35(6), 30-34.
- National Marine Electronics Association. (2022). NMEA 0183 Interface Standard (Ver. 4.11).
- Department of Defense. (2022). IS-GPS-705 Rev J: Navstar GPS L5 Interfaces.
- European Commission & EUSPA. (2023). Galileo OS SIS ICD (Issue 2.1).
- China Satellite Navigation Office. (2019). BeiDou B1C Signal-in-Space ICD.
- Russian Federation Ministry of Defense. (2016). GLONASS CDMA L3OC ICD.
- International GNSS Service. (2018). RINEX 3.04 Specification.
- Radio Technical Commission for Maritime Services. (2014). RTCM 1019: Recommended Standards for RINEX Stream.
- NASA Goddard Space Flight Center. (2025). CDDIS GNSS Data and Product Archive.
- Deutsches GeoForschungsZentrum. (2022). GFZRNX Converter Manual (Ver. 1.14).
- Ntrip Community. (2022). Ntrip Rev 1 vs Rev 2 Formats (Technical Note).
Day 11 — The Protocol: RTCM SC-104
- Radio Technical Commission for Maritime Services. (2001). RTCM 10402.3: Differential GNSS Services. RTCM.
- Radio Technical Commission for Maritime Services. (2010). RTCM 10403.1: Differential GNSS Services, Version 3.1. RTCM.
- Radio Technical Commission for Maritime Services. (2020). RTCM 10403.3: Differential GNSS Services, Version 3.3. RTCM.
- Radio Technical Commission for Maritime Services. (2021). RTCM 10410.1: Ntrip Version 2.0, Internet Streaming of GNSS Corrections. RTCM. (rtcm.myshopify.com)
- Kalafus, R. M. (1996). New RTCM SC-104 standard for differential GNSS. In Proceedings of ION GPS '96 (pp. 605-612). ION.
- Liu, H. (2018). BeiDou integration into RTCM 3 messages. In Proceedings of the China Satellite Navigation Conference 2018 (pp. 417-429). Springer.
- Talbot, N. (1996). Compact Measurement Record for RTK surveying. In Proceedings of ION GPS '96 (pp. 303-312). ION.
- Bundesamt für Kartographie und Geodäsie. (2023). Ntrip Caster Toolkit (Ver. 2.0). BKG.
- Hedling, G. (2018). RTCM SC-104 overview. RTCM Technical Presentation.
- Datta-Barua, S., & Langel, S. M. (2017). Integrity of RTCM 10403.1 for aviation applications. Navigation, 64(4), 681-699.
- IEEE Standards Association. (2015). IEEE 1278.2-2015: Distributed Interactive Simulation—Communication Services and Profiles. IEEE.
- International Electrotechnical Commission. (2020). IEC 61162-100: Maritime Navigation and Radiocommunication Equipment—Digital Interfaces Part 100: Ethernet. IEC.
- Radio Technical Commission for Maritime Services. (2022). SC-104 Meeting Minutes: Message Types 22-58 Reserved for Galileo/BeiDou.
- International Organization for Standardization. (2018). ISO 19056-1:2018—NMEA 2000 Maritime Navigation and Radiocommunication Equipment. ISO.
- National Marine Electronics Association. (2021). NMEA 2000 Standard (Ed. 4.00).
This consolidated bibliography contains 165 unique references organized by lecture day, formatted in APA 7 style for a U.S. academic audience.
Historical Context: Industrial Computing in GNSS (2003)
🔶 Mission-Critical Infrastructure
- Platform: Sun Fire 6800
- CPU: UltraSPARC III (1.05 GHz, 8-core)
- Architecture: RISC (big-endian)
- Memory: 32GB ECC SDRAM
- OS: Solaris 9
Key Selection Criteria:
- Deterministic performance
- Hardware fault tolerance
- Institutional trust in Sun Microsystems
🟢 Navigation Software Implementation
- Languages: C/C++ (full-stack)
- Concurrency: POSIX Threads
Key Algorithms:
- Runge-Kutta 4th order (GLONASS)
- Keplerian solver (GPS)
- Manual loop optimization
Reliability Features:
- Memory protection
- Checksum verification
- Watchdog timers
🔧 Technical Decisions: Why This Architecture Mattered
- Runge-Kutta as Core Algorithm — Not a “step” but the computational foundation requiring deterministic hardware.
- Solaris Trust — Linux lacked institutional credibility for critical systems in 2003.
- Big-Endian Requirement — Compatibility with telemetry systems.
- Vertical Scaling — SMP architecture matched algorithmic needs.
- Hardware Reliability — ECC memory prevented silent data corruption.
Historical Perspective: 2003 vs 2023
⚡ Architectural Contrast of the Eras: Today, Docker containers process data faster but rely on complex orchestrators. Back in 2003, a single Sun Fire 6800 server handled GLONASS navigation calculations with 99.995% uptime— without Kubernetes, YAML configs, or NPM-sourced dependencies. Reliability came not from layers of abstraction but from precise engineering decisions.
“We didn’t lose performance — we just spread it across layers of control.”
SKNOU & EGNOS: An Engineering Prologue to Ukraine’s Technological Integration
The 2004 integration of Ukraine’s Navigation Field Control System (SKNOU) with the European Geostationary Navigation Overlay Service (EGNOS) was a significant engineering milestone. Operating without political fanfare or media coverage, this project represented a genuine act of systems integration and a quiet success for Ukraine’s scientific and engineering community.
Technical & Historical Context
SKNOU, a nationwide network of reference GNSS stations operational since the early 2000s, was designed to provide differential corrections and signal-quality monitoring for GPS/GLONASS across Ukraine. The system's architecture included:
- A network of ground-based reference stations.
- Centralized data collection and processing centers.
- Real-time distribution channels for differential corrections, including RTK services.
The Technological Foundation: Concentrator-91
The SKNOU-to-EGNOS data link was enabled by a Ukrainian-developed messaging exchange technology built on the modernized Concentrator-91 platform. This middleware was engineered to provide robust, real-time data flow management, ensuring:
- Priority-based message routing.
- High resilience to communication link failures.
- Interoperability between heterogeneous measurement and computing systems.
The concentrator algorithms, first developed in the 1990s, were scaled and adapted to coordinate computing nodes across borders, forming the technical backbone for this international collaboration.
Project Management and Execution Challenges
Successfully synchronizing the Ukrainian system with the European EGNOS infrastructure required overcoming significant logistical and technical challenges. Establishing a stable satellite data link between Kharkiv and the processing center in Norway, for instance, involved complex multi-agent coordination and navigating numerous regulatory hurdles.
Meeting the strict 2004 deadline demanded precise project planning and resource management. The project leadership relied on quantitative forecasting to ensure that all software development, integration, and testing stages were completed exactly on schedule. This disciplined approach to workforce and timeline planning was critical for the project's success.
Managing complex, multi-stage projects like the SKNOU & EGNOS integration demands more than engineering intuition—it requires quantitative scheduling discipline. The timelines for this 2004 milestone were met using an in-house labor-intensity calculation model. That model has since evolved into the Labor Intensity Calculator This tool helps engineers model realistic timelines, allocate developer resources, and estimate project feasibility with one goal in mind: to deliver a product to market exactly when it’s needed. Plan precisely—deliver on time.
A Comparative Look at Major Integration Projects
Year Event System-Level Significance 1869 Completion of the First Transcontinental Railroad (USA) A landmark civil engineering project that resolved complex logistical challenges and established a unified national transportation network, enhancing economic connectivity. 1914 Opening of the Panama Canal A key infrastructure project that significantly altered global maritime logistics by connecting the Atlantic and Pacific oceans, creating a new strategic trade route. 1969 First connection established on ARPANET The origin of a global digital integration effort. A decentralized network built for fault tolerance that became the foundation of the modern internet. 1998 First modules of the International Space Station (ISS) connected Represents a pinnacle of international systems integration, requiring continuous coordination between multiple independent agencies and technologies in a high-risk environment. 2004 Synchronization of SKNOU (Ukraine) and EGNOS (EU) Demonstrates successful integration of a national satellite infrastructure into a pan-European positioning system. A low-profile but strategically significant alignment with EU technological standards, years ahead of formal political integration.
Conclusion
The author of this text contributed to the project from its initial software architecture to the successful data exchange within the European infrastructure. The principles embedded in Concentrator-91 bridged components once considered technically incompatible.
This case marks one of the earliest engineering-level integrations between Ukraine and the European Union. Executed with precision and strategic foresight years before official political alignment, its technical success speaks louder than any slogan.
Andrew, PhD
Senior Research Fellow