Spacecraft TC/TM Link

Why the constraint shapes everything

Spacecraft do not have a debugger attached. Every interaction with a subsystem in flight is a command sent up and a telemetry frame that comes back, and the ground segment’s entire job is to decide, from those bytes alone, whether what just happened was acceptable.

That sets the rest. Frames are small and rigidly laid out, the failure modes have to be reachable on the ground, and every decision has to be recorded because you cannot go and look.

What I built

Two endpoints and the protocol between them.

The PDU simulator stands in for a satellite power distribution unit. It accepts load-control telecommands and answers with a status telemetry frame, including the case where overcurrent protection has tripped and the frame comes back reporting the load ON and its protection TRIPPED at the same time.

The ground client encodes commands, decodes the response, evaluates the reported state against safe operating limits (bus voltage at least 26.5 V, current between 1.8 and 2.2 A, OCP flag clear), and writes its verdict to a log.

Three scenarios run end to end: a nominal load enable, a fault where the telemetry contradicts itself and has to be caught on two independent checks, and a commanded shutdown that has to be positively confirmed rather than assumed.

The rule the client is built around

The socket code is the boring half. The design rule underneath it is that the client must never assume its command worked. A telecommand that is acknowledged is not a telecommand that was executed, and a system built on that assumption fails silently in the situation where you can least afford it.

So the client’s model of the spacecraft is only ever updated from returned telemetry, and never from what it just sent. The confirm-gates in my robotics work come from the same principle: the state of the world is whatever the sensor reports, not whatever you told it to be.

Where it fits in integration

This is EGSE, electrical ground support equipment: two tools built from the same protocol pointed in opposite directions.

During spacecraft assembly, integration and test, the flight hardware and the ground software are almost never ready at the same time. The subsystem simulator lets ground software be written and exercised months before a real power distribution unit exists. The ground client does the reverse: when the PDU arrives on the bench, it can be commanded and verified before anyone connects it to the real mission control stack. On a FlatSat, the integration bench where subsystems are laid out flat and wired over their real interfaces, both halves run at once.

The fault scenario is where the bench earns its keep. You cannot ask an expensive power unit to trip its overcurrent protection on demand just to check that the ground reacts correctly. A simulator can produce that frame on every run, which makes the failure path testable instead of hypothetical. The same applies to hardware-in-the-loop work on the power system itself, and to procedure rehearsal, where operators practise responding to a fault nobody wants to stage for real.

The CSV earns its place too. In a verification campaign the artifact you hand over is evidence that a decision was made, on what data, and at what time, which is what that file records.

The test campaign (Part 1)

Before the code, I planned the campaign that would verify regulated power to four payload channels, L1 to L4, with the PDU on the bus and payloads not yet integrated:

• Rig. A current-limited 28 V supply, four 14 Ω load simulators (28 V ÷ 2 A), an EGSE computer on TC/TM over TCP, and a solid-state relay on L2 behind a hardware key-switch interlock.
• Sequence. Six phases, each behind a gate: pre-test checks, power-on and housekeeping, each load enabled and disabled in turn, a deliberate short on L2, re-verification of every load, then power-down. If overcurrent protection does not trip, the bench powers off.
• Optimisation. Polling telemetry continuously and combining each load’s enable and disable cycle cut the estimate from about 35–48 minutes to about 27–32. Two faster options were rejected: testing loads in parallel hides which load caused an anomaly, and skipping re-verification after the fault ignores what the short may have done to the other channels.
• Feedback to the client’s systems engineering. Their brief left the overcurrent reset behaviour, the fault-injection method and the idle-current limit undefined. I raised each as an open item rather than guessing.

This was contract work, done through my company Habzeno for a satellite company that needed a bench to test its parts. The problem statement was theirs. The test plan, the protocol design, both implementations, the fault scenarios and the containerised harness are mine.