A GNSS receiver interface control document (ICD) turns an integration discussion into a traceable engineering handoff. It records what the receiver exposes, what the host platform expects, and which evidence must be collected before an anti-jamming antenna or terminal is selected.
This guide is a documentation framework, not a compatibility claim. Receiver behavior, supported signals, timing accuracy, environmental limits and installation suitability must be confirmed from current manufacturer documentation and project-specific test evidence.
Why the receiver ICD matters
A receiver may provide several electrical and data interfaces, yet a project can still fail if connector pinouts, voltage levels, message timing or configuration ownership remain ambiguous. A useful ICD creates one controlled reference for the GNSS receiver, the anti-jamming equipment, the host computer and the installation team.
Before requesting a quotation, pair this document with the GNSS receiver compatibility checklist and the GNSS anti-jamming installation checklist.
1. Identify the receiver configuration
- Manufacturer, exact model and hardware revision.
- Firmware version and the configuration file or command set used for testing.
- Enabled constellations, frequency bands and signal-processing modes.
- Antenna input type, connector, impedance and any documented bias supply.
- Known restrictions, open deviations and the owner responsible for approval.
Do not use a family name where a specific receiver variant is required. A small suffix or firmware change can alter ports, messages or timing behavior.
2. Document timing interfaces
Record each timing output separately. Typical items include 1PPS, time-of-day messages, event inputs and synchronized network time. For every interface, document the connector and pin, electrical level, polarity, reference edge, configured message, update rate and the condition under which the output is valid.
| Timing item | Required ICD entry | Acceptance evidence |
|---|---|---|
| 1PPS | Pin, voltage level, polarity, reference edge and validity condition | Oscilloscope capture and receiver status record |
| Time message | Protocol, message identifier, baud rate and relation to 1PPS | Timestamped serial log and parser output |
| Event input | Electrical limits, trigger edge and event message behavior | Stimulus record and correlated receiver log |
| Network timing | Protocol, address settings, synchronization state and fallback behavior | Packet capture and host status record |
Do not copy a nominal accuracy value into the ICD unless the applicable operating conditions and the evidence source are also cited.
3. Define serial, USB and Ethernet ports
For every physical port, specify its function and ownership. A complete entry normally includes connector, pinout, electrical standard, baud rate or link speed, framing, protocol, message set, update rate, command permissions and startup behavior.
- Separate configuration ports from operational data ports.
- State whether settings persist after power cycling.
- Record any port shared with diagnostics or firmware updates.
- Define how the host detects invalid, stale or absent navigation data.
- Attach a captured data sample using the intended production configuration.
URLs, IP addresses, serial settings and query parameters should be copied exactly. They should not be translated or reformatted in multilingual project documentation.
4. Control power, grounding and antenna-bias details
The ICD should identify the receiver supply range from approved documentation, expected power state transitions, grounding reference, shield termination and any antenna-bias output. If an anti-jamming terminal sits between the antenna and receiver, confirm which device supplies bias power and how DC paths are managed.
Record connector part numbers, mating connectors, cable assembly identifiers and service-access constraints. Do not assume that a mechanically compatible connector has the correct pinout or power behavior.
5. Protect configuration and change control
Assign a version to the ICD and to every referenced drawing, log and configuration file. When the receiver firmware, antenna path, host software or message configuration changes, repeat the affected acceptance checks and update the source version.
A practical change record includes the previous value, new value, reason, approval owner, affected tests and the evidence package generated after the change.
Acceptance evidence matrix
| Interface | Evidence to retain | Review question |
|---|---|---|
| RF antenna path | Drawing, cable list, connector data and installation photographs | Is the documented RF path identical to the tested path? |
| Navigation data | Raw log, decoded message report and host parser result | Can the host identify valid, invalid and stale data? |
| Timing | 1PPS capture, time-message log and correlation note | Are the reference edge and message epoch unambiguous? |
| Power | Wiring diagram, startup capture and fault-state record | Are supply, return and bias responsibilities defined? |
| Configuration | Exported settings, firmware identity and checksum | Can the tested configuration be reproduced? |
RFQ handoff checklist
- Provide the exact receiver model, hardware revision and firmware version.
- Attach the receiver interface documentation and the project-specific ICD.
- List enabled GNSS signals, receiver input constraints and antenna-bias behavior.
- Provide mechanical drawings, available envelope, cable routes and connector requirements.
- Describe host interfaces, message rates, timing outputs and configuration ownership.
- State environmental and installation constraints that require engineering review.
- Identify the acceptance tests and evidence required before release.
Use the ResiNav RFQ page to send the controlled input set. Product selection should remain provisional until the receiver, RF path, mechanical installation and acceptance criteria have been reviewed together.
Frequently asked questions
Is a receiver datasheet enough for an integration review?
No. A datasheet is an important source, but the project also needs the exact receiver variant, firmware, enabled configuration, host interfaces, installation constraints and acceptance evidence.
Should the ICD include measured results?
Yes, when measurements are available and traceable. Keep measured results separate from requirements, and identify the test configuration, equipment and date.
Can one ICD cover several receiver models?
Only when the interfaces and behavior are demonstrably identical for the controlled scope. Otherwise, use model-specific sections or separate versions.
When should the ICD be updated?
Update it whenever a controlled interface, configuration, cable, firmware, host parser or acceptance criterion changes. The revised source version should trigger a review of every translated copy.
Next engineering step
After the ICD is complete, compare the documented receiver constraints with the ResiNav product catalogue. Final suitability, configuration and test scope remain subject to engineering confirmation.
NEXT STEP
Turn available platform information into an engineering review.
Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.