I once watched a $2.3M Ka-band terminal sit dark for six weeks. The commissioning crew couldn’t reproduce a 1.2 dB cross-pol degradation that only showed up during morning fog. The test procedure said: Verify cross-polarization isolation meets specification. It didn’t say how. Not at what elevation, not under what atmospheric conditions, not with what reference antenna. The field crew guessed. The hub engineer rejected the results. The integrator blamed the antenna manufacturer. The manufacturer blamed the installation. The customer blamed everyone.
The root cause wasn’t a faulty feedhorn or a misaligned panel. It was a document that assumed the reader already knew what the writer intended. In satellite ground station commissioning, that assumption gets expensive fast. A poorly written test procedure doesn’t just waste time—it creates failure modes no link budget can predict.
This article is for the engineer who has to write the procedure, execute it, or sign off on the report. It gives you a concrete framework for producing documentation that survives the gap between the design review and the muddy antenna pad.
Why Most Commissioning Documents Fail Before the First Measurement
Walk through any ground station acceptance test plan and you’ll find the same three defects:
- Implicit knowledge masquerading as instruction. “Perform a G/T measurement” isn’t a step. It’s a topic heading. A step tells you which noise source to use, where to connect it, what spectrum analyzer settings to apply, and what pass/fail threshold to record.
- Pass/fail criteria that float. “G/T shall be better than 20 dB/K” without stating the reference plane, the elevation angle, or the ambient temperature range isn’t a criterion. It’s a wish.
- No failure branching. The procedure describes the happy path. When the spectrum analyzer shows an unexpected spur at 19.7 GHz, the technician has no instruction. He calls the office. The office calls the design engineer. The design engineer is on a plane. The terminal sits dark.
These defects share a common origin: the author wrote the document for a reviewer who already understands the system, not for the technician who’ll hold the torque wrench at 02:00 in a rainstorm. The Google SRE book captures this principle in its chapter on effective troubleshooting: “If you can’t describe what you’re doing in a way that someone else can follow, you don’t understand it well enough yourself” (Google SRE). That applies to test procedures as much as to incident response.
The Anatomy of a Commissioning Report That Survives an Audit
A commissioning report isn’t a diary. It’s a legal and technical record that must answer three questions for any reader who picks it up six months later:
- What was tested, exactly?
- How was it tested, with enough detail that the measurement can be reproduced?
- Did it pass, and against what objective evidence?
Every report I write or review contains these sections, in this order:
1. System Under Test Identification
Not just “3.8m Ku-band terminal.” List the antenna model, serial number, feed assembly part number, LNB model and serial number, BUC model and serial number, modem type and firmware version, and the exact configuration file loaded. If a component is swapped during commissioning, the report must record the swap with a timestamp and a reason. I’ve seen a terminal fail its six-month re-validation because the original report listed an LNB that had been replaced during commissioning but the replacement was never documented. The auditor flagged it as an unverified configuration. The terminal was taken offline for three days while we reconstructed the paper trail.
2. Test Environment and Conditions
Record the ambient temperature, relative humidity, wind speed, and sky condition at the start and end of each test session. For G/T and cross-pol measurements, record the elevation and azimuth angles used, the satellite beacon frequency and polarization, and the clear-sky confirmation method. If you used a spectrum analyzer, record the model, serial number, calibration due date, and every relevant setting: RBW, VBW, sweep time, detector type, reference level, and input attenuation. A G/T measurement made with a 10 dB input attenuator and a 300 Hz RBW is not the same measurement as one made with 0 dB attenuation and a 1 kHz RBW. The report must make the difference obvious.
3. Step-by-Step Test Results
Each test step gets its own numbered entry. The entry states the step from the procedure, the measured value, the pass/fail threshold, and the pass/fail determination. If the step failed, the entry references the non-conformance report number. No narrative. No interpretation. Just the data. Interpretation lives in the next section. For example, a G/T measurement entry would read: “Step 4.2: G/T at 11.7 GHz, 45° elevation. Measured: 22.1 dB/K. Threshold: ≥ 21.5 dB/K. Result: PASS.” A cross-pol entry that failed would read: “Step 5.3: XPD at 11.7 GHz. Measured: 28.4 dB. Threshold: ≥ 30 dB. Result: FAIL. NCR #2024-03-002.” This format leaves no room for ambiguity when the report is reviewed months later by an engineer who wasn’t on site.
4. Non-Conformance and Deviation Log
Every deviation from the expected result gets a unique identifier, a description of the symptom, the immediate containment action taken, and a reference to the failure diagnosis report if one was generated. This log is the single most valuable section for the engineer who inherits the system three years later. It tells them what broke, when, and what was done about it.
5. Summary of Compliance
A single table that maps each contractual performance requirement to the test step that verified it, the measured value, and the margin. If a requirement was not verified, state why and reference the waiver or deferral. This table is what the procurement lead actually reads. Make it impossible to misinterpret.
This structure aligns with the auditable documentation principles found in frameworks like the NIST Cybersecurity Framework, which emphasizes repeatable, evidence-based processes for critical infrastructure (NIST). While NIST targets cybersecurity risk, the underlying requirement—that a process must be documented well enough that an independent assessor can verify it—applies directly to ground station commissioning.
Writing Test Steps That a Technician Can Execute at 02:00
The difference between a procedure that works and one that causes a call to the office is the level of assumed context. Here’s a real example from a Ku-band terminal acceptance test I reviewed:
Bad: “Measure cross-polarization isolation.”
Better: “Measure cross-polarization isolation on the receive path at 11.7 GHz using the satellite beacon.”
Field-ready:
- Configure the spectrum analyzer: center frequency 11.700 GHz, span 10 MHz, RBW 10 kHz, VBW 1 kHz, sweep time 500 ms, detector RMS, reference level -30 dBm, input attenuation 0 dB.
- Connect the spectrum analyzer to the LNB receive IF output port labeled “Rx-V” on the indoor unit patch panel.
- Command the antenna to the stored beacon track position for satellite [SAT_ID] at elevation [ELEV]°, azimuth [AZ]°.
- Confirm beacon carrier is visible on the spectrum analyzer at ≥ -50 dBm. If not visible, execute the beacon acquisition procedure in Appendix B before continuing.
- Record the carrier level in dBm as P_co.
- Switch the spectrum analyzer input to the “Rx-H” port.
- Record the carrier level in dBm as P_cross.
- Calculate cross-pol isolation: XPD = P_co – P_cross in dB.
- Pass if XPD ≥ 30 dB. Record the value. If XPD < 30 dB, stop the test and initiate Non-Conformance Report per Section 8.
This version removes every ambiguity. It specifies the instrument settings, the connection points, the prerequisite condition, the calculation, and the failure branch. A technician who has never seen this terminal before can execute it. That’s the standard.
When you write a step, ask: If I hand this to a competent technician who has never touched this system, will they produce a valid measurement without calling me? If the answer is no, add detail until it becomes yes.
Writing Failure Diagnosis Reports That Remote Support Teams Can Actually Use
A failure diagnosis report isn’t a test result. It’s a story. It must tell the remote support engineer what the system was doing, what went wrong, what the field technician observed, what was tried, and what the current state is. The narrative structure matters because the remote engineer can’t see the system. They’re building a mental model from your words.
I structure every failure report with this template:
- Trigger event. What was the system doing when the failure was first observed? “Terminal was tracking Eutelsat 10A at 10.95 GHz vertical beacon during routine G/T measurement. Ambient temperature 4°C, light rain.”
- Symptom description. What did the technician see, hear, or measure? Be specific. “Spectrum analyzer showed beacon carrier level fluctuating between -52 dBm and -48 dBm with a period of approximately 2 seconds. No fluctuation observed on the co-pol port.”
- Immediate actions taken. What did the technician do in response? “Swapped LNB H-pol output cable with known-good cable. No change. Powered down BUC and repeated measurement. Fluctuation persisted. Ruled out uplink interference.”
- Current state. Is the system operational, degraded, or down? “Terminal is receiving on V-pol only. H-pol path is unavailable. Cross-pol isolation cannot be verified.”
- Supporting data. Attach spectrum analyzer screenshots, trend logs, and photos. Annotate them. A screenshot of a spectrum analyzer without a caption explaining what the engineer should notice is noise.
This structure forces the field technician to separate observation from interpretation. “The LNB failed” is an interpretation. “The H-pol carrier level dropped 15 dB while the V-pol carrier remained stable” is an observation. The remote engineer needs observations. They’ll form their own interpretation.
For engineers who struggle with structuring long-form technical narratives—especially when a failure report must be written under time pressure after a 14-hour shift—tools like an AI script generator can help organize field notes into a coherent first draft, which the engineer then corrects and tightens. The value isn’t in replacing engineering judgment but in removing the friction of staring at a blank page when the facts are already known.
Common Documentation Failures and Their Field Consequences
Here are four documentation failures I’ve encountered repeatedly, and what they cost:
1. The missing reference plane. A G/T measurement report stated 22.3 dB/K. The contract required 21.0 dB/K. The terminal passed. Six months later, a different test team repeated the measurement and got 19.8 dB/K. The difference: the first team measured at the LNB output flange. The second team measured at the indoor unit input, after 40 meters of LMR-600 cable with 2.5 dB of loss at L-band. The original report didn’t state the reference plane. The terminal was non-compliant and had been operating with 2.5 dB less margin than the link budget assumed. The fix required replacing the cable run and re-validating the entire RF chain.
2. The unstated elevation angle. A Ka-band terminal was accepted at a 45° elevation angle with a G/T of 18.5 dB/K. The link budget assumed a 10° elevation look angle for the operational satellite. At 10°, the antenna noise temperature increased by 35 K due to ground spillover, dropping the G/T to 16.1 dB/K. The acceptance test didn’t record the elevation angle. The terminal couldn’t close the link at the operational look angle. The integrator had to install a larger antenna at their own cost.
3. The assumed clear sky. A cross-pol isolation measurement was recorded as 32 dB. The report said “clear sky.” The technician’s logbook, found later, noted “thin cirrus, sun visible.” Thin cirrus at Ka-band can introduce 0.5–1.5 dB of depolarization. The true clear-sky cross-pol isolation was closer to 30.5 dB, which was below the 31 dB specification. The terminal should have failed. It passed because the weather condition wasn’t objectively verified.
4. The missing failure branch. A modem acquisition test step said: “Verify modem locks within 30 seconds.” The modem didn’t lock. The procedure had no instruction for what to do next. The technician power-cycled the modem. It locked. He recorded a pass. The root cause was a PLL open up condition triggered by a frequency reference warm-up drift. The power cycle masked it. The terminal passed commissioning and failed on its first operational pass because the reference oscillator hadn’t been characterized. A proper failure branch would have directed the technician to measure the reference frequency before retrying.
A Practical Framework for Writing and Reviewing Procedures
Use this checklist when you write or review a ground station test procedure. Every “no” is a risk of field failure:
- Instrument settings: Does every measurement step specify the instrument model, connection point, and all relevant settings (center frequency, span, RBW, VBW, sweep time, detector, reference level, input attenuation)?
- Environmental conditions: Does the procedure require recording temperature, humidity, wind, and sky condition at the start and end of each test session?
- Pass/fail thresholds: Is every threshold expressed with a value, a unit, and the reference plane or condition to which it applies?
- Failure branches: For every step that can fail, does the procedure specify the immediate action (stop, retry, escalate, log) and the non-conformance reporting path?
- Prerequisites: Does each step state what must be true before it can be executed (e.g., “beacon carrier visible at ≥ -50 dBm”)?
- Traceability: Does the report map every contractual requirement to a specific test step and measured result?
- Configuration control: Does the report record the serial numbers, firmware versions, and configuration files of every active component?
If you’re reviewing a procedure written by someone else, apply this test: pick a step at random and ask the author to explain exactly what the technician will do, what they’ll see, and what they’ll record. If the author hesitates or says “they’ll know what to do,” the procedure isn’t ready.
Conclusion
Satellite ground station commissioning documentation isn’t bureaucratic overhead. It’s the difference between a terminal that works on day one and a terminal that fails silently until the first rain event exposes the margin you never had. Write your procedures for the technician who’ll execute them at 02:00 in bad weather. Write your reports for the engineer who’ll inherit the system three years later and needs to know exactly what was measured, how, and against what standard. Every missing detail is a future failure that someone will have to diagnose under pressure. The time to prevent that failure isn’t during the outage. It’s when you sit down to write the document.