Skip to content
gnsscalc

GNSS Positioning

Work out where you are from GNSS. Post-process a recorded RINEX file with Precise Point Positioning below for a decimetre-level absolute position — no base station — or position live from a real-time stream. Everything runs in your browser.

Positioning live instead? Open the stream workbench for real-time SPP & RTK from an NTRIP, TCP or USB source.

Precise Point Positioning (from a file)

Drop a dual-frequency RINEX observation file for an absolute decimetre-level position. Precise orbits and clocks are fetched automatically and the solve runs in your browser. For a full quality breakdown of the same file use QC.

Drop a dual-frequency RINEX observation file — or click to choose

GPS (L1/L2), Galileo (E1/E5a) and BeiDou (B1I/B3I), dual-frequency. A full day at 30 s is ideal. Precise orbits & clocks are fetched automatically; everything runs in your browser.

Post-processing RTK (base + rover)

Drop a base RINEX (with a known position) and a rover RINEX over the same window for a centimetre-level relative track — the browser equivalent of RTKLIB's rnx2rtkp. Broadcast ephemerides are fetched automatically; the solve runs locally.

Base stationRINEX/CRINEX with a known position (APPROX POSITION XYZ). Drop or click.
RoverThe receiver to position, over the same time window as the base.
Navigation file (optional — broadcast nav auto-fetched by day)
Navigation (RINEX)Drop a nav file to override the auto-fetched BKG BRDC.

Receiver comparison (zero baseline)

Drop two RINEX files from receivers sharing one antenna to compare their clocks: the between-receiver single difference cancels geometry, atmosphere and multipath, leaving the relative receiver clock (Allan deviation) and inter-system biases. No base position or ephemeris needed.

Reference receiver

Drop a RINEX obs file

Comparison receiver

Drop a RINEX obs file

Same-antenna (zero-baseline) pairs only — the single difference cancels geometry, atmosphere and multipath. No ephemeris needed.

How positioning works

Every method turns satellite observations (code pseudoranges, and for the precise methods carrier phase) plus corrections (satellite orbits and clocks, ionosphere and troposphere) into a position and an accuracy estimate. What separates them is the quality of the corrections and whether carrier phase is used:

Related Tools

Positioning FAQ

What are SPP, PPP and RTK?
They are the three ways to compute a GNSS position, in order of accuracy. SPP (single-point positioning) uses the broadcast ephemeris and code pseudoranges for a metre-level absolute position. PPP (precise point positioning) swaps in precise orbits/clocks and carrier phase for a decimetre-to-centimetre absolute position from one receiver — no base station. RTK (real-time kinematic) differences against a nearby base or network stream for centimetre positioning in real time.
Should I post-process a file or position live?
Post-process (this page) when you have a recorded RINEX observation file and want the best absolute position after the fact — that is PPP. Position live (the stream workbench) when you have a real-time feed from an NTRIP caster, TCP endpoint or a USB receiver and want SPP or RTK as data arrives.
What is Precise Point Positioning (PPP)?
PPP computes an absolute position from a single receiver — no base station — by using precise satellite orbits and clocks instead of the broadcast ephemeris, plus dual-frequency carrier phase. It reaches decimetre-to-centimetre accuracy where ordinary single-point positioning is metre-level.
What do I need to upload for PPP?
A dual-frequency RINEX observation file (GPS L1/L2 — C1W/C2W pseudorange and L1C/L2W carrier phase), ideally a full day at 30-second sampling. Hatanaka (CRINEX) and gzipped files are accepted. The precise orbit and clock product (ESA MGEX SP3) is fetched automatically for the file’s day.
How accurate is it, and does anything leave my machine?
This is static float PPP: it converges to the decimetre level (centimetre vertical) over a few hours. GPS-only float positioning is geometry-limited in the horizontal; multi-GNSS and integer ambiguity resolution are the path to centimetre. The RINEX file is parsed and solved entirely in your browser — only the public precise-orbit product is fetched (via a CORS proxy).
Why does it need data to be a few weeks old?
It uses ESA’s precise MGEX orbit/clock product. The final product has roughly a three-week latency; the rapid product (a day or two old) is used as a fallback. Very recent data may not have a precise product available yet.