5 Common Mistakes in Satellite Interference Screening

A first-pass frequency screening is a simple idea, but a handful of habits quietly undermine it. None of these are exotic mistakes — they're the ordinary ones that creep in when screening is treated as a checkbox instead of a real risk assessment.

1. Treating it as a one-time task

A screening pass done the week you file tells you nothing about a conflicting network published six months later. New filings appear continuously, and a network with no overlaps today can have several by next quarter. Screening once and filing the result away is the single most common way real conflicts go unnoticed until a coordination request lands unannounced.

2. Ignoring polarization

Two filings with full frequency overlap but opposite polarization carry meaningfully less practical interference risk than the raw overlap suggests. Skipping this field turns a manageable shortlist into a much longer, noisier one.

3. Not distinguishing notice types

An overlap with an early-stage API/A filing and an overlap with a formal CR/C carry very different levels of urgency — see our notification types reference. Treating every match the same way, regardless of stage, makes it hard to tell which ones need attention this week versus which are worth a note for later.

4. Skipping orbital geometry entirely

Frequency overlap is necessary but not sufficient. Two bands can overlap perfectly and still never practically interact if the orbital geometry — position for GSO, orbital parameters for NGSO — points them at completely different parts of the sky. A frequency-only screen is the right first triage, but treating it as the final word skips a step that often resolves a large share of apparent conflicts.

5. Assuming "already published" means "already checked"

An entry sitting in the BR IFIC history isn't automatically something a previous screening pass already caught — especially if that satellite's filing was added to your monitoring list after the overlapping entry was published. Newly added monitoring should always start from the target satellite's own publication date, not from whatever checkpoint an unrelated satellite happened to reach.