H2-1 · What a SATCOM terminal contains (system boundary & interfaces)

This chapter defines the SATCOM terminal boundary, the minimum interface set, and the state flow that decides when traffic is allowed. The goal is a practical “where to probe, what to read, and what the terminal is responsible for”.

1) Boundary: terminal vs antenna-side hardware vs network

A SATCOM terminal (IDU-class) owns the closed-loop controls and the “traffic release gate”. Antenna-side hardware provides RF amplification/conversion (LNB/LNA/BUC), while the network side provides IP transport. The terminal is responsible for coordinating acquisition/lock, maintaining stable operation across temperature and supply variation, and exporting enough telemetry to isolate faults quickly.

2) Internal blocks: name the block AND the observable outputs

For engineering use, each internal block should be described with the specific signals or counters it must expose. Without these “observables”, troubleshooting degenerates into guessing.

• RF front-end control (LNB/LNA/BUC): bias voltage/current, AGC/RSSI, LO/PLL lock flags, output power detector reading, VSWR/over-temp alarms.
• Frequency & reference: reference-stable indicator, synthesizer lock, lock-time, unlock reason codes, re-lock attempt counters.
• Modem ASIC: acquisition/sync state, BER/FER counters, FEC decoder stress indicators (e.g., iteration/erasure trends), buffer under/overrun counters.
• Encryption (terminal-side): enable/disable state, throughput utilization, error counters, audit-friendly event IDs (without exposing sensitive internals).
• Ethernet backhaul & management: link up/down, DHCP/DNS failures, queue/QoS drops, management-plane isolation status, remote health heartbeat.

3) External interfaces: a checklist that supports field isolation

External interfaces should be listed by interface class so they remain applicable across vendors and form factors. The checklist below is designed to enable isolation between RF issues, modem issues, and network issues.

4) Operational workflow: the “traffic release gate” must be explicit

A robust terminal behaves like a state machine. The critical engineering concept is the traffic release gate: user traffic is only enabled when RF lock, modem sync, crypto readiness, and backhaul readiness are all satisfied.

H2-2 · Link budget knobs you can actually control (G/T, EIRP, margin)

This chapter turns “link quality” into a small set of controllable knobs and observable metrics. It separates what the terminal can tune from what it can only detect and record.

1) Practical interpretation of G/T, EIRP, and margin

G/T summarizes how clean the received signal appears at the demodulator input (front-end noise and losses dominate). EIRP summarizes how effectively transmit power is delivered on-air (including back-off and protection limits). Margin captures how far the link is from the FEC threshold once modulation and coding are applied. The terminal should convert these into actionable observables rather than leaving them as abstract budget terms.

2) G/T knobs (receive path): it is more than noise figure

• Front-end noise & loss: any added loss before the first low-noise gain stage directly reduces recoverable SNR.
• Gain distribution: too little early gain raises the relative impact of downstream noise/quantization; too much early gain increases overload risk and AGC hunting.
• Temperature & cabling effects: temperature drift and loss variations often present as “AGC climbing over time” or “more frequent re-lock”.
• What to watch: RSSI trend, AGC step history, LNB bias current trend, LO lock dropouts, and lock acquisition time.

3) EIRP knobs (transmit path): usable linear power is the target

• PA bias + power loop: setpoint should be reached through a stable detector loop (avoid oscillation/hunting).
• OBO (output back-off): back-off trades raw power for better linearity (often improving EVM/ACPR and decoding stability).
• Protection limits: VSWR/over-temp/under-voltage events can force power rollback; logging “limit active” flags is essential.
• What to watch: power detector reading, “power limit active” flag, temperature, VSWR alarm count, and re-try counters.

4) Margin knobs: Eb/N0 behavior, FEC threshold, and stability over time

Margin is where RF, modem, and control policies meet. A terminal should record time series rather than single snapshots: BER/FER over windows, sync state transitions, and any rate/adaptation changes. A common failure pattern is “near-threshold operation” where small environmental changes cause repeated state churn.

• If RSSI drops with AGC pegged: receive path impairment is likely (loss/pointing/weather). The terminal can detect and timestamp the onset.
• If RSSI is stable but BER/FER rises: suspect non-linear transmit behavior, lock instability, or interference-like conditions; the terminal must correlate with power limit flags and lock history.
• If frequent re-lock happens: focus on reference/synth stability and the lock sequence; record lock times and failure codes.

5) “Controllable vs not controllable”: draw the responsibility line

6) Field quick checks (fast isolation without special gear)

• Check lock timeline: Reference stable → synthesizer lock → RF lock → modem sync. Any missing step points to the responsible block.
• Check “limit active” flags: power limit, VSWR, over-temp. These convert mystery throughput drops into explainable events.
• Check RSSI/AGC trend: slow climbs often indicate loss/temperature drift; sudden steps often indicate environment or configuration changes.
• Check BER/FER window history: spikes aligned with lock transitions suggest acquisition instability; spikes with stable lock suggest linearity/interference-like conditions.
• Check backhaul queue drops: link can be RF-healthy while traffic stalls due to queuing/QoS mis-prioritization.

H2-3 · LNB/LNA control: biasing, gain steps, LO lock and health reads

Practical terminal-side control means more than “power on”. A robust design defines bias ramp rules, AGC stability rules, and lock/telemetry that translate raw readings into actionable alarm codes.

1) Biasing: ramp, monitor, and protect (terminal internal)

Bias rails should be treated as controlled resources because they can destabilize the entire terminal if they surge or collapse. Use a soft-start ramp to avoid inrush dips, and continuously monitor both voltage and current to detect wiring faults, shorts, and thermal drift that degrades RF performance over time.

• Soft-start ramp: raise bias in steps or with a fixed slope; freeze other “release gates” until the rail settles.
• Dual monitoring: voltage confirms “rail present”, current confirms “load is sane”. Logging current trend is often the earliest fault indicator.
• Protection sequence: limit → foldback/disable → cooldown delay → retry with counter; expose a clear alarm code and retry count.

2) Gain steps & AGC: avoid hunting and false alarms

Gain-step AGC can create “instantaneous” level changes that look like faults to downstream detectors. A stable policy uses deadband and rate limiting, and applies a settling window after each step so protection logic does not react to transient artifacts.

• Deadband / hysteresis: require a meaningful delta before changing gain; prevents oscillation between adjacent steps.
• Step rate limit: cap how frequently steps can occur; limits noise-induced chatter and lock disturbances.
• Settling window: after a step, suppress overload/lock-fail decisions for a short window; only then evaluate health metrics.

3) LO/PLL lock: make lock status debuggable

A single lock flag is not enough. Lock behavior should be represented as a state machine with time-to-lock and reason codes. When a system shows “powered but not locked”, the fastest isolation is achieved by correlating RefStable, SynthLock, LO_Lock, and any overload indicators around the acquisition period.

• Time-to-lock: record how long each lock step took; spikes often point to reference instability or marginal loop settings.
• Unlock reason codes: ref lost, overload, temperature limit, bias dip, external alarm — keep codes short and consistent.
• Lock stability counters: “unlock events per hour” is more useful than a single snapshot.

4) Health reads → alarm codes: convert signals into actions

Telemetry should produce alarm codes that indicate the most likely subsystem, not just “fail”. Use a small set of categories and always attach a snapshot of key readings (RSSI, AGC step, bias current, temperature, lock flags) to each event record.

5) Field quick checks (fast isolation)

• Bias first: verify BiasOK (V in range + I settled) before interpreting RSSI or lock failures.
• Lock timeline: RefStable → SynthLock → LO_Lock. Missing the first step points to reference/power; missing later steps points to RF/loop margin.
• AGC history: rapid step toggling suggests hunting; step changes followed by lock drops suggest transient sensitivity.
• Correlate with temperature: lock instability that tracks temperature often indicates drift or derating triggers.
• Use event snapshots: any alarm should include RSSI, AGC step, V/I, Temp, and lock flags to avoid “no data” support loops.

H2-4 · BUC control: PA bias, power detector loop, OBO and protection

A stable uplink is achieved by controlling usable linear power, not chasing the maximum output number. The terminal should close a slow, well-behaved power loop, apply a practical back-off policy, and enforce protection sequencing.

1) PA bias & temperature compensation: predict drift and derate smoothly

Temperature changes shift PA gain and compression behavior, and they also shift detector sensitivity. A robust terminal uses temperature as a first-class input to maintain stability: apply a derate curve and compensate bias/gain so the system stays in a predictable linear region.

• Derate curve: reduce target power gradually above a thermal knee; avoid abrupt throughput collapse.
• Bias/comp tables: apply piecewise compensation that keeps the PA in a stable region across temperature.
• Telemetry correlation: always log temperature, target power, measured power, and “limit active” flags together.

2) Output power closed-loop control: detector → ADC window → controller → bias/atten

Most uplink instabilities come from a poorly tuned loop: detector noise, insufficient averaging, or a controller that reacts too fast. Power control should be slower than the thermal time constants and should use step ramps to avoid overshoot that triggers protection.

• Detector source: a coupled power detector is the primary measurement; treat it as a noisy sensor that needs windowed averaging.
• Controller behavior: prefer slow, monotonic convergence; avoid hunting around the setpoint.
• Actuators: attenuation is fast (good for quick limiting), bias is slower (good for steady operating point).

3) OBO and linearity: choose usable power, not headline power

Output back-off (OBO) is a practical lever that trades raw power for linearity. Too little back-off pushes the PA into compression, causing distortion that can degrade demodulation stability. Too much back-off reduces EIRP and erodes receive margin. The terminal should treat OBO as a policy tied to measured quality metrics and protection headroom.

• When BER/FER worsens with stable lock: prioritize checking linearity policy and “limit active” events before increasing power.
• When thermal rollback is frequent: increase OBO or lower the target setpoint to avoid repeated protection churn.
• Record OBO state: always log the current OBO mode/level alongside BER/FER windows and throughput.

4) Protection sequencing: limit first, trip last (VSWR, thermal, UV)

Protection should be a state machine that enforces priority and debounce windows. The most common failure mode in the field is “chattering”: brief events cause repeated limit/trip actions that destabilize the link. Debounce and hold times convert noisy events into stable decisions.

• VSWR: apply immediate limiting → derate if persistent → trip only if the condition remains beyond a verified window.
• Thermal: derate smoothly → trip on hard over-temp → require cooldown before retry.
• Under-voltage: freeze power increases → reduce setpoint → protect against brownout-induced oscillation.

5) Field quick checks (fast isolation)

• Compare target vs measured power: large persistent error suggests loop or actuator limitation; log “controller saturated” if available.
• Check “limit active” flags: VSWR/thermal/UV flags convert unexplained throughput drops into timestamped causes.
• Check temperature vs power: power collapse that tracks temperature indicates derate/rollback rather than random fading.
• Check retry counters: repeated trip-retry cycles indicate poor debounce/hold rules or intermittent sensors.
• Correlate with BER/FER windows: quality drops aligned with limit events usually point to EIRP/linearity, not receive sensitivity.

H2-5 · Frequency plan & reference: synthesizers, phase noise, and lock sequencing

A SATCOM terminal can “look locked” and still behave poorly if the frequency plan, reference quality, or lock sequencing allows images, spurs, or unstable intermediate states to leak into the receive or transmit chain.

1) Frequency planning: IF choice and “do-not-step-on” checks

Frequency planning is a pre-emptive debug tool. A clean plan reduces surprises such as unexpected self-interference, images folding into the band, or reference-related spurs landing inside the effective receive bandwidth. The simplest practical approach is to define an IF, then enumerate predictable mixing products and confirm none land in-band.

2) Synthesizers and phase noise: why “locked” is not always “clean”

Phase noise and spurs can degrade demodulation margin without triggering a hard unlock. The terminal should connect synthesizer quality to observable effects: increased decoder workload, higher frame error windows, or stability issues during acquisition. These symptoms become actionable when correlated with lock timestamps and setpoint changes.

3) Reference inside the terminal: TCXO vs OCXO boundary (lock & drift focus)

The reference clock impacts time-to-lock, lock stability, and effective phase-noise floor. A stronger reference option is justified when the system repeatedly re-acquires under temperature swing or when quality margins are tight and decoder workload rises even with stable RF lock. The selection boundary should be expressed in operational terms: lock stability and drift sensitivity.

• Lock stability: unstable reference behavior tends to lengthen lock time and increase unlock/re-lock events.
• Quality under margin: higher phase-noise floor can manifest as higher decoder iterations or worse error windows.
• Temperature drift: large drift during warm-up or environmental changes can shrink acquisition tolerance and trigger re-lock cycles.

4) Lock sequencing: enforce a traffic release gate

Lock sequencing should be treated as a state machine with explicit settle windows. The goal is to prevent intermediate, partially-locked states from being mistaken as “ready”, which often produces unstable behavior after traffic begins. A clean sequence uses a release gate: traffic is enabled only after the full chain is stable.

H2-6 · Modem ASIC chain: framing, FEC, rate adaptation and diagnostics

Users searching for “SATCOM modem ASIC / LDPC / ACM” typically want actionable anchors: where performance is determined, which knobs exist in silicon, and which diagnostics quickly prove whether instability is RF margin, decoding pressure, or sync.

1) Data path: from Ethernet to IF (and back) with measurable checkpoints

The most useful mental model is a pipeline with checkpoints. Each stage should expose a short set of counters that survive real-world noise: windowed error rates, loss counters, and buffer levels. These are the signals that convert “it’s slow today” into a reproducible diagnosis.

2) FEC in practice: decoder workload is the early warning

FEC is best treated as a workload engine rather than an algorithm lesson. Near the decoding threshold, the system often shows a characteristic signature: iteration counts rise, latency can increase, and frame error windows widen. Those are measurable outputs that remain meaningful even when a hard unlock never occurs.

• IterationAvg / IterationMax: rising iterations indicate shrinking margin or increased impairment, even with stable lock.
• FER window: windowed frame errors are more actionable than single-point estimates.
• DecoderFail count: repeated decoder failures usually precede rate fallback or reacquire events.

3) ACM/VCM: switching rules that prevent oscillation and “rate thrash”

Rate adaptation is a control system. If it reacts too quickly, it can thrash between modes and degrade user experience with repeated bursts of loss or re-sync. A stable policy uses hysteresis, minimum dwell time, and a hold-off window after any reacquire.

4) Diagnostics: build a readable “modem health panel”

A high-value terminal exposes a compact diagnostic panel: sync state, BER/FER windows, decoder iteration statistics, frame loss counters, buffer levels, and current ACM mode with dwell time. When these metrics are time-aligned with lock events, support and field troubleshooting become deterministic instead of speculative.