Skip to content
gnsscalc

Live Network

A watchlist of live GNSS stations — permanent stations from the station catalogue, or any NTRIP mountpoint or raw receiver stream — with each station's health at a glance, alerts when one changes, and the stream inspector one click away. Up to sixteen at once, decoded entirely in your browser.

How it works

  1. Add stations from the catalogue: search by id, name, city or network, pick them on the map, or take the ones nearest to you. Stations on casters that need a free account (BKG's IGS and EUREF casters, Kadaster) ask for the login once. Any other NTRIP mountpoint or tcp://host:port receiver stream can be added from its caster or pasted as a line.
  2. The list shows every station's verdict and why, data age, satellites and uptime; the map shows where they are. Pick one for its signals, its live position check and its events — or open it in /stream for every message.
  3. Turn on Notify for a desktop alert when a station degrades or recovers. It keeps working while you use other pages or the tab is in the background.
  4. The watchlist is kept in this browser (never with passwords) and is in the page address, so you can share it. Save the ones you use often under a name.

Related Tools

Live Network FAQ

What does the live network monitor?
Each station is watched live: data age (seconds since the last observation epoch), message types, satellites per constellation, data rate, cycle-slip rate, and — when a reference position is available — a live single-point position solution compared against it. Stations can be NTRIP mountpoints or raw TCP receiver streams, mixed freely in one grid.
What station formats are supported?
NTRIP mountpoints carrying RTCM3 (MSM observations), and raw streams speaking Septentrio SBF, u-blox UBX, NovAtel OEM binary, Trimble RT17/RT27, BINEX, or plain RTCM3 — mixed freely. Streams are format-detected from the bytes themselves — two checksum-valid frames decide — so no configuration is needed beyond tcp://host:port. A stream in a format the grid can’t decode is flagged “unsupported format” rather than reported as down — the connection is fine, the payload just isn’t one we read.
How is station health decided?
Data age over 10 seconds flags WARN and over 30 seconds DOWN (a fresh connection gets those 30 seconds to deliver its first bytes). A stream that is connected but has stopped sending something it used to — a message type such as 1005, or a whole constellation — is WARN, with what stopped as the reason. So is an elevated cycle-slip rate (over 10 slips per satellite-hour, once enough tracking time has accumulated). Otherwise the station is OK. The thresholds are editable.
How accurate is the live position, and what does the error tell me?
The position is a single-frequency single-point solution (SPP) from the live pseudoranges, compared against the station’s broadcast reference coordinates — it is a data-quality indicator, not a survey. Satellite orbits and clocks come from a same-day broadcast ephemeris and the ionosphere from a global ionosphere map (GIM), with the troposphere modelled by Saastamoinen; expect roughly sub-metre agreement. A sudden jump or drift in the ΔE/ΔN/ΔU error is the useful signal — it flags a receiver, antenna or data problem long before the numbers themselves matter.
What is a cycle slip?
A sudden jump in the carrier-phase measurement when a receiver briefly loses lock on a satellite signal. The grid runs Melbourne-Wübbena, geometry-free and code-phase detectors on the live stream and reports slips per satellite-hour — a key receiver and antenna health indicator.
What else does it notice?
Changes a station announces about itself — a moved reference position (RTCM 1005/1006) or a new antenna or receiver (1033) — and C/N0 drops that start at several stations within two minutes of each other. One station losing signal strength is usually local (snow, a cable); several at once point to something regional, such as interference or a solar radio burst. Both appear in the event log and, if enabled, as desktop notifications.
How does it relate to the stream inspector and the station catalogue?
Stations come from the catalogue: a permanent station shows its catalogue identity (id, name, networks, equipment) and links to its page, and every station page with a live stream has "Watch on /network". With the stream inspector it shares the live streams: stations you watch here keep running while you use other gnsscalc pages and appear in the Live pill, and "Open in /stream" hands one to the inspector — sky plot, every decoded message, full live quality control, RTK and recording — on the same connection, without reconnecting to the caster.
Can I record the stations?
Yes. Every station keeps the bytes it received (two to three hours of a typical RTCM base with up to eight stations, about half that with sixteen), and Export → RINEX writes observation and navigation files for all of them in one zip, or keeps them in Files for QC, PPP or Convert.
Can a browser really hold 16 streams at once?
Yes. Each stream is only a few kB/s, and because the relay is HTTPS the browser uses HTTP/2, which multiplexes all streams over a single connection (the old 6-connections-per-host limit only applies to HTTP/1.1). The decoding and positioning run in a background thread (a Web Worker), so the page stays responsive — sixteen TU Delft stations keep the page itself under 3 % busy.
Is anything stored?
No. Streams are decoded in your browser and statistics live only in the page — close the tab and everything is gone. Caster logins go to the caster through a relay that stores and logs nothing, are kept in this browser (listed in Settings), and the raw-TCP bridge is strictly read-only: nothing you send is ever forwarded to the receiver. Saved station lists stay in this browser and never include passwords.