Validation & Evaluation
From RF evidence to customer evaluation.
The initial research experiment uses open civil GPS signals. Initial feasibility work will confirm receiver and signal selection, source association, orbital-reference quality, and tracking observables before implementation. The first experiment will use a static test setup with independently bounded position and timing. Application to GNSS-dependent navigation and timing would require subsequent integration and validation.
1 / Establish RF evidence
Confirm a viable GPS measurement path, then collect live-sky and controlled deception/replay observations in a static test setup. Evaluate genuine signals and defined threat cases, including Doppler-matched deception and replay delay, against receiver, clock, position, and orbital-reference error budgets.
2 / Demonstrate hardware admission
Implement admission logic in FPGA hardware. Test latency, withholding, interface isolation, and resistance to bypass.
3 / Define integration requirements
Work with receiver providers and A-PNT integrators to identify required observables, host interfaces, deployment constraints, acceptable latency, and preference for embedded implementation licensing or an SES hardware module.
4 / Prepare a scoped technical evaluation
Work with a receiver provider or A-PNT integrator to identify a sponsor, agree on measurable success criteria, and define a representative data or lab test setup and integration interface.
Initial engineering target from program kickoff: Month 1—Confirm receiver and signal selection, source association, orbital-reference quality, and usable tracking observables. Define the threat cases, error budget, numerical acceptance criteria, and downstream interface. Months 2–3—collect RF evidence; Months 4–5—implement and test FPGA admission; Month 6—compare baseline and gated paths.
Proceed to FPGA implementation after confirming a viable measurement path and evidence supporting useful discrimination. Re-scope or stop if the measurement path is not viable; reassess the approach if the evidence does not support the intended benefit.
Integration discovery can proceed alongside technical development.
SES seeks paid evaluations or sponsored R&D, with scope and commercial terms agreed for each engagement.
Evaluation metrics
False acceptance and false rejection; observation window; admission latency; hardware requirements; integration burden; and incremental benefit over baseline.
These measurements will guide prototype refinement, integration requirements, and the choice between embedded implementation licensing and an SES hardware module. Customer evaluations will also establish pricing expectations, delivery costs, and production requirements.