Currently, QField's NTRIP client requires an external Bluetooth-connected GNSS receiver to apply RTK/RTCM corrections — the correction stream is forwarded to the external device, which performs the PVT (Position, Velocity, Time) computation internally, and QField simply consumes the resulting NMEA output.

This issue proposes evaluating the feasibility of a complementary, lower-precision pathway: applying differential (DGPS-style) corrections in software to the internal GNSS chipset's raw measurements, without requiring external hardware. This would not replace RTK workflows, but would provide a meaningful accuracy improvement (~5m → ~1-3m) for use cases where a geodetic-grade receiver isn't available or practical.

Motivation

Android has exposed raw GNSS measurements (pseudorange, Doppler, and in supported chipsets, carrier phase) via the GnssMeasurement API since Android 7.0 (Nougat). This enables applications to implement their own PVT solvers instead of relying solely on the OS-provided fused/black-box location fix.

Field-tested comparisons (same device, same route, internal GNSS only) show a noticeable accuracy improvement when NTRIP corrections are applied to the internal chipset's raw measurements versus standalone GNSS. This has been documented academically as well — e.g. PPP/DGPS solutions computed from smartphone raw measurements achieving significantly better results than the phone's internal fused solution (Satellite Navigation, Springer, 2021).

OruxMaps appears to implement (or at minimum enable, via its NTRIP + raw measurement logging support) this kind of software-side correction path, and its own users report visibly tighter tracks when NTRIP is active — even with no external antenna connected. This is consistent with published research using OruxMaps as a raw-measurement logging tool for DGPS/PPP evaluation on Android devices.

Why this matters for QField specifically

QField's current architecture treats GNSS positioning as fully delegated to either:

The OS-provided fused internal location (no correction applied), or

An external NMEA-outputting receiver (which performs its own corrected PVT)

There is no intermediate tier. For field users without access to (or budget for) an RTK-capable external receiver, this leaves standalone ~5m accuracy as the only internal option — even though the underlying Android hardware may support raw measurements capable of a meaningfully better fix via code-based (DGPS) corrections.

This would be particularly valuable for:

Reconnaissance / preliminary field surveys where cm-level accuracy isn't required but sub-5m matters

Users without access to RTK hardware

NGOs, students, and low-budget mapping projects using QField in the field

Proposed scope (for discussion, not a finished spec)

Investigate feasibility of consuming GnssMeasurement raw data (pseudorange/Doppler) on devices/chipsets that support it

Apply code-based (DGPS/RTCM 1004/1005 style) corrections from the existing NTRIP client to compute a corrected position independently of the internal fused provider

Explicitly not attempting carrier-phase RTK fix/float resolution in software — this is understood to be unreliable on most smartphone chipsets due to duty-cycling and antenna quality, and would misrepresent achievable accuracy

Surface this clearly in the UI as a distinct "DGPS (internal, code-based)" positioning source, separate from RTK Fixed/Float, so users are not misled about achievable precision

This would be opt-in and clearly documented as not a substitute for RTK — accuracy expectations should be explicitly bounded (~1-3m, not cm-level)

Known limitations to flag upfront

Duty-cycling on most Android chipsets interrupts continuous raw measurement collection unless "Force Full GNSS Measurements" is enabled in Developer Options — any implementation would depend on this OS-level setting

Internal phone antennas introduce significantly more multipath/noise than geodetic antennas, so carrier-phase-based fixes are not a realistic goal

Chipset support for raw measurements (especially carrier phase) varies significantly across Android devices and is effectively unsupported on iOS

This would add complexity to the positioning stack and should be carefully scoped to avoid conflicting with the existing, well-tested external-receiver RTK workflow

Questions for maintainers/community

Is there interest in a lower-precision, internal-only correction tier, or is this considered out of scope for QField's target professional survey use case?

Would this be better implemented as a QField core feature, or as a companion/plugin approach (similar to how mock-location workarounds are currently used for iOS/Android NTRIP clients)?

Are there known technical blockers (Qt/QML GNSS API limitations, cross-platform raw measurement access) that would make this impractical compared to other GIS/GPS apps like OruxMaps?

Happy to help test on Android devices with Qualcomm Snapdragon chipsets (raw measurement support confirmed) if this is seen as worth prototyping.