Introduction
The ability to log raw GNSS data is what separates a precision navigation workflow from a simple navigation application. Raw data enables post-processing, quality assessment, algorithm development, and forensic analysis of positioning errors. Understanding what raw GNSS data consists of, how to capture it, and how to manage it effectively is a foundational skill for any serious GNSS practitioner.
What Raw GNSS Data Actually Is
A GNSS receiver internally computes several fundamental measurements from each tracked satellite signal. These measurements - the raw observables - are the basis for all position computation, and they are far more information-rich than the final position output.
Pseudorange
The pseudorange is the apparent distance from satellite to receiver, computed by multiplying the measured signal travel time by the speed of light. It is called a ''pseudo'' range because it is contaminated by receiver clock error, satellite clock error, and atmospheric delays. Pseudoranges from the code phase (C/A code or P-code) have precisions of around 1–3 metres for a good civilian receiver under open-sky conditions.
Carrier Phase
The carrier phase measurement tracks the phase of the satellite''s radio carrier wave - the underlying sine wave at L1 (1575.42 MHz) or L5 (1176.45 MHz). Because the carrier wavelength is approximately 19 cm (L1) or 25 cm (L5), carrier phase measurements have millimetre-level precision. The challenge is the integer ambiguity - the receiver cannot initially determine how many full wavelengths exist between satellite and receiver. Resolving this ambiguity is the basis of RTK and PPK techniques.
Doppler
The Doppler measurement captures the rate of change of the carrier phase, which corresponds to the radial velocity between satellite and receiver. Doppler measurements are used to compute receiver velocity, to assist carrier phase tracking, and to detect anomalous satellite behaviour.
Signal-to-Noise Ratio (SNR / C/Nâ‚€)
The signal-to-noise ratio - often expressed as carrier-to-noise density ratio C/Nâ‚€ in dB-Hz - indicates the quality of the received signal. Typical open-sky values are 40–55 dB-Hz. Values below 30 dB-Hz indicate a weak or obstructed signal; values consistently below 25 dB-Hz typically make reliable carrier phase tracking impossible.
Receiver Output Formats
Receivers make raw data available in several formats, each suited to different use cases.
NMEA-0183
NMEA is the most universally supported output format. It is human-readable ASCII text. Common sentences include GGA (position, fix quality, altitude), RMC (position, velocity, time), GSA (active satellites, DOP values), and GSV (satellites in view, elevation, azimuth, SNR). NMEA is ideal for real-time display and simple position logging, but it truncates coordinates to the 0.0001-minute level (roughly 20 cm precision) and does not carry raw pseudorange or carrier phase data. It is therefore insufficient for post-processing to centimetre accuracy.
Proprietary Binary Formats
Every major receiver manufacturer provides a proprietary binary format that carries the full resolution raw measurements. u-blox uses the UBX protocol; NovAtel uses the OEM7 binary format; Trimble uses the T02 format; Septentrio uses SBF. These formats carry pseudoranges, carrier phases, Doppler, and SNR for every tracked signal, at full receiver resolution. They must be converted to the open RINEX format for use with standard post-processing software.
RTCM Raw (MSM Messages)
RTCM 3.x Multiple Signal Messages (MSM4, MSM5, MSM7) are a standardised binary format for transmitting raw observations. MSM4 carries pseudorange and carrier phase; MSM5 adds Doppler; MSM7 provides the highest resolution pseudorange and carrier phase. RTCM MSM messages are increasingly used for raw data logging as well as correction transmission, since they are receiver-independent.
Logging Hardware
The choice of logging hardware depends on the application requirements for data rate, storage duration, and environmental robustness.
- Data loggers with integrated storage: Dedicated GNSS data loggers from manufacturers such as Emlid, u-blox, and Tersus provide turnkey logging to microSD cards with time-stamped raw data.
- Single-board computers (SBCs): Raspberry Pi, Jetson Nano, or similar SBCs running Linux can log serial or USB data from any receiver, enabling flexible format selection and integration with other sensors for synchronised multi-sensor logging.
- SD cards and USB storage: Storage media selection matters - industrial-grade SD cards with SLC flash are preferred for applications requiring sustained high write rates (10 Hz raw data) or extreme temperatures.
| Logging Rate | Data Size (1 hour, 4 constellations raw) | Typical Application |
|---|---|---|
| 1 Hz | ~10 MB | Static surveying, slow assets |
| 5 Hz | ~50 MB | Vehicle tracking, mapping |
| 10 Hz | ~100 MB | RTK/PPK rover, UAV |
| 20 Hz | ~200 MB | High-speed dynamics, vibration testing |
| Raw (100 Hz IMF) | ~1 GB | Research, deep integration testing |
Common Logging Mistakes
Several frequently encountered logging errors can invalidate an entire dataset:
- Logging only NMEA: NMEA cannot be used for post-processing to sub-metre accuracy - raw binary or RINEX format is required.
- Insufficient logging rate: Logging at 1 Hz for a fast-moving platform means carrier phase continuity is lost between epochs, preventing ambiguity resolution.
- Missing antenna information: Failure to record the exact antenna model and height above the ground mark makes the logged data unusable for precise vertical positioning.
- Unsynchronised multi-sensor logs: If GNSS and IMU logs are recorded to separate clocks without a common hardware pulse (e.g., PPS signal), temporal alignment in post-processing becomes unreliable.