Case A - Simple, uninterrupted downlink

Setup / assumptions

• 4 images, sent as 4 separate transfers (labeled Tx1-Tx4 - "Tx" = "transaction," CFDP's term for one file transfer). Splitting big images into several transfers instead is still open - Q8.
• CFDP's reliable mode ("Class 2 / Acknowledged") - confirmed with PAVI. The satellite gets confirmation each image arrived, and can resend missing pieces if needed.
• Sent one at a time, Tx1→Tx2→Tx3→Tx4 - deliberate, not just tidiness (why, below).
• PLDP doesn't process live. It records during the pass, and only decodes/checks afterward, once the pass ends ("LOS" = Loss Of Signal).

How these 4 images got decided for Pass 1 in the first place is now shown in the diagram below, at PPS's downlink-request step - PPS's mechanism, worked out later in this project (see the TC vs X-band concept, Q23): a request travels up as a custom command, and the satellite's payload app locally issues each Put.request from it. Still a light, unconfirmed working assumption, not locked - noted here since this is the first case where the gap actually shows up.

Phase 1 - Sending during Pass 1

The satellite sends all 4 images, one after another. Each image goes out as three messages in order: "here's what's coming" (Metadata), the image data itself (File Data), and "that's everything, here's the checksum" (EOF).

Nothing complicated here - no pausing, no resending. The smooth, ideal case.

Pass ends (LOS). Everything sent is sitting in PLDP's raw recording, but nothing's been decoded or checked yet.

Phase 2 - Ground-side processing, then Pass 2's S-band uplink

PLDP decodes the pass-1 recording, reassembles all 4 images, checks each checksum - all clean. PLDP does not wait for all 4 before acting: each image's confirmation is handed off to MCS the moment that image individually validates - Image 1 first, then 2, and so on, independent of how long Image 4 takes.

PLDP sends two confirmations per image: "got your EOF" (ACK(EOF)) and "complete and correct" (Finished(complete)). PLDP can't talk to the satellite directly, so these travel to MCS first, then ride up on Pass 2's S-band window - S-band and X-band are up together on every pass, so this doesn't need a separate dedicated contact.

Why dispatch immediately instead of batching everything?

Two separate layers were getting blurred together here - worth pulling apart:

1. PLDP's dispatch policy - hand each image's confirmation off the moment it validates. Never wait on a slower sibling.
2. MCS's transmission policy - when Pass 2's S-band window opens, MCS batches whatever's sitting in its queue at that moment into one frame (see below). This happens naturally, regardless of how PLDP dispatched - it isn't something PLDP has to orchestrate.

Result: Images 1-3, ready by the time Pass 2's window opens, go up together in one frame. Image 4, not ready yet, simply isn't in the queue at that moment - it rides whatever later window it's actually ready for. Nobody waits artificially, and nothing gets sent as a wasted lone transmission if something else happens to be ready alongside it. This gets full transmission-count efficiency (the same COP-1/CLCW round-trip argument that would apply if MCS runs something like YAMCS) with none of the downside of an artificial wait - and it matches how CFDP is already built to treat every transfer as independent.

Still open: whether MCS's actual per-transmission cost (COP-1 round trips, command queue gating, rate limits) is large enough to matter in practice - doesn't change this design, just how much it was worth reasoning through. Worth confirming with whoever operates MCS.

Phase 3 - Same Pass 2, the satellite confirms receipt

The satellite acknowledges each Finished message as it individually arrives and gets processed (ACK(Finished)), rather than waiting for all 4 - Image 1 can be fully closed while Image 4 is still processing. This travels back down via X-band, still within Pass 2, since X-band is co-active with the S-band uplink that just happened. No third pass needed.

Rendered from diagram/case_a_closure.puml (PlantUML)

Variant - what if the pass ends mid-way through the last image?

Suppose Pass 1 is barely too short for all 4 - Images 1-3 finish cleanly, but LOS hits mid-way through Image 4. The design above already handles this with no special case:

• Images 1-3: fully received, no problems → send their confirmations at the next chance, without waiting on Image 4.
• Image 4: incomplete, needs Pass 2 to finish, then goes through its own confirmation cycle separately.

This works because CFDP treats every transfer independently - 3 of 4 images can be wrapped up a whole pass earlier than the 4th.

The one thing worth remembering

Even in this best case, fully closing out all 4 transfers takes two passes (Pass 1 for the original send, Pass 2 for the complete uplink+downlink confirmation round trip). It's two, not three, specifically because S-band and X-band are up together on every pass: the confirmations ride Pass 2's S-band up, and the satellite's reply rides that same Pass 2's X-band down. But as noted above, the image itself is usable much sooner, right after Phase 2's checksum check. Don't confuse "not yet closed" with "not yet usable."

Open questions this case raised