Trace a signal to an operational result

Before the March 2016 ExoMars launch, ESA described a joint ESA/ASI rehearsal at Malindi. The plan connected the tracking station to the main control room at ESOC through data links and a voice loop. That published account explains preparation for acquiring a first signal; its predicted times should not be rewritten as measured arrival times.

The rehearsal matters because the receiving dish is only one boundary. The control team needs to know what the station detected, which spacecraft the data belongs to, and whether the information is usable. A message passed between teams must preserve its time and meaning rather than merely announce that something appeared on a display.

Detecting radio energy establishes a different fact from decoding valid mission data. A compatible receiver may detect a carrier while the subsequent data stream still fails its integrity checks. Valid received data then has to reach the intended control or processing system. Each stage has its own evidence.

Use an invented operations log: signal detected at 10:00, first valid packet at 10:01, packet delivered to the control team at 10:04. The detection-to-delivery interval is four minutes; the valid-packet-to-delivery interval is three. If the requirement starts at valid reception, comparing it with the four-minute interval would use the wrong boundary.

Choose the correct timing boundary

Suppose an invented service must deliver validated health data within two minutes of valid reception. The three-minute delivery in the example fails that requirement even though a signal was detected. Investigating the ground network or processing queue may be more relevant than changing the spacecraft transmitter.

A useful incident record keeps station time, packet identity, integrity results and delivery time together. Distinguish an estimate from an observed event and record missing evidence explicitly. This allows the next team to identify the failed stage without erasing the stages that worked.