Monitoring goals
A process responding to a health check does not prove that a GNSS service is healthy. A station can hold a TCP connection without sending messages, a rover can receive data while remaining Float, and a published mountpoint can contain inconsistent coordinates. Monitoring therefore combines infrastructure health, NTRIP activity, and GNSS information.
Fast detection uses last-packet age and connection events. Explanation uses tenant, user, mountpoint, remote address, User-Agent, and rejection reasons. Long-term measurement uses outage duration, session counts, transferred volume, and RTK mode trends.
These layers help support teams verify what actually crossed the server before asking field users to change receiver settings.
Station and RTCM indicators
An active source has a tenant, session ID, mountpoint, remote endpoint, connection time, and last-data time. Duplicate use of the same mountpoint is rejected so rovers never receive competing producers under one name.
RTCM 1005 and 1006 provide station ID and ECEF coordinates; 1006 adds antenna height. Messages 1007, 1008, and 1033 can describe equipment. Changes after maintenance can be surfaced for operator review.
Permanent-station rules open an incident after a configurable delay, notify the appropriate contacts, and close the incident when data returns. Alert deduplication prevents repeated messages for one outage.
Rover position and RTK mode
A rover account provides the operational identity. Public IP and User-Agent are supporting evidence, not hardware serial numbers. A GGA sentence supplies latitude, longitude, altitude, and a quality value that can be mapped to Fix, Float, or Single.
GGA cadence varies by receiver. Requiring the first GGA before RTCM is appropriate for location-dependent services but may reject clients that never send it. The policy and timeout must be configurable.
Base-rover distance gives immediate context and can enforce a service radius. The rejection reason must be clear when a policy blocks the rover.
Alerts and incident handling
An actionable alert identifies the tenant, device, UTC time, observed condition, and last activity. Email or messaging failure must not stop RTCM distribution; it is logged and retried with a bounded policy.
Delay thresholds avoid false alarms during brief mobile reconnections. Permanent and temporary stations can follow different schedules. Planned maintenance can suppress notifications without removing the underlying events.
An incident has a start, updates, and recovery. This structure supports uptime, mean time to restore, and interruption-count metrics. Repeated short outages often reveal an unstable modem or power supply.
History, retention, and statistics
WebSocket events are only received while the control center is connected. A bounded history API restores recent positions and connection events at sign-in. Active markers are then maintained by live events.
Retention must match the purpose. A 24-hour rover history provides operational context, but fifty clients sending every five seconds already produce 864,000 positions per day. Compact storage, indexes, limits, and periodic cleanup are mandatory.
Key statistics include station uptime, unique rovers, session duration, Fix/Float distribution, most-used mountpoints, rejection reasons, and transferred bytes. Every query remains tenant-scoped.
| Indicator | Source | Purpose |
|---|---|---|
| Last RTCM age | Source read loop | Detect a silent station |
| Fix/Float/Single | Rover NMEA GGA | Observe operational positioning state |
| Base-rover distance | Station and client positions | Check baseline policy |
| Incident duration | Outage and recovery events | Measure service availability |
A structured diagnosis method
Start with DNS, listening port, firewall, and service state. Then verify source authentication, declared mountpoint, and recent bytes. Next inspect rover authentication, success response, initial RTCM writes, GGA, and RTK mode.
Broken pipe means the remote endpoint closed during a write. It should produce one disconnection event, not repeated failure stacks. A TLS handshake on a plain port should generate a clear protocol warning rather than unreadable text.
If the network path is healthy but the rover remains Float, inspect RTCM message content, correction age, baseline, constellations, sky view, antenna setup, coordinate frame, and field control points.
GNSS monitoring FAQ
Why monitor the age of the last RTCM packet?
A TCP connection may remain open even when a receiver has stopped producing data. Last-packet age detects this silent-source condition.
Where do rover coordinates and RTK mode come from?
They are commonly extracted from the NMEA GGA sentence sent by the NTRIP client. The quality field can be mapped to operational labels such as Fix, Float, or Single.
How much rover history should be kept?
Retention should be explicit and bounded. A 24-hour operational window often provides useful context while periodic cleanup and query limits protect memory and storage.