What is an NTRIP Caster?
An NTRIP Caster receives correction streams from GNSS reference stations or network engines and distributes them to authenticated NTRIP clients through named mountpoints.
XYZRVB
Professional GNSS control center and NTRIP Caster server
Monitor reference stations, rovers, and RTCM streams, then integrate authorized mountpoints from external NTRIP Casters through one secure platform available worldwide.
Professional GNSS infrastructure
XYZRVB combines an NTRIP Caster server and a GNSS control center. Reference stations send RTCM corrections to the caster. Authenticated rovers select a mountpoint and receive the data required by their RTK or NRTK engines.
Each organization uses its own domain, accounts, GNSS bases, rovers, and sourcetable. Server-side tenant isolation prevents a client from discovering or opening another company’s mountpoints.
The platform serves RTK network operators, CORS managers, surveyors, GNSS integrators, and organizations working in construction, agriculture, or mapping.
NTRIP Control connects over HTTPS, receives a short-lived token associated with the company, and listens for real-time WebSocket events. Administration remains separate from the public binary NTRIP port.
An observable end-to-end service
One environment covers correction distribution, security, monitoring, management, history, and RINEX.
Multi-caster NTRIP relay
Bring local stations and authorized streams from another provider into XYZRVB. Imported mountpoints appear in your company sourcetable and remain available through the same NTRIP domain.
Explore external-caster relayRegister the external caster hostname, port, TLS mode, and provider credentials.
Retrieve the upstream sourcetable, select individual mountpoints, or import every authorized stream.
XYZRVB opens the upstream stream when requested and shares that connection among rovers using the same point.
Bases and CORS
The server distinguishes an open TCP connection from an active stream. Last-packet age detects silent sources and configurable permanent-station rules open and close incidents.
RTCM 1005 and 1006 provide station ID, ECEF coordinates, geodetic position, ellipsoidal height, and antenna height. Equipment messages can add antenna and receiver descriptions.
Source management covers mountpoint, description, format, country, coordinates, permanent status, service radius, RINEX policy, and originating caster. Duplicate active mountpoints are rejected.
Sources not declared in the tenant sourcetable are refused so advertised and available services remain consistent.
GNSS reference station guideReal-time corrections
RTCM remains binary from station to rover. Byte arrays are forwarded without operating-system text encoding. A parallel parser validates frames and extracts only the information needed for monitoring.
The caster supports common NTRIP v1 behavior such as ICY 200 OK and HTTP/1.1-aligned NTRIP v2 requests. TLS handshakes received on a plain port generate a clear protocol warning.
A company administrator can configure an upstream caster by hostname, port, TLS mode, username, and password. XYZRVB retrieves the remote sourcetable and imports selected or all mountpoints with an origin label.
When an authorized rover requests an imported point, an on-demand relay connects upstream, verifies the response, and redistributes RTCM. The relay stops after the final rover leaves and the idle delay expires.
In the XYZRVB relay model, one external-caster subscription can serve several rovers using the same mountpoint because XYZRVB shares one upstream connection. Each different mountpoint still requires its own upstream connection. If the provider forbids simultaneous connections using the same credential, one credential or subscription is required per open mountpoint. If reuse is allowed, the same credential may be used within the subscribed terms.
Learn about RTCM messagesAccess and attribution
When creating a rover credential, the administrator selects the maximum number of concurrent connections. Several rovers may share that credential when its quota allows it, and the control center still displays each session separately using its connection number.
For unambiguous physical-rover identification, create one credential per rover and set its concurrent-connection limit to 1. Positions and events can then be attributed directly to that rover, and its access can be revoked without affecting other equipment.
Basic authentication should be protected by TLS or a private network where receivers support it. Public IP, MAC address, and User-Agent are not reliable remote hardware identities.
Control-center credentials are not hard-coded. The server validates the organization domain, username, and password and returns a temporary token for the API and WebSocket.
Rejection events include clear reasons such as invalid credentials, a reached connection limit, a missing mountpoint, an unrecognized company, an inactive subscription, missing GGA, or excessive distance.
Respond before field impact
A permanent station that stops producing data opens an incident with the company, mountpoint, UTC time, and last activity. Recovery closes the incident and provides the outage duration.
Events appear in the control center and can use configured email or messaging channels. Notification failure is logged but never stops RTCM distribution.
Configurable delays reduce false alarms during short mobile reconnections. Policies can also cover repeated access failures, excessive baseline distance, or persistent RTK mode degradation.
Incident history supports uptime, outage count, and recovery metrics that guide power, modem, link, or receiver improvements.
NTRIP Control
The map shows active stations, rovers, Fix/Float/Single mode, and clickable base-rover lines with distance. Active markers disappear at disconnect while historical positions remain visually distinct.
Lists for sources, clients, connections, RINEX files, and events complement the map. Initial state and authorized history load first, followed by live updates without automatic panning.
Explore the GNSS control center
The control center in action
NTRIP Control brings receiver status, RTK links, station settings, RINEX archives, and external NTRIP services into one operational interface.
Protocols and equipment
GPS, GLONASS, Galileo, BeiDou and, depending on the stream, QZSS or SBAS.
NTRIP v1, NTRIP v2, RTCM 3.x, MSM, NMEA GGA, and RINEX.
Compatible Emlid Reach, Leica Geosystems, Trimble, CHCNAV, Septentrio, Topcon, Hi-Target, and other compliant equipment.
RINEX archives for PPK, PPP, quality control, mission recovery, and permanent-station analysis.
Detailed documentation
Common questions
An NTRIP Caster receives correction streams from GNSS reference stations or network engines and distributes them to authenticated NTRIP clients through named mountpoints.
It displays tenant-scoped stations, rovers, GGA positions, Fix, Float or Single modes, base-rover relationships, events, alerts, statistics, and recent history.
Compatibility is based on NTRIP, RTCM, and NMEA support. Compatible receivers from Emlid, Leica Geosystems, Trimble, CHCNAV, Septentrio, Topcon, and other manufacturers can be integrated.
Yes. Reference-station streams can be archived and converted to hourly RINEX files for quality control, PPK, PPP, and post-processing.
One upstream connection can be shared among several rovers using the same mountpoint. Each different mountpoint requires another upstream connection. When the external caster forbids simultaneous use of one credential, one credential or subscription is required per open mountpoint; otherwise the same access may be reused within the provider’s terms.
The concurrent-connection limit is selected when the rover credential is created. Shared-account sessions remain separate through their connection numbers, but one credential per rover with a limit of 1 gives unambiguous attribution for every position and event.
Subscription
Describe your needs, then continue to the detailed subscription form to select domain and capacity.