Research and Calculation Methodology | SATCOM Index

This methodology describes how SATCOM Index turns a technical question into a sourced article, worked calculation, comparison, or decision framework. It is intended to make our evidence and limitations inspectable; it is not a substitute for a site-specific engineering process.

1. Define the question and reference plane

Before researching, we state what the page is trying to answer and define terms that can change the result. Depending on the topic, this includes direction, frequency, bandwidth, orbit, geometry, reference plane, path, availability target, equipment mode, measurement interval, geography, date, and user scenario.

Ambiguous labels such as latency, frequency, capacity, availability, mesh, or standard LO are split into measurable definitions before a number is assigned.

2. Find the narrowest applicable source

We search for the source that has authority over the claim:

• standards and recommendations for definitions, protocols, and prediction methods;
• regulators and administrations for legal or spectrum requirements;
• operators for their current network or service specifications;
• manufacturers for a named product, part number, mode, and datasheet revision;
• agencies and project owners for mission or architecture facts; and
• peer-reviewed or institutional research for analysis not covered by primary operational documents.

Search-result snippets and AI-generated summaries are discovery aids, not final evidence. We open the underlying document and check the relevant text.

3. Record claim-level evidence

For each material claim, the review record uses this structure:

A generic link to a standards body or manufacturer homepage is insufficient for a narrow technical claim when a direct document exists.

4. Reproduce calculations

A published worked example should provide enough information for an independent reader to reproduce it:

1. list all inputs with units;
2. define reference planes and sign conventions;
3. identify the formula or prediction method;
4. show intermediate values that materially affect the result;
5. state constants and rounding;
6. identify losses, delays, margins, or implementation terms not included;
7. perform an independent recomputation or reverse check; and
8. separate the model output from measured or guaranteed performance.

We do not present an illustrative input as a recommended default. A 12 GHz example does not define every Ku-band link; a named LNB's LO does not define every product in that band; and a propagation floor does not equal application latency.

5. Handle current and product-specific information

Operator fleets, service plans, product specifications, standards revisions, regulations, and corporate relationships can change. For these claims we use an official source checked close to the update date and include the access date.

Product data is scoped to the complete product or part number and stated mode. If a document is archived, superseded, region-specific, or silent on a feature, the page should say so rather than infer universal support.

6. Separate evidence from inference

When we combine sources or calculate a new comparison, we label the result as analysis. We state assumptions and avoid implying that the source itself reached our conclusion.

Screening metrics, such as weighted satellite hops or a simplified clear-sky budget, identify where deeper engineering is needed. They do not replace a carrier plan, operator coordination, regulatory check, acceptance test, or contractual SLA.

7. Review uncertainty and precision

Before publication, we challenge:

• precise ranges without a named source and test condition;
• statements using always, never, all, standard, or typical;
• averages that hide geography, time, loading, or percentile;
• dB quantities combined with arithmetic that requires linear ratios;
• delay values that mix space-leg, satellite-hop, one-way, and RTT definitions;
• RF and IF values without a reference plane;
• availability percentages without an exceedance method or outage definition; and
• product examples generalized into an industry rule.

Precision is reduced when the evidence does not justify it.

8. Translation handling

Translated pages are separate editorial artifacts. A technically reviewed English page does not automatically make a translation reviewed. Formula, unit, link, product, and date changes must be propagated and rechecked. A language version may remain non-indexable until its content and terminology receive appropriate review.

9. Release and update record

The release check covers title/H1 alignment, source links, internal links, calculation recomputation, dates, change summary, byline, reviewer attribution, crawlability, canonical URL, language alternates, sitemap state, and final rendered output.

Material revisions should record what changed. A named reviewer attribution is carried forward only when the changed scope remains covered; otherwise re-review is required.

Limitations

SATCOM Index content is educational. Actual designs depend on operator assignments, current equipment data, local regulation, site conditions, interference environment, safety rules, and contractual requirements. Obtain appropriate professional and operator approval before applying a calculation to a live network or transmission.

See the Editorial Policy, Technical Review Policy, and Corrections Policy, or contact us with evidence about a specific claim.