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.
Choose the output you need before choosing the port. Position, velocity and time (PVT) describe navigation results. Satellite observations and receiver diagnostics answer different questions. A recorded position stream is not automatically an observation dataset, and saving the original serial bytes does not change which information the receiver exported.
| What your software needs to do | Output to identify in the offer | What is not a substitute |
|---|---|---|
| Consume a computed navigation result | The required position, velocity and time fields, with the documented epoch and validity information needed by the host. | A list of tracked signals or an RF-output specification does not identify that navigation-data interface. |
| Compute a solution from satellite measurements or perform observation-based post-processing | The measurements the intended software requires—such as pseudorange, carrier phase or Doppler—identified by satellite, signal and epoch, with the required units and measurement-status fields. | A saved PVT trajectory does not provide the underlying satellite observations. Also confirm that the exported format contains the required measurements and can be read by the intended software. |
| Investigate receiver or interface behavior | The documented status, error and diagnostic records relevant to that investigation, including their field meanings and output conditions. | A valid position alone is not a complete fault record. A diagnostic flag does not automatically provide a spectrum recording or identify an interference source. |
These categories can overlap within a message; compare the required fields, not the filename or the word “log”. NovAtel’s OEM7 documentation illustrates the distinction: BESTPOS reports a computed position and solution status; RANGE reports satellite-channel measurements, including pseudorange, carrier phase and Doppler; RXSTATUS reports receiver status and errors. These are NovAtel examples, not ResiNav message formats or a compatibility endorsement.
If your software consumes PVT, compare that deliverable without automatically adding an observation-logging requirement. If it requires satellite measurements, a PVT-only demonstration leaves that requirement unanswered: retain the offer for that workflow only when the required observation output and usable export path are documented. Diagnostics should be selected for the fault question they must answer, not treated as a synonym for raw observations.
For a workflow that needs navigation during operation and a trajectory after collection, compare real-time GNSS/INS navigation and post-mission processing as separate deliverables.
When adding inertial navigation while retaining a receiver, compare loosely and tightly coupled GNSS/INS by the data that receiver can actually supply.
Do not use a family name where a specific receiver variant is required. Record the exact model, firmware and enabled output set; then apply the port-capacity calculation in section 3 to the messages actually included.
For a ResiNav PVT enquiry, the current RN2501-AJS-4CH-DPA configuration provides PVT through its HDMI interface without a separate GNSS receiver to obtain those outputs. That confirmation does not establish raw-observation export or diagnostic logging, and HDMI here is not a promise of video or display compatibility. You can start an RN2501 enquiry with the output your software needs and the information already available; model-specific interface and pinout documentation is provided during quotation.
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.
If you are buying RF interference protection for a timing receiver, use the GNSS timing procurement guide to distinguish the required time output from RF protection and assess the added RF path against an end-to-end time-error budget.
3. Check whether the message schedule fits the port
Specify the actual electrical standard, framing and output schedule before buying a receiver interface or host adapter. A matching connector is not evidence that voltage levels or protocols match. For a conventional asynchronous serial link configured as 8N1, each transmitted byte occupies ten bits: one start bit, eight data bits and one stop bit. A useful first estimate is required bit rate = sum of (message bytes × messages per second) × 10. Include framing characters, checksums and terminators in the message lengths.
Worked example with invented message sizes: assume a navigation message is 88 bytes at 10 Hz, an observation message is 132 bytes at 5 Hz, and a status message is 64 bytes at 1 Hz. These are teaching inputs, not ResiNav message formats or measured receiver outputs. Assume all three travel in the same transmit direction using 8N1, with no flow-control pauses.
| Message group | Assumed bytes per message | Messages per second | Bytes per second |
|---|---|---|---|
| Navigation | 88 | 10 | 880 |
| Observations | 132 | 5 | 660 |
| Status | 64 | 1 | 64 |
| Total | Each length includes its message overhead | Mixed schedule | 1,604 bytes/s, or 16,040 bits/s under 8N1 |
The schedule needs about 167.1% of a 9,600 bit/s link, so that link cannot continuously carry it as specified. It uses about 41.8% at 38,400 bit/s or 13.9% at 115,200 bit/s. Those percentages are arithmetic, not recommended utilization limits. A device must actually support the chosen setting at both ends; average headroom does not prove that simultaneous message bursts, buffering or host processing meet the timing requirement.
For the same example, an 88-byte message alone takes about 22.9 ms to serialize at 38,400 bit/s. That is transport time, not receiver calculation time or the age of the position when a controller uses it. Keep those quantities separate when comparing a stated update rate with a platform requirement.
Choose the least disruptive way to resolve a bandwidth shortfall
| Option to investigate | What it changes | What must remain true |
|---|---|---|
| Reduce nonessential message rates | Reduces the offered load without changing the physical link. | Required status, time and fault indications still reach the host often enough; do not discard them merely to fit a nominal budget. |
| Use a supported higher serial rate | Shortens transmission time per byte. | Both endpoints, the electrical interface and the installed path support the setting, including after restart. |
| Use a documented compact format | May reduce bytes for the required information. | The host parser supports that exact format and revision; “binary” alone does not guarantee equivalent fields. |
| Move diagnostics to another documented port or transport | Can separate operational traffic from larger diagnostic bursts. | The receiver exposes that route, host software can consume it, and required timing relationships are preserved. |
NovAtel’s OEM7 serial communication guidance illustrates framing overhead and warns that insufficient port throughput can lead to lost data. Its settings and supported ports belong to the specified NovAtel products, not to ResiNav. Use the exact receiver manual and a representative captured output to replace the hypothetical sizes above.
In the ICD, keep a compact calculation row for every message: identifier | maximum expected bytes | frequency or trigger | destination port | reason the host needs it. Also record command permissions, power-up defaults, persistent settings and any shared diagnostic traffic. This makes a proposed change measurable instead of relying on “high-speed output” as a buying criterion.
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? |
Carry the evaluated interface into the purchase decision
Use the ICD to identify the receiver variant and the message schedule that was evaluated. If a quotation proposes different firmware, enabled output or host interface, compare that change with the bandwidth and timing assumptions before accepting it. The published ResiNav datasheets identify documented product configurations; they do not define a third-party receiver’s serial protocol.
For data that arrives but may no longer be usable, pair this calculation with the GNSS freshness and monitoring guide. Transport capacity and application acceptance are different decisions.
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. Identify the affected acceptance checks and notify the teams using the previous interface definition.