Design & architecture
Ethernet and PTP on board: a flight-test network that keeps time
Ethernet has replaced most point-to-point links in flight-test installations: one cable per zone, every unit reachable for configuration, the same data sent to the recorder, the telemetry and the screens at once. Such a network is easy to build and easy to get subtly wrong, mostly on time. Here is what to design, what to buy, and what to check.
Why flight test moved to Ethernet
The older pattern — one PCM encoder per zone, each with its own cable to the recorder and the transmitter — scales badly. Ethernet replaces it with a network: acquisition units, cameras, recorders, the telemetry transmitter and the on-board displays share switched gigabit links, every unit can be configured from one laptop, and the same data reaches several destinations without extra wiring.
What the network does not give for free is determinism. A PCM link has a fixed bit rate and a fixed latency; a switched network has queues. The design work is about keeping those queues short, and keeping time across them.
What travels on the network
- Data streams: UDP packets, usually multicast, in a flight-test format — IRIG 106 Chapter 10 packets over UDP, IENA, or a manufacturer's own — sent once by each unit to every subscriber.
- Video: compressed camera streams, often the largest flows on the network, the cameras sometimes powered over the same cable.
- Time: PTP messages between the grandmaster and every unit, in both directions.
- Control: configuration, status and health monitoring — small in volume, but it must still get through when the links are busy.
Bandwidth: budget each link, not the network
Gigabit Ethernet sounds limitless next to a few megabits of PCM. The trap is that the limit applies link by link, and the busiest link is usually the one to the recorder or the transmitter, where every stream converges. Add up, for each link, the streams that cross it at the worst moment — every camera at its highest bit rate, every unit at full rate, a configuration download on top — and keep a real margin: a link at 60 % of its capacity on paper is already exposed to bursts.
When a link saturates, the switch drops packets. UDP does not retransmit, and the receiver cannot tell what it missed unless the format numbers its packets; Chapter 10 does, channel by channel. Read the drop counters of every switch port after the first flights, not only when something looks wrong.
Multicast, IGMP and VLANs
Multicast lets a unit send a stream once and every subscriber receive it. Left alone, a switch floods multicast to every port, and a small unit or the telemetry transmitter ends up receiving all the video on the aircraft. IGMP snooping fixes that: the switch learns which ports asked for which group and forwards each stream only there. It needs an IGMP querier somewhere on the network, often the switch itself.
VLANs separate traffic that must not mix — the aircraft's own network if the installation is connected to it, test data, video, maintenance access — and priorities can then be set per class, so that time and control messages never wait behind a burst of video.
Time across switches: where PTP succeeds or fails
PTP measures the delay between master and slave with time-stamped messages, and assumes that delay is the same in both directions. A switch that simply stores and forwards packets breaks that assumption: how long a PTP message waits in its queue depends on the traffic at that instant, and the variation goes straight into the time error.
- Transparent clock: the switch measures how long each PTP message stayed inside it and adds that residence time to the message, so the slave can remove it.
- Boundary clock: the switch synchronises to the master on one port and acts as master on the others, so each unit sees a single hop.
- Ordinary switch: forwards PTP like any other packet. Acceptable on a quiet segment where microseconds do not matter; not on a link shared with video.
scroll
The grandmaster
The grandmaster is the clock every other device follows, usually disciplined by GPS, sometimes by an IRIG-B input. Its quality sets that of the installation, and so does its honesty: it should announce whether it is locked to GPS or running on its own oscillator, so that units and analysis tools can tell a traceable time from a free-running one.
Cabling, power and environment
On board, the network is built from rugged parts: circular connectors such as MIL-DTL-38999 rather than RJ45, shielded cable rated for its zone, switches qualified to DO-160 or MIL-STD-810 for the vibration, temperature and electromagnetic environment where they sit. Power over Ethernet simplifies cameras and small sensors — one cable for data and power — but its budget adds to the switch's own dissipation, in a box often cooled by conduction alone.
Keep the topology simple enough to be understood by whoever is on duty before a flight: a star or a small tree, no loops unless a spanning-tree protocol is configured on purpose, documented addresses and groups, and a maintenance port that does not sit on the data path.
Checks before the first flight
- Run every stream at its highest rate at the same time, and read the drop counters of every switch port.
- Check that each multicast group reaches only the ports that subscribed to it.
- On every unit, read the PTP offset to the master and how much it varies — with the video running, not on a quiet network.
- Disconnect the GPS antenna and check that the grandmaster says so, and that the units and the recording log it.
- Power-cycle a switch in flight configuration and time how long the network takes to come back, time and streams included.