GNSS control center overview
A real-time GNSS service contains several layers that change independently. Reference stations observe satellites, IP links carry corrections, the NTRIP Caster publishes mountpoints, and rovers consume selected streams. When these systems are inspected separately, operators spend time correlating receiver screens, server logs, and field reports. A control center brings the signals together and answers practical questions: which base is online, which rover is connected, which mountpoint is used, and what changed before an incident?
XYZRVB NTRIP Control combines live caster events with station coordinates from RTCM 1005 or 1006, rover positions from NMEA GGA, RTK quality labels, transferred volumes, and access-control decisions. This does not replace receiver configuration software. It provides a service-wide view across compatible Emlid Reach, Leica Geosystems, Trimble, CHCNAV, Septentrio, Topcon, Hi-Target, and other NTRIP/RTCM equipment.
The control center is intended for RTK network operators, CORS managers, surveying businesses, GNSS integrators, and teams that support multiple field users. It focuses on observable facts and clear event reasons instead of assuming that an open TCP socket proves a healthy correction service.
Technical architecture
The NTRIP listener and the administration API have different responsibilities. Long-lived binary streams use the caster port. Status and management use an HTTPS API and WebSocket. At sign-in, the user supplies a tenant domain, username, and password; the server returns a short-lived token bound to that tenant. Credentials are not hard-coded into the Windows application.
Multi-tenant isolation is enforced before resource lookup. Hostname or dedicated local IP resolves the organization. The resolved tenant scopes authentication, sourcetable entries, mountpoints, clients, events, and stored history. A user cannot bypass the interface by requesting another tenant’s known mountpoint directly.
Current state and history use separate storage policies. Live status must remain compact. Recent rover positions may be retained for a bounded period, while RINEX files follow their own archival policy. Query limits and cleanup prevent the dashboard from becoming an unlimited in-memory event store.
Live operation and event processing
After authentication, the application loads an initial tenant snapshot so the map is meaningful immediately. WebSocket events then update station, rover, and event collections. Source connection, client acceptance, GGA position, RTCM reference position, rejection, and disconnection events each have distinct handling.
Active markers must be different from historical points. When a device disconnects, its active marker and base-rover line disappear. Historical observations can remain as smaller traces. This prevents the last known location from being mistaken for a current session.
RTCM 1005 and 1006 provide signed ECEF coordinates. The server validates message length before reading bits and converts X, Y, and Z to geodetic latitude, longitude, and ellipsoidal height. Rover GGA parsing converts degrees and minutes, altitude, and quality while accepting practical line-ending variations.
Network errors such as Broken pipe normally mean the peer closed the socket. The server removes the session, cancels the opposite read loop, and emits one clean disconnection reason. Source and GGA inactivity timers catch silent sessions that do not close normally.
Dashboard, map, and management views
The map identifies each active station by mountpoint and each rover by user account and RTK mode. A clickable base-rover line provides the distance in kilometers. The view fits markers on initial load or on explicit operator action; routine position updates do not force the map to pan.
Management lists complement spatial monitoring. Station records include description, format, country, coordinates, permanent status, service radius, RINEX policy, and originating caster. Rover records show identity, active state, last connection, selected mountpoint, and remote address.
Operators can manage local mountpoints and upstream casters from the same control environment. When configuration changes, the server reloads the affected tenant and disconnects sessions that no longer have valid accounts or source declarations.
Security and operational boundaries
HTTPS protects control-center credentials and tokens. NTRIP Basic authentication does not encrypt the stream by itself, so TLS or a private transport is preferred when receivers support it. Configurable per-account connection limits support shared credentials, while one credential per rover with a limit of 1 provides the clearest attribution.
IP addresses and User-Agent strings are useful context but not stable hardware identity. MAC addresses do not traverse the Internet. Client TLS certificates can provide stronger device identity only when the operator controls certificate issuance, installation, and revocation.
Rover positions are operational data and may be sensitive. Retention should be documented, limited, and isolated by tenant. The system is a correction-service monitor, not a general employee-surveillance or fleet-safety platform.
Upstream caster credentials are stored server-side in tenant-specific protected files and are never returned by the API. Outbound connections reject private and loopback destinations to reduce server-side request forgery risk.
Operational use cases
A support technician can verify that a field rover authenticated, selected the expected mountpoint, sent GGA, and moved from Float to Fix. A network operator can see that a permanent station stopped producing bytes before users report a problem. A manager can review availability and session history without exposing another company’s data.
A surveying company can restrict a station to a defined service radius and guide a rover toward a closer base. A CORS operator can archive hourly RINEX for quality checks, PPK, or PPP. A multi-site organization can share one platform while retaining separate domains, accounts, sourcetables, and dashboards.
| Situation | Observed evidence | Possible action |
|---|---|---|
| Rover remains Float | GGA mode, distance, stream age, mountpoint | Check sky view, RTCM content, or select a closer service |
| Station is silent | Last packet, TCP state, source metadata | Inspect power, modem, receiver, and antenna |
| Access is rejected | Tenant, user, mountpoint, reason | Correct account, subscription, or declaration |
| Service audit | History, uptime, volumes, RINEX | Measure quality and plan maintenance |
GNSS control center FAQ
What does a GNSS control center monitor?
It combines the status of reference stations, NTRIP connections, RTCM streams, rover GGA positions, RTK modes, alerts, and recent history in one operational view.
Is the control center tied to one receiver brand?
No. Interoperability is based primarily on NTRIP, RTCM, and NMEA support. Actual message availability still depends on the receiver model and firmware.
Can one company see another company’s mountpoints?
No. Tenant resolution, authorization, sourcetable filtering, and direct mountpoint checks are performed server-side so each organization only accesses its own resources.
Does a Fix label guarantee survey accuracy?
No. Fix describes the ambiguity state reported by the rover. Coordinates, reference frame, antenna setup, multipath, field procedures, and independent checks still determine the reliability of a survey.