Role of a GNSS Caster
The caster receives data from a reference station or network engine and distributes it through NTRIP. It does not replace the base receiver or the rover positioning engine. It provides authentication, stable mountpoint names, a sourcetable, and efficient long-lived byte transport.
A professional service adds tenant isolation, user management, rejection reasons, monitoring, backups, and capacity limits. It can combine local stations with authorized upstream streams.
The term GNSS emphasizes support for correction content spanning GPS, GLONASS, Galileo, BeiDou, and multiple frequencies, subject to receiver and RTCM compatibility.
Data and rover feedback
RTCM carries reference coordinates, observations, and equipment information. Multi-Signal Messages describe multiple constellations. The caster forwards binary bytes without text conversion.
A parser can extract RTCM 1005/1006 station positions for monitoring without changing the rover stream. GGA feedback provides rover location and an operational quality indicator.
Rover position can support nearest-station selection, VRS, distance limits, and support diagnostics. Collection and retention remain tenant-scoped and purpose-limited.
Service organization and security
Source accounts inject declared mountpoints; client accounts receive authorized streams. A second source using the same mountpoint is rejected, while rover credentials use an administrator-defined concurrent-connection limit.
Tenant context comes from the requested domain or a dedicated local IP for legacy receivers without Host. Both the sourcetable and direct stream request are filtered.
The HTTPS control API is separate from the public binary listener. Short-lived tokens protect management actions, while upstream passwords stay on the server.
Evaluating a GNSS Caster service
Test NTRIP v1/v2 behavior, receiver firmware, long sessions, reconnection, GGA, TLS where available, and source loss. Review whether logs explain failures and whether accounts can be revoked immediately.
Capacity evaluation covers sources, rovers, bandwidth, client fan-out, logging, and disk use. Server location matters, but actual Internet routing and mobile coverage often dominate latency.
XYZRVB combines the caster and control center. Plans differ by base and rover capacity while retaining the operational monitoring features.
GNSS Caster FAQ
What is the difference between an NTRIP source, caster, and client?
The source injects correction data, the caster authenticates and distributes named streams, and the client selects a mountpoint and receives the stream. A base receiver commonly acts as the source and a rover as the client.
Can NTRIP v1 and v2 be supported together?
Yes. A compatible caster can understand historical NTRIP v1 behavior such as ICY 200 OK and modern HTTP/1.1-based NTRIP v2 requests.
Does standard NTRIP encrypt credentials and corrections?
Not by itself. Basic authentication is only encoded. TLS, a compatible secure listener, or a private network is required when transport encryption is needed.