What happens if we block the Starlink satellite signal so that the terminal cannot receive any satellite signal? Will it continue scanning the 8 channels in sequence?

Experiments show that the answer is yes.

Continuous RF measurements for 1.5 hours clearly show that, when the satellite signal is blocked, the terminal continues searching across the 8 downlink channels, switching channels strictly every ~8.26 seconds. This behavior remains clearly visible until the terminal reboots after ~1834 seconds.

After rebooting, we clearly observe again the 8 uplink channels being transmitted sequentially, as seen in the previous article. This is likely related to RF calibration. After that, the terminal stops transmitting on the uplink and only continues scanning the 8 downlink channels in sequence. It then reboots again after another 1834 seconds.

This is consistent with our previous analysis and also with the design principles of most cellular communication networks: a terminal should not transmit blindly before acquiring system broadcast information.

Because the reboot interval is highly consistent, it is likely a fixed long-timeout mechanism in the terminal firmware that triggers when no Starlink satellite can be found for an extended period.

During the ~8.26 second dwell time on each channel, how many directions in the sky does the phased array scan on the same channel? This requires further investigation.

Below is a waterfall plot taken near the end of the 1.5-hour measurement (5400 seconds). The sequential switching across all 8 downlink frequencies remains unchanged and clear.

First, a brief explanation of how a receiver can be detected even when no signal is actively transmitted:

To receive a communication signal at a specific carrier frequency, a receiver internally generates a local oscillator (LO) signal at the target Rx frequency (let’s consider zero-IF here). This LO signal is mixed with the signal received by the antenna, converting it to baseband for digital signal processing, demodulation, decoding, and other operations.

Because RF signals can easily leak through electronic circuits, the LO signal can travel backward from the receiver circuitry to the antenna and radiate into the air.

A radio monitoring system can detect this leaked LO signal from a distance, revealing the presence and potentially the location of the receiver. Some radios periodically turn their receivers on and off, for example in TDD or TDMA systems. By monitoring when the LO signal appears and disappears, it is possible to obtain information about the communication scheme and its frame structure.

End of the introduction.

I again used the high-speed AD9361 frequency-scanning system developed in my previous article: “Measure Starlink Channel Switching: 10,000-Hop/s Fast-Frequency Measurements by AD9361”.

This time, I configured it to scan the frequencies of the eight Starlink downlink channels, allowing me to observe whether the terminal produces LO leakage or other radiation on these downlink frequencies during cold start.

The measurement revealed some interesting Rx behavior.

At around 24 seconds after cold start (“Tx scan” in the above figure), we see our familiar behavior from the previous article: the 8-channel uplink scanning operation. (post: “Starlink Terminal Cold-Start RF Emission Behavior Fingerprinting”)

After that, the receive-chain LO appears to turn on continuously while scanning the downlink channels in the following order:

Channel 3 → 4 → 5 → 7 → 6 → 8 → 1 → 2 → 3 → 4 → …

This continues until the first communication event with a satellite: initial_network_entry in the gRPC logs.

After this event, the continuous Rx LO scanning appears to be interrupted from time to time by communication activity, although the scanning pattern can still be observed (almost).

Why do I believe that the signal clusters at around 24 seconds are the 8-channel uplink scanning operation?

When zoomed in, their timing characteristics are exactly the same as those observed in the previous article (post: “Starlink Terminal Cold-Start RF Emission Behavior Fingerprinting”): each channel scan contains five signal clusters.

There is also a new observation compared with the previous experiment on uplink: a clear “warm-up” signal appears before the uplink 8-channel scan begins.

But wait, why can we observe uplink transmission on the downlink receive frequencies?

Possible explanations include:

• Because my receiver is very close to the terminal, we may be capturing out-of-band radiation from the transmitter.
• The RF front end (LNB) and AD9361 may not provide sufficient out-of-band rejection.
• Other mixing or frequency-aliasing effects may also be involved.

The Starlink terminal operates in TDD mode (though the system is FDD and has different uplink downlink frequencies), so even if some uplink transmission leaks into the downlink receive path, this does not necessarily cause a problem because transmission and reception do not occur simultaneously.

Then at around 31 seconds, starting from receive channel 3, we begin to observe continuous Rx LO activity sequentially on each receive channel.

My current hypothesis, with 89.3% confidence, is that the receiver is performing a blind scan of the downlink frequencies to acquire network broadcast information? This may be similar to how an LTE receiver scans for and acquires broadcast information, such as the PBCH.

In my captures, each channel remains active for approximately 8.254 seconds, then switches seamlessly to the next channel.

Here is another measurement from a different cold start. The conclusion remains unchanged.

After repeated measurements, the same behavior was consistently observed.

In the previous article (“Starlink Terminal Cold-Start RF Emission Behavior Fingerprinting”), I observed that after a cold start, the Starlink terminal begins a continuous scan across the eight uplink frequencies at a fixed time.

This is most likely an Tx RF and phased-array calibration procedure.

For example, the terminal may calibrate transmit power to ensure that the output power and EIRP remain within local regulatory limits.

I suspect that the Starlink terminal also contains monitoring and calibration Rx channel for its Tx chains, similar to designs used in smartphones and other RF chips (such as Analog Devices Inc.).

In addition, CFR (Crest Factor Reduction) and DPD (Digital Predistortion) are important for OFDM transmitters and also require feedback and monitoring Rx paths.

In general, it seems unlikely that the terminal’s uplink-frequency transmission is directly used to calibrate the receive chain because the receive chain operates at downlink frequencies.

Furthermore, some receiver calibration algorithms based on statistical and higher-order statistical properties can be performed using only the thermal noise already present in the circuitry and antenna.

So here is the interesting question:

Could the out-of-band radiation and spurious emissions from the terminal’s uplink transmission—or even intentional leakage—be used to calibrate the receive chain?

This fixed-time transmission pattern is highly likely to be an RF and phased-array self-calibration procedure.

After some additional (random) time, likely depends on the currently visible satellites, the terminal begins uplink transmissions for initial network entry and control-plane connection.

Another interesting discovery/guess: The Starlink terminal firmware OS loading (Linux?) costs about 6s.

The detailed information

I continue to use the AD9361 high-speed frequency-hopping measurement system developed in my previous article, to study the RF behavior of the Starlink terminal during cold start.

Measurement Method

I pressed Enter on my 8-channel RF capture program at the same time as I powered on the Starlink terminal. After five minutes of RSSI (all 8 UL channels) and gRPC logging, I examined the RF channel occupancy timeline and compared it with the startup timeline reported by gRPC.

I performed eight cold-start measurements, and all eight showed the same behavior.

Here is one example.

Time-frequency waterfall

Raw time-domain RSSI

It is very clear that the terminal begins the channel-scanning (ch1~8) transmissions at around 24 seconds after power-on, and ends the channel-scanning transmission at around 29 seconds.

Zoomed-in time-domain view:

In the Ku band (8*62.5MHz), channel 1 to 8 are transmitted sequentially. Five clusters are transmitted sequentially on each channel.

Zooming in further to channel 1 shows the five clusters:

Zooming in on the first cluster reveals several even shorter bursts inside it:

My AD9361 fast-hopping measurement system has a time resolution of 800 μs, because it completes one scan of all eight channels every 800 μs. Therefore, the exact burst shapes and intervals are not very clear.

But this is not a problem. Once we know the channel transmission pattern during cold start, we can return to my original 60 Msps single-channel capture system and analyze the detailed structure of each cluster on an individual channel.

Detailed Timing

• The complete 8-channel scan takes 4.7 seconds.
• Transmission on each channel: 0.49 s
• Channel switching time: 0.1134 s
• Duration of each of the five clusters on a channel: 0.046 s
• Interval between clusters: 0.06 s

Why Is This 8-Channel Scan Probably Not Actual Satellite Communication?

• The timing is fixed relative to power-on

The 8-channel scanning transmission always appears at approximately the same time after power-on.

If this were actual communication with a satellite, the timing should be random/variable. In a typical communication system, before transmitting to a base station or satellite, the terminal should first obtain downlink synchronization and some knowledge of the available time-frequency grids. Its transmission should then occur within specific time-frequency resources pre-defined/allocated by the network.

If the terminal always transmitted at a fixed time after power-on, while power-on itself occurs at a random time, the resulting transmission would occur at essentially random times relative to the network. This would create unnecessary interference.

A fixed-time RF operation after power-on therefore looks much more like an inherent hardware/firmware procedure than actual satellite communication.

• The phased-array antenna requires self-calibration

The Starlink phased-array antenna contains thousands of RF paths that need to be calibrated. Because: The temperature may be different every time the terminal starts. Hardware aging may also change the RF characteristics, and the terminal may even have experienced mechanical shock.

Teardown reports of Starlink phased-array antennas have described a hardware-based near-field self-transmit/self-receive calibration mechanism using air coupling.

The 8-channel scanning signal, together with the multiple clusters within each channel, looks very much like the RF paths of the phased array being calibrated step by step using different frequency and phase settings.

• The signal power appears lower

The power of the 8-channel scanning signal appears to be lower than that of the actual satellite communication signals that follow.

This is also consistent with a near-field self-calibration mechanism between antenna elements. Because the coupling distance is very short, the transmit power does not need to be high and may need to remain low to avoid receiver saturation.

That’s WHY I believe the 8 channel scanning emission is for self-calibration instead of actual satellite communication.

Identifying the Actual Initial Network Entry

I also measured the time at which a large amount of transmission first appeared after the 8-channel scan.

Unlike the 8-channel scan, this time varies from one cold start to another. This strongly suggests that these transmissions are actual satellite communication signals synchronized to the network’s time-frequency resources rather than to the terminal’s power-on time.

After comparing the gRPC startup records from all eight cold starts, I found that these moments of heavy transmission correspond closely to the initial_network_entry state.

I therefore suspect that they are part of the initial network entry procedure.

For example, the following gRPC status corresponds to the RF capture shown above:

"initialization_duration_seconds": {
    "attitude_initialization": 70,
    "burst_detected": 23,
    "ekf_converged": 143,
    "first_cplane": 27,
    "first_pop_ping": 41,
    "gps_valid": 15,
    "initial_network_entry": 25,
    "network_schedule": 29,
    "rf_ready": 23,
    "stable_connection": 0
}

An interesting detail is that the measured 8-channel scan ends at approximately 29 seconds after power on, while gRPC consistently reports rf_ready at 23 seconds across many many gRPC logs from many many cold starts.

This 6-second difference may correspond to the startup time of Starlink’s internal firmware/operating system (Linux?).

Therefore, the initial_network_entry time reported by gRPC as 25 seconds should be shifted by roughly 6 seconds, giving approximately 31 seconds after power-on.

Using this time-offset compensation, I compared the RF channel measurements with the gRPC records from all eight cold starts.

The results strongly support the conclusion that the moment of heavy RF transmission following the 8-channel scan corresponds to the initial_network_entry stage.

The main findings

Satellite switching and channel switching are synchronized in most cases. The terminal usually switches both every 15 seconds. 15s! I have to say: “ONLY STARLINK CAN DO!” with such a high satellite density. But it does happen:

• Sometimes the satellite switches but the channel does not.
• Sometimes the channel switches but the satellite does not.

Measurement method

The satellite to which the terminal is connected, and when it switches satellites, can be estimated using the open-source GitHub project LEOViz.

Note that LEOViz does not directly get the connected satellite from Starlink system signaling or official terminal state informaion. It estimates it using information obtained through gRPC together with satellite ephemeris data, so the result is not guaranteed to be absolutely true (But I believe it is almost true).

The authors of LEOViz mentioned in their paper that the Starlink network updates its configuration every 15 seconds. My independent RF channel measurements also confirm this observation, as shown by the detailed data below.

Of course, the reliability of my RF measurement method has not yet been fully validated. I already have some ideas for further verification and improvement. My current estimate is that its reliability is probably above 93.6%. :)

I used chronyc to synchronize both the RF channel measurement system and LEOViz to NTP server on internet. I then continuously measured the terminal for 30 minutes and compared the RF measurements with the LEOViz results. The LEOViz records use UTC, while my RF measurement records use local time (currently UTC+2).

Satellite switching statistics

According to the log of LEOViz, during the 30-minute observation period:

• Maximum satellite switching interval: 75 s
• Minimum: 15 s
• Mean: 22 s
• Median: 15 s

The distribution clearly shows that most switching intervals are 15 seconds, with a small number occurring at integer multiples of 15 seconds.

RF channel switching statistics

According to my AD9361 fast hopping based RF measurements:

• Maximum channel switching interval: 75.6127 s
• Minimum: 0.168215 s
• Mean: 19.1157 s
• Median: 15.0495 s

The distribution also shows a clear pattern around 15 seconds and its integer multiples. Note that my RF measurement is independent. In other words, even from pure RF channel measurements, we can still observe the same fundamental 15-second periodicity as reported by the author of LEOViz.

However, there are indeed some switching intervals shorter than 15 seconds. This means that the channel can switch without the satellite switching.

The timing jitter (offset from the 15s and its integer multiples) visible in the distribution plot may be caused by measurement errors, or it may be real behavior. Further verification is needed.

The following figure shows the RF channel-switching waterfall plot.

The satellite connection data estimated by LEOViz is stored in a CSV file:

2026-08-18 19:37:55+00:00,STARLINK-34039,975.1731036954168
2026-08-18 19:37:56+00:00,STARLINK-34039,973.8658621168312
2026-08-18 19:37:57+00:00,STARLINK-35776,532.9811019171716
2026-08-18 19:37:58+00:00,STARLINK-35776,529.7964872658133

Each line contains: UTC time, Satellite ID, Satellite distance

Plotting the LEOViz log and the measured RF channel switching in the same UTC time basis on the same figure:

Red vertical lines indicate satellite switching events along with time (X axis). Blue traces show the uplink channel (Y axis) switching over time (X axis).

Many red lines are separated by exactly 15 seconds, and many blue channel transitions occur at the same times as the red lines. This is why I say most of the time satellite switching and RF channel switching happen together.

Satellite switches without channel switching

At around 575 s, the satellite switches and the channel changes from 3 to 7. Then 30 s later the satellite switches, but the channel remains unchanged. 45 s later the satellite switches again, but the channel still remains unchanged. 60 s later the satellite switches for the third time, and the channel changes from 7 to 5.

The original RF RSSI measurements also confirm this behavior.

In the figure, the short black vertical lines below −85 dBm indicate channel-switching events. The region above −85 dBm shows the measured RSSI of the individual channels.

Channel switches without satellite switching

After a satellite switch at around 890 s, the channel switches at 905 s and 920 s, while the satellite remains unchanged. At 935 s, the satellite finally switches again, accompanied by another channel switch.

The corresponding raw RSSI measurements are shown below.

The following figure shows obvious channel switching cases faster than 15s: around 1710s and 1740s.

These channels may be dynamically assigned among different satellites, among different beams on the same satellite, and even among multiple terminals within the same beam.

How exactly are these channels dynamically allocated? Is there some pre-planned frequency allocation between satellites and beams, or are the channels dynamically assigned in real time according to channel conditions and traffic load?

To answer these questions, we need to combine satellite ephemeris data, beam ground-track information, and real-time monitoring of the uplink and downlink channels used by the terminal.

My previous series of reverse-engineering experiments, combined with Starlink’s basic OFDM patents, have largely revealed the physical-layer parameters, including the signal format, modulation/demodulation, and subcarrier allocation, etc..

In my previous article, Starlink Terminal Codename “Panda”: Capture IQ Signals? The Complete Satellite Access Procedure Begins to Emerge!, I tried to obtain real-time channel information through the Starlink terminal’s gRPC interface, but this approach does not seem very practical. It may have to be combined with reverse engineering of the terminal firmware, and there have already been some such attempts online by others.

However, I do not like doing destructive reverse engineering of the terminal. I prefer purely external, non-invasive measurements.

I only have a few rtl-sdr dongles and some AD9361-based SDRs. The AD9361 supports a maximum sampling rate of 61.44 MHz and a maximum analog bandwidth of 56 MHz. This is clearly insufficient for covering the full 500 MHz Starlink uplink spectrum or the 2 GHz downlink spectrum.

At first glance, an RFSoC with several-GHz sampling capability would be the ideal solution. It could easily capture the full-band signals of all eight Starlink channels simultaneously.

But I do not have an RFSoC.

Does this mean the research has reached a dead end?

When one path seems to lead nowhere, another suddenly opens up.

At first glance, an RFSoC seems almost perfectly suited for full-bandwidth Starlink measurements. However, its enormous capability also creates practical problems.

Such measurements need to cover the entire period during which multiple satellites pass overhead, preferably at least 10 minutes. The enormous sampling rate of an RFSoC generates a huge amount of raw IQ data. Storing this data losslessly, transferring it to a computer in real time or afterward, and processing the resulting huge files would place extremely high demands on the computer’s I/O, CPU and memory.

So let’s rethink the actual problem.

Our goal is to study the real-time operating channels. We are not interested in the detailed IQ content of the signals here (I have captured and analyzed the signal before). We only need to know whether a signal is present and how long it remains on a given channel.

From this perspective, we do not need extremely high sampling rates and wide bandwidth.

And we should not forget that the AD9361 itself is a remarkably flexible chip with many hidden/unusual functionalities. Its capabilities can be explored extensively through software, the large amount of information in its documentation, and its register map document.

My final solution

I configured the AD9361 to perform 10,000 frequency hops per second to scan the eight Starlink uplink channels.

In other words, the receiver changes its center frequency every 100 μs. It therefore takes only 800 μs to scan all eight channels once.

Of course, this is done after downconverting the Starlink uplink signals using a 14 GHz LNB (see my 1st Starlink series post).

This allows me to monitor the uplink frequency of my Starlink Mini continuously for a long period while generating only a very small amount of data. Even my old AMD computer can process it easily.

If anyone has accurate satellite ephemeris data and beam information, the following measurements (see the end) can be combined with that information to further investigate Starlink’s frequency/channel allocation strategy:

• frequency allocation between satellites;
• frequency allocation between beams on the same satellite;
• channel switching within a single beam (if any);
• and potentially the relationship between channel allocation and satellite/beam scheduling.

The measurement data

• Measurement start time: UTC 2026-08-15 10:18:23.206335
• Measurement location: Southern Ghent, Belgium

The end

For example, the hardware version reported by my Starlink Mini through gRPC is:

“hardware_version”: “mini1_panda_prod2”

• mini1: identifier for the first-generation/first-version Starlink Mini hardware platform
• panda: an internal Starlink hardware/platform codename. Since it is called “Panda,” could it have some connection to China?
• prod2: production hardware revision / production variant

Although gRPC exposes many configurable and readable interfaces, most of them return Unimplemented when actually accessed. A smaller number explicitly return PermissionDenied.

One particularly interesting gRPC interface is called iqCapture. This really looks like an interface that could allow the Starlink terminal to capture IQ samples for signal analysis. Another piece of supporting evidence, the interface immediately following iqCapture is getRadioStats, which also looks like an interface for obtaining low-level radio information.

After searching around, I have not found any publicly documented example of using the Starlink gRPC interface to obtain low-level radio information such as the real-time transmit frequency, channel, modulation scheme, etc. Perhaps accessing this information requires deeper firmware analysis or reverse engineering as some others did.

Interestingly, gRPC can provide the complete terminal power-up initialization sequence and its timing.

"initialization_duration_seconds": {
    "attitude_initialization": 285,
    "burst_detected": 169,
    "ekf_converged": 361,
    "first_cplane": 175,
    "first_pop_ping": 215,
    "gps_valid": 64,
    "initial_network_entry": 171,
    "network_schedule": 176,
    "rf_ready": 23,
    "stable_connection": 0
}

Initialization timeline

23 s — RF ready

The RF subsystem becomes ready first.

64 s — GPS valid

The GPS solution becomes valid.

169 s — Burst detected

This may indicate that the terminal has detected a valid satellite downlink burst for the first time.

171 s — Initial network entry

This probably means that the terminal has successfully completed the initial network access procedure.

175 s — First C-plane

The control-plane connection is established.

176 s — Network schedule

This may mean that the terminal has received its initial radio resource allocation from the network scheduler.

215 s — First PoP ping

The terminal successfully reaches the network/Point of Presence for the first time.

285 s — Attitude initialization

This may refer to initialization of the terminal’s attitude estimation. It may be related to antenna pointing and beam-pointing calibration.

After all, Starlink terminals support operation while moving — i.e., connectivity while in motion. This requires a good internal inertial measurement unit (IMU), allowing the phased-array antenna to continuously track fast-moving LEO satellites using electronic beam steering.

361 s — EKF converged

EKF usually means Extended Kalman Filter. It converges after 361 seconds.

Kalman filtering has been an important algorithm in spacecraft navigation and docking since the Apollo era and is still widely used in positioning, navigation, and guidance systems. Considering the excellent in-motion connectivity capability of Starlink terminals, the presence of an EKF is not surprising.

From power-on to the first successful ping takes only a little over three minutes. Is that fast or slow?

The gRPC interface also provides a surprising amount of information about beam pointing, terminal attitude, and sky obstructions.

It even provides the quaternions needed to transform between the terminal coordinate system and the geographic coordinate system.

There are also various performance metrics, event logs, and statistics, including:

• Ping packet loss rate
• Ping latency
• Downlink and uplink throughput
• Connection-loss events
• Handover events
• And other link statistics

Based on this information, several open-source projects can use the gRPC interface to display, in real time:

• Terminal attitude
• Beam pointing
• Sky obstruction maps
• Link performance
• The Starlink satellite that is most likely to be serving the terminal, based on orbital ephemeris data

gRPC can also report information from the terminal’s internal GPS module, including:

• Number of visible satellites
• Satellite health/status
• Convergence status of the GPS internal positioning and navigation filter

According to information available online, older firmware versions could reportedly provide SNR (Signal-to-Noise Ratio). In newer firmware, however, this appears to have been replaced by only a binary indicator:

is_snr_above_noise_floor = true/false

The gRPC interface also exposes the ready state of several internal modules:

"ready_states"
cady = false
scp = true
l1l2 = true
xphy = true
aap = true
rf = true

My current guess is that these modules form a hierarchy from lower-level hardware toward higher-level processing:

rf — RF subsystem
aap — reportedly the Active Antenna Processor
xphy — transceiver / PHY-related subsystem
l1l2 — Layer 1 and Layer 2
scp — reportedly the System Control Processor
cady — based on information from network analysis, possibly related to the clock source or time reference

The exact meaning of some of these internal module names remains unknown. Further firmware analysis may reveal their actual functions.

From a communications perspective, Starlink largely adopts technology comparable to LTE from about 18 years ago.

Starlink can be viewed as a simplified SISO LTE system or a SISO Wi-Fi 6 system, with carrier aggregation,.

Although it incorporates onboard processing, digital beamforming, and phased-array antennas, these are less communication-standard-specific technologies. They are enabling technologies for efficiently constructing multiple beams (cells) and multiple SISO links.

The LTE standard was largely defined by 2008.

Even in 2026, Starlink still lacks one of LTE’s key features: MIMO. The patent contains no discussion of spatial multiplexing or multiple spatial data streams.

Does this mean the Starlink engineers were unfamiliar with advanced communication techniques?

Obviously not.

The patent was filed in 2021, thirteen years after LTE had already become well established in 2008.

Possible reasons include:

• Under a line-of-sight (LoS) channel model, long-distance communication between a single satellite and a single terminal is dominated by far-field plane-wave propagation, rather than near-field spherical-wave propagation. As a result, it is difficult to construct a MIMO channel matrix with rank greater than one.
• Although multi-user MIMO (MU-MIMO) could be implemented using multiple satellites serving multiple terminals, the high orbital velocity and varying geometry of multiple LEO satellites make MU-MIMO considerably more challenging.

In the future, Starlink may gradually introduce technologies such as MU-MIMO, Inter-Cell Interference Coordination (ICIC), cell-free architectures, and inter-satellite coordination to improve spatial reuse and system capacity without increasing spectrum or satellite count.

Starlink may also introduce multiple spatial data streams at the terminal, for example through simultaneous connections to multiple polarizations or multiple satellites. This could further improve user experience and price premium.

The current burst structure already appears potential with future MIMO expansion.

The patent allows multiple channel estimation (CE) symbols, similar to the multiple LTFs used in Wi-Fi (for MIMO). Multiple CE symbols can naturally support channel estimation for multiple spatial streams.

Maybe, Some of these capabilities may already be appearing through Starlink’s frequent over-the-air (OTA) updates.

By continuously monitoring Starlink uplink and downlink signals, future changes of this kind may be observed.

Technology is neither “advanced” nor “outdated” by itself. Its value depends on how well it matches the application.

The essence of engineering is trade-offs.

Done is better than perfect.

Multiple Access

Starlink uses a combination of OFDMA and TDMA for multiple access.

Duplex Mode

Although all Starlink links operate in Frequency Division Duplex (FDD), with separate uplink and downlink frequencies, the user terminal operates in half-duplex mode.

One possible reason is that half-duplex operation eliminates the need for separate transmit and receive antennas or a frequency duplexer. An RF switch may be sufficient, reducing terminal cost and size.

Satellites and gateway stations operate in full-duplex mode. Satellites use multiple phased-array antennas with separate transmit and receive apertures. When no gateway station is within coverage, a satellite can access a gateway through inter-satellite links.

Beams

The beamwidth of a Starlink satellite is approximately 2 degrees.

Gateway Stations

Communication between a satellite and a gateway station is always point-to-point. There are no scenarios in which multiple satellites communicate with the same gateway simultaneously, or multiple gateways communicate with the same satellite simultaneously.

This may explain why publicly available photos of Starlink gateway stations show many radomes (“mushrooms”). Each radome may communicate with only one satellite at a time.

The patent frequently mentions parabolic antennas when describing gateway stations. This suggests that the radomes may contain mechanically steered Ka-band parabolic antennas, rather than phased-array antennas.

One possible advantage is lower cost by using mature commercial Ka-band parabolic antenna technology. Wideband Ka-band phased arrays are likely much more expensive.

Phased-Array Interface

Parabolic antennas still play a role in the Starlink system, most likely at gateway stations.

This may also explain why the patent specifies that the modem can interface with two types of antennas:

• Parabolic antennas
• Digital Beamforming (DBF) antennas (phased-array antennas)

For parabolic antennas, the modem interface consists of conventional ADC/DAC connections, implying that the antenna includes the RF front-end.

For DBF antennas, the modem connects through a high-speed SerDes interface, indicating that the DBF module is a complex digital subsystem containing substantial digital signal processing.

Subcarriers

The patent states that Starlink OFDM uses a half-subcarrier offset (1/2-bin offset) to achieve spectrum symmetry.

This avoids having one fewer positive-frequency subcarrier than negative-frequency subcarriers.

The approach resembles the uplink DFT-s-OFDM implementation used in LTE and also helps reduce DC interference.

Channel Model

The patent explicitly assumes a predominantly line-of-sight (LOS) propagation environment.

As a result, the pilot clusters located at the two edges of a user’s allocated bandwidth can be used with simple frequency-domain linear interpolation to estimate propagation delay.

Accurate delay compensation is particularly important in satellite communications. The patent also provides extensive discussion of Doppler compensation, Sampling Frequency Offset (SFO), and Carrier Frequency Offset (CFO).

This is consistent with my previous analysis.

MAC Random Access

The patent also specifies the purpose of MAC-layer random access.

It is used for:

• Initial network access
• Bandwidth requests

This design is similar to the random access procedures used in LTE and other cellular systems.

The patent defines links and RF links as follows.

• FIG.4 defines a link from the perspective of the user terminal (UT). A link is an L3 connection to a UT, including the associated MAC, PHY transmitter, PHY receiver, and one or more beams.
• An RF link is defined as a paired downlink (DL) and uplink (UL) channel starting from the MAC layer. The patent explicitly states that an RF link is a logical concept, consisting of one MAC, one PHY transmitter, and one PHY receiver. It also states that an RF link may use multiple beams. One possible guess is that when a UT is located near the boundary between two beams, a single RF link may serve that terminal through both beams.

The patent states that a satellite can have 32 RF link pairs, and each RF link may include multiple frequency bands:

“In an embodiment, the SAT 104 can include 32 RF link pairs (e.g., 32 UL RF links and 32 DL RF links), and each of the DL and UL links can include a plurality of frequency bands (e.g., a DL can have 8 frequency bands, a UL can have 8 frequency bands).”

We already know that the Ku-band user link consists of:

• Eight 250 MHz downlink channels (2 GHz total)
• Eight 62.5 MHz uplink channels (500 MHz total)

A natural interpretation is that a single RF link can span the entire bandwidth by including all eight channels.

However, the wording is ambiguous.

Does the patent mean that each link can have eight frequency bands, or that each RF link can have eight frequency bands?

Does “can have” mean that eight bands are always active simultaneously, or simply that up to eight bands are supported?

Must these eight bands be eight non-overlapping frequency channels, or could they instead represent reuse of the same channel across eight geographically separated beams?

In my previous analysis, I assumed that each RF link simultaneously carried eight 8*250 MHz downlink channels. This resulted in a total downlink capacity of 320 Gbps for 32 RF links.

However, 320 Gbps is much higher than the publicly reported capacities of current Starlink satellites. Public sources typically report approximately 20 Gbps for first-generation satellites and around 80 Gbps for V2 Mini satellites. Even the not-yet-launched V3 satellites are reported to provide about 1 Tbps of downlink capacity —— not super higher than 320Gbps.

Therefore, either my previous blog interpretation was incorrect, or the 2021 patent describes a configuration that was considerably more ambitious than the satellites eventually deployed so far.

Additional information in the patent provides further insight.

Regarding the relationship between the modem and the RF link, FIG.5 suggests that a modem contains one PHY transmitter and one PHY receiver, implying a one-to-one correspondence between a modem and an RF link.

However, later figures suggest a more complex implementation. A modem may contain two transmitter/receiver pairs, supporting two independent 250 MHz Ku-band downlink channels. In that case, one modem would contain two RF links.

FIG.20 illustrates an example satellite configuration with four modems for Ku band downlink. Each modem supports two 250 MHz channels, and each channel corresponds to one beam, resulting in a total of eight 250 MHz downlink channels. According to the earlier RF link definition, this is an example of one modem (or RF link) supporting two frequency bands, rather than eight.

These eight 250 MHz channels provide a total downlink capacity of 10 Gbps, noticing 5 bit/s/Hz in my previous blog.

The patent also notes that the four-modem configuration in FIG.20 is only an example and could instead use 16 modems.

With 16 modems, the satellite would support 32 independent 250 MHz downlink channels, providing a total downlink capacity of 40 Gbps. This example also aligns naturally with the patent’s reference to 32 RF links.

Based on this interpretation, the Ku-band downlink capacity explicitly described in the patent falls in the range of 10–40 Gbps, which is much closer to the reported capacities of current Starlink satellites than the 320 Gbps estimated in my previous blog analysis.

According to FIG.21, Starlink uses two types of modem chips/modules based on capability of demodulation bandwidth and data rate.

Modem for the Ku-band User Link

This modem is used for:

• Terminal reception of a 250 MHz Ku-band downlink channel.
• Satellite reception of four 62.5 MHz Ku-band uplink channels (4 × 62.5 MHz = 250 MHz).

It provides a peak data rate of 1.25 Gbps over 250MHz bandwidth.

Modem for the Ka-band Feeder Link (satellite — gateway)

This modem is used for:

• Gateway reception of two 250 MHz Ka-band downlink channels (2 × 250 MHz = 500 MHz).
• Satellite reception of a 500 MHz Ka-band uplink channel.

It provides a peak data rate of 2.5 Gbps over 500MHz bandwidth.

From these informations, the Starlink modem achieves a spectral efficiency of 5 bit/s/Hz.

The highest modulation supported is 64QAM, whose ideal uncoded spectral efficiency is 6 bit/s/Hz. After accounting for channel coding, packet headers, and other protocol overhead, the resulting 5 bit/s/Hz is both efficient and a reasonable engineering result.

In deployment:

• A user terminal contains a single modem.
• Satellites and gateway stations contain multiple modems, forming a modem pool onboard.
• The modems are connected in a daisy-chain architecture rather than a star topology to aggregate capacity.

Each Starlink satellite user link provides:

• 32 Ku-band downlink RF chains
• 32 Ku-band uplink RF chains

Each RF chain supports eight parallel frequency channels:

• Ku uplink: 8 × 62.5 MHz = 500 MHz, with a total data rate of 2.5 Gbps
• Ku downlink: 8 × 250 MHz = 2 GHz, with a total data rate of 10 Gbps

32 chains in total offer 80Gbps (2.5x32) UL and 320Gbps (10x32) DL capacity.

Each RF chain supports approximately 200 simultaneously active terminals. Each satellite supports approximately 6,400 (32 chains times 200 UT/chain) simultaneously active terminals.

Assuming equal resource allocation:

• Average uplink per terminal: 12.5 Mbps (2.5Gbps/200)
• Average downlink per terminal: 50 Mbps (10Gbps/200)

In practice, depending on service tiers and network oversubscription, a satellite can serve significantly more than 6,400 subscribed users.