NTRIP caster overview

Status: Draft

Purpose

Learn why an RTK system needs correction data. Learn how this project moves that data from a base receiver to an authorised client.

This lesson gives you the system model used by all later lessons. It does not teach installation or detailed configuration.

Learning objectives

After this lesson, you can:

State the purpose of an RTK correction stream.
Distinguish an NTRIP source, caster, mountpoint, and client.
State the role of RTCM data.
Trace the data path through this project.
Identify the main security and privacy boundaries.

Prerequisites

You need basic TCP/IP knowledge. You do not need prior GNSS, RTK, NTRIP, or RTCM knowledge.

Key terms

Base receiver: A GNSS receiver at a known or surveyed position.
Correction data: Data that lets a rover account for errors observed by the base receiver.
RTK: A positioning method that combines rover observations with current correction data.
RTCM: A family of formats used to represent GNSS correction and observation data.
NTRIP: A method for transporting GNSS data across an IP network.
NTRIP caster: A server that distributes named streams to clients.
Mountpoint: The name used by a client to request one stream.
NTRIP client: Software or equipment that requests and consumes a stream.
Sourcetable: A list that describes streams available from a caster.

Concept explanation

Why correction data is required

A rover and a nearby base receiver observe some of the same GNSS errors. The base receiver has a controlled position. It publishes observations that a rover can use as corrections.

The caster does not calculate the rover position. It transports correction data. The rover or its positioning software calculates the position.

NTRIP responsibilities

An NTRIP arrangement has clear responsibilities:

Component	Responsibility
Source	Supplies the GNSS data stream.
Caster	Names, protects, and distributes streams.
Mountpoint	Identifies the stream requested by a client.
Client	Connects to the caster and consumes the stream.

This project combines the source-side receiver connection and the caster in one application. It reads RTCM from a serial receiver. It then serves the validated stream to clients.

Project data flow

base receiver
    -> serial port
    -> receiver setup and acknowledgement
    -> RTCM framing and CRC check
    -> per-client queues
    -> NTRIP mountpoint
    -> authorised clients
    -> optional passive monitor
    -> web reports and local SQLite data

The monitor connects to the outgoing local NTRIP stream. It does not open the receiver serial port. This keeps monitoring separate from receiver control.

Main project components

Project area	Responsibility
`lib/receiver.py`	Select and confirm receiver time mode.
`lib/rtcm.py`	Find complete RTCM frames and reject invalid CRC values.
`lib/broadcaster.py`	Give clients separate bounded queues.
`lib/caster.py`	Read serial data and serve authorised NTRIP clients.
`lib/monitoring/`	Observe the outgoing stream and prepare reports.
`lib/cli.py`	Start the caster and optional monitor processes.

Security and privacy boundaries

Basic authentication does not encrypt network traffic. Use the caster only on a trusted network or through an approved VPN. The web monitor has no built-in authentication. Do not expose it directly to the internet.

Configuration and logs can contain credentials, device paths, host details, and site coordinates. Do not include these values in learner evidence.

Worked demonstration

Trace one valid frame:

The receiver produces RTCM bytes.
The serial reader receives part or all of a frame.
The framer waits until the frame is complete.
The framer checks the CRC.
The broadcaster places the valid frame in each client queue.
An authorised client receives the frame from the selected mountpoint.
The passive monitor observes the same outgoing stream.

Expected result: the original valid frame reaches clients. The caster does not change the RTCM payload or calculate a rover position.

Guided practice

Use an unlabelled copy of the data-flow diagram.

Label every component.
Mark the component that creates receiver observations.
Mark the components that transport or distribute data.
Mark the component that calculates the rover position.
Mark the points where credentials or private site values can appear.

Expected result: the rover is outside the caster boundary, and the monitor is a passive client of the outgoing stream.

Independent practice

Write a short responsibility table for a farm base station, caster host, VPN, rover, and operator. State which component owns each action.

Checks for understanding

What is the difference between RTCM and NTRIP?
What does a mountpoint identify?
Does the caster calculate the rover position?
Why does the monitor use the outgoing stream?
Why is Basic authentication not sufficient on an untrusted network?

Assessment and evidence

Submit an annotated data-flow diagram and a component responsibility table. Your explanation must separate data creation, transport, distribution, monitoring, and position calculation.

Troubleshooting guidance

Incorrect explanation	Correction
The caster creates GNSS observations.	The receiver creates observations.
The mountpoint is an RTCM message type.	The mountpoint names a complete stream.
The monitor controls the receiver.	The monitor passively reads the outgoing stream.
Authentication encrypts the stream.	Basic authentication does not encrypt traffic.

Summary

The base receiver supplies RTCM data. The caster validates and distributes the stream through a named mountpoint. An authorised client receives the stream. The rover remains responsible for position calculation.

Source references

SRC-PROJECT-OVERVIEW: project architecture and safety boundaries
SRC-PROJECT-CODE: implemented component responsibilities
SRC-NTRIP-CONCEPT: general NTRIP concepts
SRC-RTCM-CONCEPT: general RTCM concepts