When a satellite link degrades, teams often lose time because symptoms overlap: a weak carrier can be caused by antenna pointing, RF chain loss, modem configuration, interference, or upstream network issues. A good troubleshooting playbook uses decision trees—simple, repeatable checks that narrow the fault domain quickly and reduce guesswork. This guide lays out practical decision trees for the four most common layers: antenna, RF, modem/baseband, and network.
Table of contents
- How to Use These Decision Trees
- Start Here: Symptoms and Fast Triage
- Decision Tree: Antenna and Pointing
- Decision Tree: RF Chain and Interference
- Decision Tree: Modem/Baseband and Configuration
- Decision Tree: Network and Routing
- Cross-Layer Failures and What to Check Next
- What to Log During an Incident
- Common Operator Mistakes
- Troubleshooting FAQ
- Glossary
How to Use These Decision Trees
The goal is to isolate the problem domain before you try to “fix” anything. Start with symptoms, run the shortest checks first, and only change one thing at a time. If you have historical baselines (normal C/N0, normal receive power, normal BER), compare against them immediately—baseline drift is often the fastest clue.
These trees assume you can observe at least: receive power or AGC, C/N0 (or SNR), lock status, BER/PER, transmit power, and basic network health. If you can’t, start by restoring visibility (telemetry, monitoring, remote access, or local console) before deeper troubleshooting.
Start Here: Symptoms and Fast Triage
Use this quick triage to choose the right tree:
No lock / lost lock: start with Antenna then RF.
Lock but low throughput: start with Modem then Network.
Intermittent drops: check RF/Interference and weather before making configuration changes.
Good RF, bad user experience: go straight to Network.
Before anything else, confirm whether the issue is local (one site/terminal) or systemic (multiple sites, a whole beam, or a shared upstream dependency). If multiple sites show the same symptom at the same time, prioritize network control plane, hub/gateway, or space segment checks.
Decision Tree: Antenna and Pointing
Use this when you see loss of lock, weak receive signal, or high variation during tracking.
Step 1: Confirm the antenna is tracking the correct target
Check: satellite/beam selection, polarization setting, and current ephemeris/TLE (for LEO). Confirm the schedule is correct for the current time window.
Step 2: Verify pointing and tracking health
Check: azimuth/elevation readbacks, tracking mode (program track vs step track), and whether the antenna is hitting limits or oscillating. If you have a beacon, confirm beacon lock and beacon SNR.
Step 3: Inspect mechanical and environmental factors
Check: wind conditions, ice/snow accumulation, obstructions (new construction, parked vehicles, cranes), radome condition, and cable strain. Mechanical issues often show up as repeatable errors at certain azimuths or elevation angles.
Step 4: Quick isolation test
If possible, run a known-good reference: switch to a known-good satellite/beacon, or compare to a second antenna/terminal on site. If the antenna can’t achieve expected signal on any known target, keep focus on mechanical/pointing sensors and mount control.
Decision Tree: RF Chain and Interference
Use this when receive power is low, C/N0 is depressed, noise floor is elevated, or performance varies with transmit activity nearby.
Step 1: Check the receive chain from feed to modem
Check: waveguide/coax integrity, connectors, water ingress, corrosion, loose fittings, and any recent maintenance changes. Verify LNA power and status (and that it’s installed at the correct point in the chain).
Step 2: Validate frequency plan and conversion stages
Check: LNB/BDC/BUC LO settings, downconverter configuration, and correct IF at the modem input. A wrong LO or swapped bandpass filter can look like “no signal” even when the antenna is pointed correctly.
Step 3: Look for interference and noise
Check: spectrum view at RF/IF, expected carrier shape, adjacent carriers, spurs, and unexpected wideband noise rises. If available, compare current noise floor to baseline.
Step 4: Transmit chain sanity checks
Check: HPA/SSPA alarms, output power vs commanded power, backoff settings, and interlocks. Verify you are not driving the amplifier into compression (which can increase errors even when power looks “high”).
Step 5: Isolation actions
Temporarily remove variables: disable transmit (if safe and allowed) to see if receive recovers, swap to spare LNB/LNA, bypass suspect filters, or move to a known-good modem input path. If the symptom changes with a swap, you have localized the fault.
Decision Tree: Modem/Baseband and Configuration
Use this when the carrier is present and stable but throughput is low, BER is high, or the link won’t pass traffic even with lock.
Step 1: Confirm lock state and what kind of lock
Check: carrier lock, symbol lock, frame lock, and network/ACM state. “Lock” can be partial; you want stable frame lock with acceptable error rates.
Step 2: Validate modulation/coding and framing
Check: modulation order, FEC rate, roll-off, pilots, framing mode, and scrambling. A single mismatched parameter can cause high errors that look like “RF problems.”
Step 3: Check timing, frequency, and Doppler compensation
Check: reference clock status, frequency offset, and Doppler settings (critical for LEO). An unstable reference can cause intermittent slips that look like random outages.
Step 4: Inspect buffering and QoS configuration
Check: shaping, QoS policies, encapsulation overhead, and MTU/MSS clamping. Mis-sized MTU can create “mystery” throughput collapses due to fragmentation or PMTUD issues.
Step 5: Test with known patterns
Run: loopback tests (if supported), BER tests, or test carriers. If a test mode performs well but production traffic does not, suspect encapsulation, QoS, or network path issues rather than RF.
Decision Tree: Network and Routing
Use this when RF and modem metrics look normal but applications fail, latency is unstable, or throughput is inconsistent end-to-end.
Step 1: Confirm local LAN health
Check: interface errors/drops, duplex mismatches, VLAN tagging, link speed, and CPU/memory on routers/firewalls. Many “satcom problems” are actually local switch or firewall issues.
Step 2: Validate addressing and routing
Check: default route, BGP/OSPF adjacency (if used), NAT rules, and policy routes. Confirm nothing changed recently (maintenance windows, config pushes, key rotations).
Step 3: Measure the path and locate the break
Use: ping and traceroute equivalents, packet captures at both ends (if possible), and application-layer checks. If loss appears only beyond the modem/hub boundary, escalate to upstream provider or gateway operations with evidence.
Step 4: Check DNS, time, and certificates
Check: NTP sync, DNS resolvers, and certificate validity. Time drift is a common cause of “everything broke” symptoms for VPNs and TLS services.
Step 5: Confirm service policies
Check: rate limits, fair-use policies, shaping thresholds, and whether traffic is being deprioritized by class. If RF is clean but performance drops during congestion windows, it may be policy-driven.
Cross-Layer Failures and What to Check Next
Some failures present across layers:
Weather-driven fades: RF metrics dip, modem steps down ACM, throughput drops—this is expected behavior if designed correctly.
Interference events: noise floor rises, C/N0 drops, errors spike, lock may flap—often time-of-day correlated.
Bad power or grounding: “random” errors, modem reboots, LNA failures, unusual spurs—check UPS/generator transfer events and grounding integrity.
Configuration drift: worked yesterday, fails today with “normal RF”—compare configs, firmware, and known-good templates.
What to Log During an Incident
A good incident record makes escalations faster and repeat issues easier to prevent. Capture:
Time window: start/end times, and whether it matches a pass window (LEO) or is continuous (GEO).
RF metrics: receive power/AGC, C/N0 or SNR, BER/PER, spectrum screenshots (RF/IF), transmit power and backoff.
Antenna state: az/el, mode, alarms, beacon lock status, wind/ice conditions.
Modem state: modulation/coding, ACM mode, lock states, frequency offset, reference clock status.
Network evidence: interface counters, traceroutes, packet captures, DNS/NTP status, routing events.
Common Operator Mistakes
Changing multiple variables at once: makes root cause impossible to prove.
Skipping the spectrum view: interference and wrong-frequency issues hide in plain sight.
Assuming “lock” means “healthy”:strong> you can have lock with unusable error rates or wrong framing.
Ignoring baselines: without “normal,” every metric looks ambiguous.
Not documenting swaps: hardware swaps are powerful—only if tracked and correlated to symptom change.
Troubleshooting FAQ
What should I check first: antenna, RF, modem, or network?
Start with the symptom. If there’s no lock or signal is weak, begin with antenna and RF. If lock is stable but traffic is bad, start with modem configuration and then network path validation.
How do I tell interference from pointing error?
Pointing errors often change smoothly with az/el or during tracking and may affect beacon and carrier similarly. Interference often shows as a raised noise floor, sudden changes, or unexpected carriers/spurs in a spectrum view.
When should I escalate to the satellite operator or service provider?
Escalate when you can show the issue is not local: stable local RF and modem metrics but persistent upstream loss, or multiple sites showing the same symptom. Provide timestamps, metrics, and spectrum evidence to speed resolution.
Why does throughput drop even when RF looks fine?
Often due to modem settings (ACM thresholds, encapsulation overhead, MTU) or network constraints (shaping, congestion, routing changes). That’s why a layered decision tree is useful.
Glossary
RF chain: The path of radio-frequency components from antenna feed through amplification, filtering, and frequency conversion to the modem.
IF: Intermediate frequency—converted signal range used between RF hardware and the modem/baseband.
Modem/Baseband: Equipment that demodulates, decodes, and frames satellite signals into usable data.
C/N0: Carrier-to-noise density ratio, commonly used to assess link quality.
BER/PER: Bit error rate / packet error rate—measures of data corruption.
ACM: Adaptive coding and modulation—adjusts link parameters to maintain service under changing conditions.
LNA/LNB: Low-noise amplifier / low-noise block—front-end receive components near the antenna feed.
BUC: Block upconverter—transmit chain component that converts IF up to RF for uplink.
HPA/SSPA: High-power amplifier / solid-state power amplifier—boosts uplink transmit power.
MTU/MSS: Maximum transmission unit / maximum segment size—packet sizing parameters that affect throughput.
More
