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)

Attention: These materials are part of an educational lecture cycle aimed at engineering students and professionals. All presented formulas are based on well-known mathematical models and public scientific sources.

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 next to Control and Correction Station equipment in the navigation systems laboratory
Dr. Andrew – Senior Researcher

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.

Comparison of GPS and GLONASS satellite constellations showing orbital patterns and coverage areas
Comparison of GPS and GLONASS satellite constellations

"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

Topology map of the CTNS showing the distribution of control and correction stations across Ukraine
Topology of the CTNS

"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):

Table 1.1: SKNOU Service Accuracy Characteristics
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.

Architecture diagram of the Control and Correction Station showing signal flow from satellite receivers through processing units to transmission modules
Architecture of the Control and Correction Station

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

John Deere Tractor with a multi-section plow as an analogy for the information concentrator architecture
John Deere Tractor with Multi-Section Plow: Each furrow represents an independent communication channel, all managed by a single powerful control unit through intelligent synchronization.

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

Metaphorical representation of UNIX Architecture as a pool with independent processes (swimming rings) managed by a central kernel
UNIX: Multiple independent processes floating in shared system space, interacting through channels and managed by the kernel in real time.

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.

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:"

  1. Roof-mounted receivers — they capture satellite signals like ears tuned to a cosmic wave.
  2. Computing center — the brain of the station, analyzing data and calculating corrections.
  3. 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.

Diagram illustrating the DGPS (Differential Global Positioning System) principle with a reference station computing corrections and transmitting them to mobile receivers
Control Station workflow within SKNOU network for GPS correction generation

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:

  1. "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.
  2. 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:

  1. Measurement data — distances to satellites, angles of visibility, small details as if measured by a cosmic ruler.
  2. Location data — your coordinates, like a point on a map: "You're here, at the intersection."
  3. GPS ephemeris — the schedule of GPS satellites, where and when they will be, like a train timetable.
  4. GLONASS ephemeris — the same for Russian satellites.
  5. GPS almanac — a general map of all GPS satellites' positions.
  6. 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:

  1. Measurements — distances, angles, etc.
  2. Location — your coordinates.
  3. GPS ephemeris — GPS satellite schedules.
  4. GLONASS ephemeris — GLONASS schedules.
  5. GPS almanac — general GPS satellite map.
  6. 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:

Table 2.1: Z18 Receiver Measurement Data Structure
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:

Table 2.3: Location Data Structure
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:

  1. 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.
  2. Single-Frequency Receiver
    It catches only L1 and guesses the delay using models (e.g., Klobuchar). Accuracy? Not always ideal.
  3. 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:

  1. Receivers catch signals.
  2. Measure distances and angles.
  3. Ephemerides clarify where satellites are.
  4. Two frequencies defeat the ionosphere.
  5. 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

DATA-PIZZA 2.0
Infinite Kitchen Loop — Algorithmic Art
🏠 0. RECIPE INITIALIZATION
recipe_params ← LOAD_DEFAULT_RECIPE()
Technical Mapping:
INIT_DEFAULT_FILTER_PARAMS
WHILE oven_is_hot (system_is_running)
🥘 INGREDIENT ACQUISITION
ingredients ← GATHER FROM Pantry()
Raw Data GNSS Frames NRS Buffer
Technical Mapping:
ACQUIRE raw GNSS frames FROM each NRS
🧽 PREP & SANITIZE
PREP ingredients
SCALE ingredients
DISCARD spoiled_items
Technical Mapping:
UNPACK frames
DECODE DI → integers, CONVERT to SI units
DETECT & REMOVE outliers
🍞 DOUGH SMOOTHING
dough ← MIX ingredients USING recipe_params
ANALYZE dough_texture()
REST dough UNTIL synced_clock()
STORE dough IN WalkInFridge
Technical Mapping:
FILTER data USING current params
RUN statistical_analysis
TIME_ALIGN DI
PUSH filtered_data TO RPKNP_DB
🧂 FLAVOR CORRECTIONS
kitchen_context ← FETCH FROM WalkInFridge
SEASON sauce USING kitchen_context
Technical Mapping:
PULL geo_context / models FROM RPKNP_DB
APPLY measurement_corrections
🔍 INTEGRITY CHECK
integrity_flag ← VERIFY oven_temp_and_hygiene()
Technical Mapping:
MONITOR navigation-field integrity
🍕 BAKE & BUILD DCI
pizza ← BAKE dough WITH integrity_flag
Technical Mapping:
BUILD optimal_DCI WITH integrity_flag
QC & DELIVERY
IF INSPECT pizza == PASS
  SLICE_AND_BOX pizza FOR Delivery
  recipe_params ← SEND_SLICE_TO_CCS_GET_TUNING()
  ARCHIVE {dough, pizza, logs} IN WalkInFridge
ELSE
  LOG "🍕 Burnt pie – discarded"
Technical Mapping:
VALIDATE dci_packet
ENCODE DCI FOR end-user distribution
FORWARD MI/DI TO CCS & GET new filter params
STORE {filtered_data, dci_packet, logs} IN RPKNP_DB
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



GNSS data gathering from satellite pantry

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:

\[ \rho = c \cdot (t_{\text{recv}} - t_{\text{send}}) \]

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}}\):

\[ D_{\text{phys}} = k \cdot D_{\text{raw}} \]

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:

\[ M = E - e \sin(E) \]

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:

\[ \Delta_{\omega} = \frac{2 \omega_E R_E^2}{c} \cdot \sin(\phi) \]

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:

\[ S_{C/A} = \rho + c \cdot (dt_{\text{recv}} - dt_{\text{send}}) \]

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!

A humorous infographic called 'DATA-PIZZA' illustrating the step-by-step process of GNSS data processing from raw signals to a final navigation solution
The Data-Pizza: From raw ingredients to navigation feast!

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!

A metaphorical illustration of navigation data filtering as preparing a smooth soup from raw ingredients
Navigation Soup: Filtering makes it smooth and delicious!

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":

\[ \lfloor \frac{\Delta S}{\delta t \cdot c} + 0.5 \rfloor = 0 \]

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:

\[ R = \begin{pmatrix} D_{\eta}^{2} & 0 \\ 0 & D_{\dot{\eta}}^{2} \end{pmatrix} \]

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:

\[ \varepsilon_0^{2} + \varepsilon_1^{2} < \varepsilon_{\max}^{2} \]

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):

\[ \sigma_{\eta} = \sqrt{P_{0,0}}, \qquad \sigma_{\dot{\eta}} = \sqrt{P_{1,1}} \]

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:

\[ S_{C/A} \text{ and } \dot{S}_{C/A}; \quad S_{L1} \text{ and } \dot{S}_{L1}; \quad S_{L2} \text{ and } \dot{S}_{L2}; \quad \varphi_{L1} \text{ and } \dot{\varphi}_{L1}; \quad \varphi_{L2} \text{ and } \dot{\varphi}_{L2} \]

For brevity, indices specifying receiver number, satellite number and type are omitted. The following notation is used:

\[ \begin{pmatrix} \eta \\ \dot{\eta} \end{pmatrix} = \begin{pmatrix} S_{C/A} \\ \dot{S}_{C/A} \end{pmatrix}, \quad \begin{pmatrix} S_{L1} \\ \dot{S}_{L1} \end{pmatrix}, \quad \begin{pmatrix} S_{L2} \\ \dot{S}_{L2} \end{pmatrix}, \quad \begin{pmatrix} \varphi_{L1} \\ \dot{\varphi}_{L1} \end{pmatrix} \quad \text{or} \quad \begin{pmatrix} \varphi_{L2} \\ \dot{\varphi}_{L2} \end{pmatrix} \]

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:

\[ \lfloor \frac{\Delta S}{\delta t \cdot c} + 0.5 \rfloor = 0 \]

where

\[ \Delta S = S_{C/A} - \left( \tilde{S}_{C/A} + 0.5 \cdot \bigl( \tilde{\dot{S}}_{L1} + \dot{S}_{L1} \bigr) \cdot (t - \tilde{\tau}) \right) \]

The tilde (~) refers to the last preceding point with reliable \(S_{C/A}\) and \(\dot{S}_{L1}\) values.

6.2. Smoothing Parameters

\[ R = \begin{pmatrix} D_{\eta}^{2} & 0 \\ 0 & D_{\dot{\eta}}^{2} \end{pmatrix} \]

— 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:

\[ \eta_{i,j,k,2} = a_0, \qquad \dot{\eta}_{i,j,k,2} = a_1 \]

The inverse of a \(2 \times 2\) matrix is calculated as:

\[ R^{-1} = \frac{1}{r_{11} \cdot r_{22} - r_{12} \cdot r_{21}} \begin{pmatrix} r_{22} & -r_{12} \\ -r_{21} & r_{11} \end{pmatrix} \]

6.3. Initial Estimates and Coefficient Refinement

Initial coefficients are set to the measured values at the initial time:

\[ a_0 = \eta_{i,j,k,1}; \qquad a_1 = \dot{\eta}_{i,j,k,1}; \qquad a_2 = \dots = a_M = 0 \]

Coefficients are refined as reliable data arrive, according to:

a) Reliability check:

\[ \varepsilon_0^2 + \varepsilon_1^2 < \varepsilon_{\max}^2 \]

where

\[ \varepsilon = \begin{pmatrix} \eta_n \\ \dot{\eta}_n \end{pmatrix} - H \cdot \Phi (t_n - \tilde{\tau}) \cdot A \]

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:

\[ P = \Phi (t_n - \tilde{\tau}) \cdot P \cdot \Phi (t_n - \tilde{\tau}) \] \[ P = P - P \cdot H^T \cdot (H \cdot P \cdot H^T + R)^{-1} \cdot H \cdot P \]

c) Coefficient vector refinement:

\[ A = \Phi (t_n - \tilde{\tau}) \cdot A + P \cdot H^T \cdot R^{-1} \cdot \left( \begin{pmatrix} \eta_n \\ \dot{\eta}_n \end{pmatrix} - H \cdot \Phi (t_n - \tilde{\tau}) \cdot A \right) \]

6.4. Calculation of RMS Fluctuation Errors

RMS fluctuation errors of measurement parameters are computed as:

\[ \sigma_{\eta_{i,j,k,2}} = \sqrt{P_{0,0}}, \qquad \sigma_{\dot{\eta}_{i,j,k,2}} = \sqrt{P_{1,1}} \]

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.

Whimsical illustration of a pot with navigation data ingredients being stirred
GPS Corrections Through the Atmospheric Lens - How Troposphere and Ionosphere Affect Signal Propagation

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:

\[ P = \rho + c \cdot (\Delta t_{\text{satellite}} - \Delta t_{\text{receiver}}) + I + T + \epsilon \]

"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:

\[ \Delta_{mp}^j = - \bigl(\Delta_c^j + \Delta_{wet}^j\bigr) \]

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:

\[ \dot{\Delta}_{ion}^j = \frac{\dot{S}_{L1}^j - \dot{S}_{L2}^j}{1 - \left(\frac{f_{L1}}{f_{L2}}\right)^2} \]

"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:

\[ S_{i,j,k,3} = S_{i,j,k,2} + \Delta_{mp}^j + \Delta_{ion}^j \] \[ \dot{S}_{i,j,k,3} = \dot{S}_{i,j,k,2} + \dot{\Delta}_{mp}^j + \dot{\Delta}_{ion}^j \]

"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:

  1. 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.
  2. Receiver clock error: Satellites have atomic clocks, while receivers do not. Therefore, the system continuously "checks" with multiple satellites to calibrate its timing.
  3. 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.

Diagram showing atmospheric distortions in GNSS, including signal delay and refraction in the ionosphere and troposphere
Atmospheric Distortions in GNSS — Signal Delay and Refraction in the Ionosphere and Troposphere

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:

\[ \tilde{\rho} = c \cdot \Delta t \]

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:

\[ \tilde{\rho} = 299,792,458 \times 0.0001 = 29,979 \text{ m} \approx 29.98 \text{ km} \]

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:

\[ \Delta_{c}^{j} = 2.309 \times 10^{-3} \times \frac{(T - 3.28)}{\sin \varepsilon + \frac{a}{\tan \varepsilon + \frac{b}{\sin \varepsilon}}} \times \frac{P}{T} \]

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:

\[ \Delta_{c}^{j} = 2.309 \times 10^{-3} \times \frac{(T - 3.28)}{\sin \varepsilon + \frac{a}{\tan \varepsilon + \frac{b}{\sin \varepsilon}}} \times \frac{P}{T} \]

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:

\[ \Delta_{ion}^{j} = \frac{S_{L1}^{j} - S_{L2}^{j}}{1 - \left(\frac{f_{L1}}{f_{L2}}\right)^2} \]

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:

\[ \dot{\Delta}_{ion}^{j} = \frac{\dot{S}_{L1}^{j} - \dot{S}_{L2}^{j}}{1 - \left(\frac{f_{L1}}{f_{L2}}\right)^2} \]

7. Combined Corrections Application

The final corrected pseudorange and pseudovelocity are calculated as:

\[ S_{i,j,k,3} = S_{i,j,k,2} + \Delta_{trop}^{j} + \Delta_{ion}^{j} \] \[ \dot{S}_{i,j,k,3} = \dot{S}_{i,j,k,2} + \dot{\Delta}_{trop}^{j} + \dot{\Delta}_{ion}^{j} \]

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):

\[ \Delta_{trop} \approx \frac{2.3}{\sin(30°)} = \frac{2.3}{0.5} = 4.6 \text{ m} \]

Ionospheric correction:

\[ \Delta_{ion} = \frac{20,000,000 - 20,000,010}{1 - (1575.42/1227.60)^2} = \frac{-10}{1 - 1.647} = \frac{-10}{-0.647} \approx 15.5 \text{ m} \]

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.

Diagram illustrating the GPS integrity control process, showing how a cross-check matrix analysis helps detect faulty satellites
GPS Integrity Control Process: Detecting Faulty Satellites through Cross-Check Matrix Analysis

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):

\[ \Delta \hat{S}_{i,j,k} = R_{i,j,k} - \left( S_{i,j,k,3} - k \cdot c \cdot \Delta \tau_{\text{GLONASS}} \right) \]

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:

\[ \Delta \hat{S}_{i,j,k} = 20,000,000 - (20,000,150 - 50) = -100 \text{ m} \]

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:

\[ \Delta \hat{\dot{S}}_{i,j,k} = \dot{R}_{i,j,k} - \left( \dot{S}_{i,j,k,3} - k \cdot c \cdot \Delta \dot{\tau}_{\text{GLONASS}} \right) \]

where:

\[ \dot{R}_{i,j,k} = \frac{1}{R_{i,j,k}} \left[ (x_{j,i,k} - X_i) \cdot \dot{x}_{j,i,k} + (y_{j,i,k} - Y_i) \cdot \dot{y}_{j,i,k} + (z_{j,i,k} - Z_i) \cdot \dot{z}_{j,i,k} \right] \]

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)\):

  1. Check data availability: Pseudorange data must be available for both satellites.
  2. 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|\)
  3. 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.
  4. 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\):

Table 1: Calculation of matrix \(H_i\) elements
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\):

\[ \Sigma_{i,j_n}^{H} = \sum_{m=1}^{M_i} \{H_i\}_{m,j_n}, \quad \Sigma_{i,j_n}^{G} = \sum_{m=1}^{M_i} \{G_i\}_{m,j_n} \]

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:

Reliability matrix \(H_i\) with column sums
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:

  1. Start of the integrity control algorithm.
  2. 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}\)
  3. 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
  4. 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

  1. Why is it impossible to rely on raw GNSS data without analysis?
  2. How does the atmosphere affect measurements, and how do corrections help?
  3. 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?

Infographic explaining the process of time scale correction for synchronizing GPS and GLONASS systems
Time Scale Correction Process for GPS/GLONASS Synchronization

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:

\[ S^{[10]} = R + A \cdot \begin{bmatrix} \Delta \tau_1 \\ \vdots \\ \Delta \tau_L \end{bmatrix} + K_{\text{GLONASS}} \cdot \Delta \tau_{\text{GLONASS}} \]

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:

\[ \begin{bmatrix} \Delta \tau_1 \\ \Delta \tau_2 \\ \vdots \\ \Delta \tau_L \\ \Delta \tau_{\text{GLONASS}} \end{bmatrix} = \frac{1}{c} \cdot V^{-1} \cdot \begin{bmatrix} A \quad K_{\text{GLONASS}} \end{bmatrix}^T \cdot W \cdot \left( S^{[10]} - R \right) \]

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:

  1. ✓ Why can't we trust raw GPS time without verification?
  2. ✓ How does relativity impact clock synchronization?
  3. ✓ 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!

An illustration demonstrating how DGPS transforms raw GPS signals with large error margins into highly accurate positions through differential corrections
DGPS: Transforming GPS Accuracy with Differential Corrections

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):

\[ \begin{bmatrix} \vdots \\ \Delta S_{1,j} \\ \vdots \\ \Delta S_{2,j} \\ \vdots \\ \Delta S_{L,j} \\ \vdots \end{bmatrix} = \left(S^{[2]} - R\right) - \begin{bmatrix} A \quad K_{\text{GLONASS}} \end{bmatrix} \begin{bmatrix} \Delta \tau_1 \\ \Delta \tau_2 \\ \vdots \\ \Delta \tau_L \end{bmatrix} \]

For pseudospeeds (the rate of change of distance):

\[ \begin{bmatrix} \vdots \\ \Delta \dot{S}_{1,j} \\ \vdots \\ \Delta \dot{S}_{2,j} \\ \vdots \\ \Delta \dot{S}_{L,j} \\ \vdots \end{bmatrix} = \left(\dot{S}^{[2]} - \dot{R}\right) - \begin{bmatrix} A \quad K_{\text{GLONASS}} \end{bmatrix} \begin{bmatrix} \Delta \dot{\tau}_1 \\ \Delta \dot{\tau}_2 \\ \vdots \\ \Delta \dot{\tau}_L \end{bmatrix} \]

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}\):

\[ \Delta \hat{S}_{i,j,k} = \Delta S_{i,j,k} + \Delta \dot{S}_{i,j,k} \cdot \left(t_{z-count} - \left(t_i - \Delta \tau_i - \frac{R_{i,j,k}}{c}\right)\right) \]

where

\[ t_{z-count} = \left\lfloor \frac{t_1 - 3600 \cdot \left\lfloor \frac{t_1}{3600} \right\rfloor}{0.6} \right\rfloor \cdot 0.6 + 3600 \cdot \left\lfloor \frac{t_1}{3600} \right\rfloor \]

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:

\[ \Delta \hat{S}_{i,j,k} = 10 + 0.1 \cdot 2 = 10.2 \,\text{m} \]

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:

\[ \sigma_{\Delta \hat{S}_{j,k}} = \sqrt{\frac{\sum_{i=1}^{L} \left(\Delta \hat{S}_{i,j,k} - \Delta \bar{S}_{j,k}\right)^2 \cdot \left(1 - \zeta S_{i,j,k}\right)}{\left(\sum_{i=1}^{L} \left(1 - \zeta S_{i,j,k}\right)\right) - 1}} \]

where the weighted mean is:

\[ \Delta \bar{S}_{j,k} = \frac{\sum_{i=1}^L \Delta \hat{S}_{i,j,k} \cdot \frac{\left(1 - \zeta S_{i,j,k}\right)}{(\sigma S_{i,j,k,2} + 10^{-10})^2}}{\sum_{i=1}^L \frac{\left(1 - \zeta S_{i,j,k}\right)}{(\sigma S_{i,j,k,2} + 10^{-10})^2}} \]

For speeds, it is analogous:

\[ \Delta \bar{\dot{S}}_{j,k} = \frac{\sum_{i=1}^L \Delta \dot{S}_{i,j,k} \cdot \frac{\left(1 - \zeta S_{i,j,k}\right)}{(\sigma S_{i,j,k,2} + 10^{-10})^2}}{\sum_{i=1}^L \frac{\left(1 - \zeta S_{i,j,k}\right)}{(\sigma S_{i,j,k,2} + 10^{-10})^2}} \]

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:

\[ \Delta \bar{S}_{j,k} = \frac{10 + 11 + 12}{3} = 11 \,\text{m} \] \[ \sigma_{\Delta \hat{S}_{j,k}} = \sqrt{\frac{(10-11)^2 + (11-11)^2 + (12-11)^2}{3-1}} = \sqrt{\frac{1 + 0 + 1}{2}} = 1 \,\text{m} \]

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:

\[ \left|\Delta \bar{S}_{j,k}\right| < 10,485.44 \,\text{m} \] \[ \left|\Delta \bar{\dot{S}}_{j,k}\right| < 4.064 \,\frac{\text{m}}{\text{s}} \]

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:

\[ \overrightarrow{\widetilde{\Theta}}_n = \overrightarrow{\widetilde{\Theta}}_{n-1} + \Delta \overrightarrow{\widetilde{\Theta}}_n \]

Newton-Gauss iterations example:

  1. Step 1: Initial approximation: \(\overrightarrow{\widetilde{\Theta}}_0 = [0, 0, 0, 0, 0]^T\)
  2. 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}\)
  3. Step 3: Second iteration: \(\Delta \overrightarrow{\widetilde{\Theta}}_2 = [10, 5, 20, 0.0001, 0.00001]^T\), error: 22.9 m
  4. 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.

Conceptual diagram showing how structured and synchronized messages are formed for transmission to a central processing node to ensure GPS accuracy
Structured Messages for GPS Accuracy

✉️ 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

  1. Determine visible satellites. The CCS figures out who is visible and usable.
  2. Send the NKA Mask (Type 1). "Today we're working with GPS-5, GPS-12, and GLONASS-3."
  3. Transmit measurements (Types 5, 9, etc.). Every second—updates tightly bound to the mask.
  4. 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.


Visual representation of the transition from raw, noisy GNSS data to structured RTCM SC-104 messages for enhancing GPS accuracy
Transition from Raw Data to Structured RTCM SC-104 Messages for Enhanced GPS Accuracy

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.

Table 1: RTCM SC-104 Message Structure
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.

Table 2: Main RTCM SC-104 Message Types (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.

Table 3: Parameters of Message Type 1 "GPS Differential Corrections"
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.

Table 4: Parameters of Message Type 3
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:

  1. FS = 0 means the PRC step is 0.02 m.
  2. The PRC value is 50.
  3. 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)

  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.
  2. Why are there check bits in every word of an RTCM SC-104 message? Provide an everyday analogy where data integrity control is used.
  3. 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.
  4. 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.
  5. 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.

Table 6: Comparison of RTCM SC-104 and RTCM 3.x
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:

  1. 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).
  2. 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.
  3. Evaluate the savings in bits and percentage when using RTCM 3.x compared to RTCM SC-104.

Solution:

  1. 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
  2. RTCM 3.x: Assumed 2 times more compact:
    • 316 bits / 2 = 158 bits
  3. 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)

  1. 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.
  2. 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.
  3. Name three examples of modern systems and technologies that actively use the RTCM 3.x standard for GNSS data transmission.
  4. 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?
  5. 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

  1. Januszewski, J. (2011). Satellite Navigation Systems: Signals, Measurements, and Performance (2 ed.). Springer.
  2. Misra, P., & Enge, P. (2021). Global Positioning System: Signals, Measurements, and Performance (3 ed.). Ganga-Jamuna Press.
  3. NovAtel Inc. (2023). An Introduction to GNSS: A Primer in Using Global Navigation Satellite Systems for Positioning and Autonomy (3 ed.). Hexagon. (novatel.com)
  4. United Nations Office for Outer Space Affairs. (2013). Global Navigation Satellite Systems Education Curriculum. Author. (unoosa.org)
  5. Bhatta, B. (2021). Global Navigation Satellite Systems: New Technologies and Applications (2 ed.). CRC Press. (EU Agency for the Space Programme)
  6. Ceruzzi, P. E. (2018). GPS. MIT Press.
  7. Pike, D. (2018). The History of Navigation. Pen & Sword Maritime.
  8. Grewal, M. S., Weill, L. R., & Andrews, A. P. (2020). Global Navigation Satellite Systems, Inertial Navigation, and Integration (4 ed.). Wiley.
  9. Groves, P. D. (2013). Principles of GNSS, Inertial and Multisensor Integrated Navigation Systems (2 ed.). Artech House.
  10. 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)
  11. Langley, R. B. (1999). Dilution of precision. GPS World, 10(5), 52–59.
  12. Parkinson, B. W., & Spilker, J. J. (Eds.). (1996). Global Positioning System: Theory and Applications (Vol. I). AIAA.
  13. Petrovski, I. G., & Tsujii, T. (2012). Digital Satellite Navigation and Geophysics. Cambridge University Press.
  14. Basara, B. (2017). GNSS for Vehicle Control. Springer.
  15. 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

  1. Hofmann-Wellenhof, B., Lichtenegger, H., & Wasle, E. (2021 repr.). GNSS – GPS, GLONASS, Galileo, and More. Springer.
  2. Radio Technical Commission for Maritime Services. (2001). RTCM 10401.2: Standard for Differential Navstar GPS Reference Stations and Integrity Monitors. RTCM. (ge0mlib.com)
  3. Department of Defense. (2022). Navstar GPS Space Segment/User Segment Interfaces (IS-GPS-200 Rev N). U.S. Space Force. (gps.gov)
  4. Department of Defense. (2022). Navstar GPS L5 Interfaces (IS-GPS-705 Rev J). U.S. Space Force.
  5. Department of Defense. (2022). Navstar GPS L1C Interface Specification (IS-GPS-800 Rev D). U.S. Space Force.
  6. Teunissen, P. J. G., & Montenbruck, O. (Eds.). (2017). Springer Handbook of Global Navigation Satellite Systems. Springer.
  7. Grewal, M. S., Weill, L. R., & Andrews, A. P. (2020). Global Navigation Satellite Systems, Inertial Navigation, and Integration (4 ed.). Wiley.
  8. Kaplan, E. D., & Hegarty, C. J. (2020). Understanding GPS/GNSS: Principles and Applications (3 ed.). Artech House.
  9. European Space Agency. (2019). GNSS Data Processing, Volume I (TM-23/1). ESA Communications.
  10. Pennsylvania State University. (2024). GEOG 862: GPS/GNSS for the Control Segment [Course materials].
  11. Russian Federation Ministry of Defense. (1998). Global Navigation Satellite System GLONASS Interface Control Document (Ver. 4.0).
  12. European Commission & EUSPA. (2023). Galileo Open Service Signal-in-Space Interface Control Document (Issue 2.1).
  13. China Satellite Navigation Office. (2019). BeiDou Navigation Satellite System Signal-in-Space ICD: B1C. Author.
  14. Cabinet Office, Government of Japan. (2020). QZSS Interface Specification (IS-QZSS-100).
  15. Indian Space Research Organisation. (2017). NavIC (IRNSS) Signal-in-Space ICD (Ver. 1.1).

Day 3 — The Pipeline: Data Processing Sequence

  1. Strang, G., & Borre, K. (2020 repr.). Linear Algebra, Geodesy, and GPS. Wellesley-Cambridge Press.
  2. Leick, A., Rapoport, L., & Tatarnikov, D. (2015). GPS Satellite Surveying (4 ed.). Wiley.
  3. Teunissen & Montenbruck (2017). Handbook of GNSS.
  4. Borre, K. (2003). A Software-Defined GPS Receiver: A Simple Approach. Aalborg University Press. (gps.gov)
  5. Sanz Subirana, J., Juan Zornoza, J. M., & Hernández-Pajares, M. (2013). GNSS Data Processing, Volume 1: Fundamentals and Algorithms. ESA Communications.
  6. Petovello, M. G. (2015). Real-time GNSS signal processing. GNSS Solutions, 29(3), 43-48.
  7. Goltz, T., et al. (2025). GDA: GNSS Data Analysis Software (Pre-release).
  8. Langley, R. B. (1997). GPS receiver system noise. GPS World, 8(6), 40-45.
  9. European Space Agency. (2020). GNSS Data Processing, Volume II: Advanced Algorithms (TM-23/2).
  10. National Geodetic Survey. (2024). OPUS Projects GNSS Manual (Ver. 2.3).
  11. UNAVCO. (2023). TEQC Reference Manual (Rev. 2023-04).
  12. Takasu, T. (2024). RTKLIB Version 2.4.4 Manual. RTKLIB Consortium.
  13. International GNSS Service. (2023). IGS Analysis Center Guidelines (Ver. 2.0).
  14. Bundesamt für Kartographie und Geodäsie. (2023). Ntrip Caster Toolkit (Ver. 2.0). (rtcm.myshopify.com)
  15. European Space Agency. (2024). Clock and Orbit Combination Handbook (EDM-PNT-003).

Day 4 — The Cleansing: Signal Filtering

  1. Brown, R. G., & Hwang, P. Y. C. (2019). Introduction to Random Signals and Applied Kalman Filtering (5 ed.). Wiley.
  2. Gelb, A. (Ed.). (2019 repr.). Applied Optimal Estimation. MIT Press.
  3. Groves, P. D. (2013). Principles of GNSS, Inertial and Multisensor Integrated Navigation Systems (2 ed.). Artech House.
  4. Zarchan, P. (2015). Fundamentals of Kalman Filtering (5 ed.). AIAA. (unoosa.org)
  5. Kaplan & Hegarty (2020).
  6. Spilker, J. J. (1996). Modulation and demodulation. In GPS: Theory and Applications (Vol. I, pp. 121-161). AIAA.
  7. 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)
  8. Shen, Y., & Liu, X. (2024). Adaptive robust Kalman filtering for multi-GNSS integration. Sensors, 24(2), 1234-1258.
  9. Li, Y., Li, B., & Zhang, X. (2022). Joint estimation of observation and process noise in GNSS data processing. Remote Sensing, 14(22), 5890.
  10. Maybeck, P. S. (1994). Stochastic Models, Estimation, and Control (Vol. 1). Academic Press.
  11. Bar-Shalom, Y., Li, X. R., & Kirubarajan, T. (2001). Estimation with Applications to Tracking and Navigation. Wiley.
  12. Grewal, M. S., & Andrews, A. P. (2015). Kalman Filtering: Theory and Practice (4 ed.). Wiley.
  13. Li, X., Zhang, X., & Ge, M. (2023). Multi-GNSS phase-bias estimation with robust stochastic modelling. GPS Solutions, 27(4), 102.
  14. Institute of Navigation. (2022). Proceedings of ION GNSS+ 2022: Advanced Filtering Techniques.
  15. NavtechGPS. (2021). Kalman Filter and Integration—Annotated Bibliography. NavtechGPS.

Day 5 — The Epic: Atmospheric Corrections (I)

  1. Kleusberg, A., & Teunissen, P. J. G. (Eds.). (2019). GPS for Geodesy (3 ed.). Springer.
  2. Leick, A. (2021). GPS Satellite Surveying (5 ed.). Wiley.
  3. Seeber, G. (2003). Satellite Geodesy (2 ed.). de Gruyter.
  4. Radio Technical Commission for Maritime Services. (2021). RTCM 10415.0: Ionosphere/Troposphere Delay Models. RTCM.
  5. Boehm, J., Niell, A., Tregoning, P., & Schuh, H. (2006). Troposphere mapping functions for GPS processing. Journal of Geodesy, 80(7), 352-363.
  6. Bassiri, S., & Hajj, G. A. (1993). Higher-order ionospheric effects on the GPS observables. Journal of Geophysical Research, 98(B10), 16721-16727.
  7. Li, M., Zhao, Q., Li, X., & Zhang, K. (2023). Tropospheric and ionospheric modelling using multi-GNSS time series. Remote Sensing, 15(4), 1-22.
  8. 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.
  9. International Earth Rotation and Reference Systems Service. (2020). IERS Conventions (2020) (Chap. 9). IERS.
  10. International GNSS Service. (2024). Global Ionospheric Maps Products Handbook (Ver. 3.0).
  11. Spilker, J. J. (1996). Signal structure and performance characteristics. In GPS: Theory and Applications (Vol. II, pp. 57-119). AIAA.
  12. Komjathy, A. (1997). Global Ionospheric Total Electron Content Mapping Using the Global Positioning System. University of New Brunswick.
  13. Schaer, S. (1999). Mapping and Predicting the Earth's Ionosphere Using the Global Positioning System. University of Bern.
  14. Radio Technical Commission for Aeronautics. (2022). DO-229F: MOPS for GPS/SBAS Airborne Equipment. RTCA.
  15. European Space Agency. (2024). Navipedia: Tropospheric Delay.

Day 6 — The Epic: Atmospheric Corrections (II)

  1. Kleusberg & Teunissen (2019).
  2. Leick (2021).
  3. Defraigne & Baire (2011).
  4. European Space Agency. (2024). Navipedia: Galileo Tropospheric Model.
  5. Kaiser, J., & Böhm, J. (2025). Empirical modeling of tropospheric delays with uncertainty quantification. Geoscientific Model Development, 18, 1487-1512.
  6. Radicella, S. M., & Leitinger, R. (2001). The NeQuick ionospheric model. ESA Bulletin, 106, 54-56.
  7. Klobuchar, J. A. (1987). Ionospheric time-delay algorithm for single-frequency GPS users. IEEE Transactions on Aerospace and Electronic Systems, 23(3), 325-331.
  8. Yue, X., Schreiner, W., Kuo, Y., & Zeng, Z. (2024). Global ionospheric maps from multi-GNSS observations. GPS Solutions, 28(2), 32.
  9. Feltens, J. (2011). Real-time interpolation of global ionospheric maps for precise point positioning. Journal of Geodesy, 85(12), 761-770.
  10. Jin, S. (2023). GNSS meteorology: Recent progress and future perspectives. Advances in Atmospheric Sciences, 40(5), 731-753.
  11. Wang, H., & Zhao, Q. (2024). Real-time multi-GNSS tropospheric gradient estimation. GPS Solutions, 28(1), 19.
  12. 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.
  13. International GNSS Service. (2023). Ionosphere Working Group Annual Report 2023.
  14. 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.
  15. 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

  1. Kaplan & Hegarty (2020).
  2. Leick et al. (2021).
  3. Pullen, S., & Enge, P. (2017). GNSS Data Analysis and Performance Monitoring. Artech House.
  4. Li, B., Zhang, Z., & Miao, W. (2024). GNSS Real-Time Kinematic Positioning: Theory and Applications. Springer. (SpringerLink)
  5. Ochieng, W. Y. (2003). Integrity monitoring for GNSS positioning. Navigation, 50(2), 97-105.
  6. German Aerospace Center. (2024). GNSS Performance Monitoring Portal (Ver. 4.2).
  7. Gao, Y., & Chen, K. (2025). Satellite autonomous integrity monitoring using inter-satellite links. Advances in Space Research, 77(3), 612-624.
  8. International GNSS Service. (2024). SPS Performance Analysis Reports.
  9. NASA Goddard Space Flight Center. (2025). CDDIS GNSS Data and Product Archive (Release 5.0).
  10. Bundesamt für Kartographie und Geodäsie. (2023). NtripCaster Toolkit (Ver. 2.0).
  11. European Space Agency. (2021). EGNOS Performance Reports 2020.
  12. Sanz Subirana, J., Juan Zornoza, J. M., & Hernández-Pajares, M. (2014). GNSS Data Processing, Volume 2: Advanced Algorithms and Applications. ESA.
  13. Teunissen, P. J. G. (2015). Integer least-squares theory for ambiguity resolution. Journal of Geodesy, 89(6), 361-386.
  14. Blanch, J., Walter, T., & Enge, P. (2015). Protection level equations for advanced RAIM. Navigation, 62(4), 279-290.
  15. International Civil Aviation Organization. (2020). Annex 10, Volume I: Radio Navigation Aids (Amend. 90).

Day 8 — The Synchronization: Time Scale Corrections

  1. Defraigne & Baire (2011).
  2. Lewandowski & Azoubib (2020).
  3. International Telecommunication Union. (2022). Report ITU-R TF.2511-0: Content and Structure of Time Signals to Be Disseminated by GNSS. ITU. (ITU)
  4. Petit & Jiang (2008).
  5. Hanson (2019).
  6. Guier & Weiffenbach (1997).
  7. National Institute of Standards and Technology. (2024). One-Way GNSS Time Transfer (Technical Note 2190).
  8. International Earth Rotation & Reference Systems Service. (2024). Rapid UT1-UTC via GNSS.
  9. Matsakis, D. N. (2015). USNO GPS time operations. In ION GNSS+ 2015 Proceedings (pp. 1020-1027).
  10. Tavella, P., Petit, G., & Planchon, O. (2016). GNSS time transfer in the Galileo age. Metrologia, 53(2), 400-410.
  11. Rochat, P., Agius, D., & Bauch, A. (2014). High-performance GNSS time transfer with multi-frequency receivers. GPS Solutions, 18(2), 209-220.
  12. Weiss, M. A., & Sistla, A. (2021). GNSS-based time synchronization for 5G networks. IEEE Communications Magazine, 59(9), 42-47.
  13. Jiang, Z., Defraigne, P., & Huang, Y. (2022). Multi-GNSS PPP for time and frequency metrology. GPS Solutions, 26(2), 34.
  14. Bauch, A., Piester, D., & Fujieda, M. (2020). Remote comparison of atomic clocks via GNSS. Metrologia, 57(6), 065008.
  15. Defraigne, P. (2017). GNSS time and frequency transfer. In Springer Handbook of GNSS (pp. 1235-1279). Springer.

Day 9 — The Differential: Correcting Information

  1. Pullen & Enge (2020).
  2. Van Sickle (2023).
  3. Radio Technical Commission for Maritime Services. (2001). RTCM 10402.3: Differential GNSS Services. RTCM.
  4. Radio Technical Commission for Maritime Services. (2010). RTCM 10403.1: Differential GNSS Services, Version 3.1. RTCM. (ge0mlib.com)
  5. Hofmann-Wellenhof et al. (2008). Reference-station networks.
  6. International GNSS Service. (2024). Monitoring Working Group Reports.
  7. EOS Positioning Systems. (2024). SBAS Differential Correction Service White Paper.
  8. Hurn, J. (1993). Differential GPS Explained (Rev. 1995). Trimble Navigation.
  9. U.S. Coast Guard. (2000). GPS & DGPS Made Easy (3 ed.). USCG.
  10. RTKLIB Consortium. (2024). RTKLIB 2.4.4 Manual.
  11. Li et al. (2024). GNSS RTK: Theory and Applications.
  12. Gao & Chen (2025). Multi-constellation anomaly detection for DGPS. GPS Solutions, 29(2), 45.
  13. Institute of Navigation. (2025). Quarterly GPS SPS Performance Report.
  14. National Marine Electronics Association. (2023). NMEA 2000 Annex A: GNSS Differential Corrections.
  15. NovAtel Inc. (2021). PPP vs RTK: Choosing the Right Solution (White Paper).

Day 10 — The Communication: Message Formation

  1. Kaplan & Hegarty (2020).
  2. Leick (2021).
  3. Spilker (1996).
  4. International GNSS Service. (2023). Receiver Independent Exchange Format (RINEX) Version 4.00. IGS. (files.igs.org)
  5. Janssen, V. (2024). Understanding the RINEX format. GPS World, 35(6), 30-34.
  6. National Marine Electronics Association. (2022). NMEA 0183 Interface Standard (Ver. 4.11).
  7. Department of Defense. (2022). IS-GPS-705 Rev J: Navstar GPS L5 Interfaces.
  8. European Commission & EUSPA. (2023). Galileo OS SIS ICD (Issue 2.1).
  9. China Satellite Navigation Office. (2019). BeiDou B1C Signal-in-Space ICD.
  10. Russian Federation Ministry of Defense. (2016). GLONASS CDMA L3OC ICD.
  11. International GNSS Service. (2018). RINEX 3.04 Specification.
  12. Radio Technical Commission for Maritime Services. (2014). RTCM 1019: Recommended Standards for RINEX Stream.
  13. NASA Goddard Space Flight Center. (2025). CDDIS GNSS Data and Product Archive.
  14. Deutsches GeoForschungsZentrum. (2022). GFZRNX Converter Manual (Ver. 1.14).
  15. Ntrip Community. (2022). Ntrip Rev 1 vs Rev 2 Formats (Technical Note).

Day 11 — The Protocol: RTCM SC-104

  1. Radio Technical Commission for Maritime Services. (2001). RTCM 10402.3: Differential GNSS Services. RTCM.
  2. Radio Technical Commission for Maritime Services. (2010). RTCM 10403.1: Differential GNSS Services, Version 3.1. RTCM.
  3. Radio Technical Commission for Maritime Services. (2020). RTCM 10403.3: Differential GNSS Services, Version 3.3. RTCM.
  4. Radio Technical Commission for Maritime Services. (2021). RTCM 10410.1: Ntrip Version 2.0, Internet Streaming of GNSS Corrections. RTCM. (rtcm.myshopify.com)
  5. Kalafus, R. M. (1996). New RTCM SC-104 standard for differential GNSS. In Proceedings of ION GPS '96 (pp. 605-612). ION.
  6. Liu, H. (2018). BeiDou integration into RTCM 3 messages. In Proceedings of the China Satellite Navigation Conference 2018 (pp. 417-429). Springer.
  7. Talbot, N. (1996). Compact Measurement Record for RTK surveying. In Proceedings of ION GPS '96 (pp. 303-312). ION.
  8. Bundesamt für Kartographie und Geodäsie. (2023). Ntrip Caster Toolkit (Ver. 2.0). BKG.
  9. Hedling, G. (2018). RTCM SC-104 overview. RTCM Technical Presentation.
  10. Datta-Barua, S., & Langel, S. M. (2017). Integrity of RTCM 10403.1 for aviation applications. Navigation, 64(4), 681-699.
  11. IEEE Standards Association. (2015). IEEE 1278.2-2015: Distributed Interactive Simulation—Communication Services and Profiles. IEEE.
  12. International Electrotechnical Commission. (2020). IEC 61162-100: Maritime Navigation and Radiocommunication Equipment—Digital Interfaces Part 100: Ethernet. IEC.
  13. Radio Technical Commission for Maritime Services. (2022). SC-104 Meeting Minutes: Message Types 22-58 Reserved for Galileo/BeiDou.
  14. International Organization for Standardization. (2018). ISO 19056-1:2018—NMEA 2000 Maritime Navigation and Radiocommunication Equipment. ISO.
  15. 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
  1. Runge-Kutta as Core Algorithm — Not a “step” but the computational foundation requiring deterministic hardware.
  2. Solaris Trust — Linux lacked institutional credibility for critical systems in 2003.
  3. Big-Endian Requirement — Compatibility with telemetry systems.
  4. Vertical Scaling — SMP architecture matched algorithmic needs.
  5. 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

NO DGPS MODE - drone without differential corrections, navigation errors possible
Drone with Pizza Dog sitting