Networked Telemetry Changes What IRIG 106 Has to Prove
Networked telemetry under IRIG 106 turns flight-test instrumentation into a managed data network. The hard work moves from cable paths alone to timing, metadata, identity, packet loss, security, and trusted recording.
Polyrhythm has designed modern IP-based telemetry links for flight test, so networked telemetry under the IRIG 106 series is a problem space we know from the cable up.
IRIG 106 is the Range Commanders Council telemetry standard for aeronautical telemetry interoperability. The IRIG 106 site describes it as a comprehensive telemetry standard for RCC member ranges, and the IRIG 106-23 table of contents includes the Telemetry Network Standard chapters. Chapter 23 defines the Metadata Description Language for network-based telemetry configuration in a common form.
That shift changes the engineering problem. Legacy PCM telemetry is often thought of as a one-way stream. Networked telemetry is addressable, configurable, and capable of carrying much more data. It also has failure modes that look more like network engineering than old instrumentation practice.
The cable swap is the easy part. Every instrument now needs a time model. Every endpoint needs identity. Every data path needs configuration. Every recorder has to prove what it received and what it missed. If packets drop, the team needs to know whether the loss matters for the test objective.
Metadata becomes central. The IRIG 106 Chapter 23 Metadata Description Language is meant to describe configuration information, component relationships, and telemetry system structure. That matters because vendor-agnostic configuration works only if the schema, time, and identity layers are agreed across the range.
Security also changes. A networked test article is a network endpoint. That endpoint may sit in a lab, on a ramp, in a chase setup, or across a range network. The team has to decide how devices are addressed, who can configure them, how keys are handled, and how test operations recover when a node misbehaves.
The recording chain becomes a software evidence problem. A flight test may depend on proving that data was captured, time-aligned, and preserved. If the telemetry network is not well configured, engineers can end up debating whether an anomaly came from the aircraft, the instrumentation, the network, or the recorder.
Tooling has to support that evidence. Engineers need configuration checks before the mission, health monitoring during the mission, and post-flight records that connect packet-level behavior to engineering data. Without that chain, the network can move more data while making the final evidence harder to defend.
The operator workflow has to change too. Range teams need to treat telemetry configuration like software configuration. A changed node, schema, or timing source should be reviewed with the same care as a changed test procedure because it can alter the data record.
Modern flight test is a software problem with sensors attached. The sensor still matters. The wire still matters. But the trusted product is data with context: time, configuration, identity, provenance, and known gaps.
Networked telemetry makes that context richer and more useful when the architecture is disciplined. It makes it harder to trust when configuration drifts. Data you cannot trust is data you eventually re-fly, and that is the cost every flight-test program is trying to avoid when assets, crews, instrumentation, and range time are scarce.