RTK / GNSS GERMANY · V1.1.0
DEEN

Technical information and requirements intake · no product performance promise

A testable acceptance plan

Engineering proposal for agreement; neither product performance nor a legal threshold.

Technical request ↓

Define the metrics

Per-point horizontal error: sqrt(ΔE² + ΔN²); vertical error: ΔH. RMSE_H = sqrt(mean(ΔE² + ΔN²)), RMSE_V = sqrt(mean(ΔH²)). Also report bias, 95th percentile, maximum error, sample count and failures. CEP is a 50% radius; RMS, 1σ and 95% are not interchangeable without distribution and dimensional assumptions.

Time and availability

Measure time to Fixed from a defined starting state, such as valid correction input; separate cold and warm starts. Re-fix begins after a defined interruption ends. Report median, 95th percentile and failures to fix. Fixed fraction = Fixed epochs / all expected epochs in the test window; do not silently remove missing data.

Test plan and records

Proposal: three independent repetitions per approved scenario, separate calibration and checkpoints, documented reference uncertainty. Scenarios: open sky, realistic obstruction, defined link interruption and reinitialisation. Store configuration, firmware, base CRS, baseline, weather, raw GNSS, timing events and processing version. H/V, fix-time and availability thresholds remain open until buyer approval.

Results beyond a status light

A tightly clustered series can be systematically displaced by incorrect base coordinates. Assess repeatability and absolute error separately. Accept orthophoto/point-cloud output against independent object checkpoints, not receiver status alone.

Relevant next steps

Technical request

Request context

Stored in the platform inbox; technical ownership and delivery scope await assignment. No automatic supplier notification.

RTK / GNSS · A testable acceptance plan
RTK Germany technical report v1.0.0 · EN · 7