GNSS Positioning
Post-process recorded observations into a position — choose a method, add your files, run. Everything runs in your browser; only public orbit, clock and antenna products are fetched.
Set up a PPP run
ObservationsDual-frequency · processed in your browser
Observation file or receiver logRINEX 2/3/4 (also Hatanaka / gzip), u-blox UBX, Septentrio SBF, NovAtel, Trimble, BINEX, RTCM3 or an Android GnssLogger log. GPS L1/L2 or L1/L5, Galileo E1/E5a, BeiDou B1I/B3I.
Receiver
Precision
Ocean tide loading: automatic
Near tidal coasts the crust moves by centimetres under the ocean tides. It averages out of a full day, but in sessions of a few hours it biases the height by up to a few centimetres (Brest, 2 h: 48 mm → 16 mm scatter). By default it is applied everywhere from our own global grid: the GOT4.10c ocean tide model (NASA) loaded onto an elastic Earth, typically within a millimetre of Onsala's coefficients.
To use a specific model instead, get your station's coefficients in BLQ format from the free Onsala ocean loading service (model FES2014b, centre-of-mass correction on) and paste them here; the station name must match the file's marker (first 4 characters). A BLQ entry takes precedence over the grid.
Fixed for every run: IGS20 satellite and receiver antenna calibrations, solid-earth tides and phase wind-up.
Surveying a base station
- 1RecordLog raw observations for 4 h or more (24 h is best) — a receiver log or RINEX, or record its stream on /stream.
- 2Wait a dayPrecise orbits come out about a day later. Files keeps your recording for three days.
- 3Solve & copyAdd the file and compute: the coordinate is ready for RTKBase, str2str, u-blox or Septentrio.
Set up an RTK run
ObservationsRINEX / CRINEX, gzip OK · same time window
Base stationA receiver on a known point — its RINEX header’s APPROX POSITION is used as the base coordinate.
RoverThe receiver to position, recorded over the same time as the base.
Rover motion
Solution
Carrier phase with integer ambiguities (LAMBDA, ratio-tested) — centimetres where it fixes.
Navigation fileoptionalBroadcast ephemerides for the day are fetched from BKG automatically — add a RINEX nav file to use your own.
Post-processing a baseline
- 1BaseA RINEX file from a receiver on a known point — yours, or a permanent station nearby (suggested once the rover is in).
- 2RoverThe receiver to position, logged over the same window. Up to ~20 km from the base for fixed solutions.
- 3ProcessThe browser equivalent of RTKLIB’s
rnx2rtkp: a track, fix rate and baseline, exportable as KML, GPX or .pos.
Set up a receiver comparison
ObservationsSame antenna · same time window · no ephemeris needed
Reference receiverThe receiver the other is measured against.
Receiver under testFed by the same antenna through a splitter.
What a zero baseline measures
- 1One antenna, two receiversSplit one antenna into both receivers and log RINEX from each over the same window.
- 2Everything else cancelsThe between-receiver difference removes geometry, atmosphere and multipath.
- 3What’s leftThe relative receiver clock (with its Allan deviation) and the inter-system biases.
Which method?
Every method turns satellite observations (code pseudoranges and, for the precise ones, carrier phase) plus corrections (orbits, clocks, atmosphere) into a position. What separates them is where the corrections come from and whether carrier phase is used.
| Method | You need | Accuracy | Where |
|---|---|---|---|
| SPP — single point | One receiver, broadcast orbits | 1–5 m | Live, QC |
| PPP — precise point | One dual-frequency receiver, a day’s wait for precise orbits | 1 cm (24 h) – 5 cm (1–2 h) | This page |
| RTK — post-processed | A base on a known point and a rover, same window | 1–2 cm relative, where fixed | This page |
| RTK — real time | A live rover plus a base or network stream | 1–2 cm relative | Live |
Related tools
- Stream Workbench — live SPP & RTK, message inspector and quality control from a real-time source
- Solution Viewer — inspect a .pos, GPX or KML track from any tool
- Quality Control — a full RINEX QC report: multipath, C/N0, completeness, SPP
- Campaign — many stations and sessions, network adjustment and velocities
- Coordinate Converter — frames, epochs, national grids and heights
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 recorded files and want the best position after the fact: PPP for an absolute coordinate from one receiver, RTK post-processing for a rover relative to a base. 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 centimetre accuracy from a few hours of data, where ordinary single-point positioning is metre-level.
- What do I need to upload for PPP?
- Dual-frequency observations, ideally a full day at 30-second sampling: a RINEX observation file (2.x/3.x/4.x, also Hatanaka-compressed or gzipped) or a raw receiver log — u-blox UBX, Septentrio SBF, NovAtel, Trimble, BINEX — or an RTCM3 capture, decoded in the browser. GPS needs L1 + L2 (P(Y) or L2C), Galileo E1/E5a, BeiDou B1I/B3I, code and phase. The precise orbit and clock product (ESA MGEX final, or GFZ rapid for recent days) is fetched automatically for the file’s day.
- Can I use it to set my RTK base station’s coordinate?
- Yes — that is what the static mode is for. Record 4 hours or more from the base (24 h is best), wait a day or two for the precise orbits, and drop the file: the result card gives the coordinate ready to paste into RTKBase/Centipede, RTKLIB str2str, a u-blox ZED-F9P fixed-mode (TMODE3) configuration or a Septentrio receiver, in ITRF2020, ETRF2000/ETRF2020 or NAD83(2011). With the receiver antenna’s IGS20 calibration applied it is good to about a centimetre from a full day; to cross-check, download the RINEX and submit it to NRCan CSRS-PPP or AUSPOS.
- How accurate is it, and does anything leave my machine?
- Float PPP with satellite and receiver antenna calibrations (IGS20), the antenna height, solid-earth tides and phase wind-up. On seven IGS stations it lands within about 1 cm of the station’s ITRF2020 coordinate from a full day of data, 1–2 cm from 6 hours and a few centimetres from 1–2 hours; kinematic mode tracks to a few centimetres once converged. The RINEX file is parsed and solved entirely in your browser — only the public precise-orbit product and the antenna calibrations are fetched.
- How old does the data need to be?
- About a day. PPP needs precise satellite orbits and clocks: ESA’s multi-GNSS final product where it exists (GPS, GLONASS, Galileo, BeiDou), otherwise GFZ’s rapid product (GPS, GLONASS, Galileo), published about a day after the observations. Data from today can be processed tomorrow.