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.

The UW is used differently on different communication links.

Satellite–Terminal Link

Uplink: When multiple terminals access the same satellite, each terminal is assigned a different UW. The UW is generated by a 7-stage LFSR-based PN generator, driven by the Channel ID.

Downlink: When multiple satellites cover the same geographic area, for example to improve reliability or avoid signal blockage, each satellite is assigned a different UW.

Satellite–Gateway Link

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

However, this link uses two Ka-band polarizations, LHCP and RHCP, and a different UW is assigned to each polarization.

Starlink supports the following modulation schemes:

• BPSK
• QPSK
• 8-QAM
• 16-QAM
• 32-QAM
• 64-QAM

Unlike Wi-Fi and LTE, Starlink includes 8-QAM and 32-QAM. A possible reason is that satellite links are highly power-limited due to large propagation losses. Finer modulation granularity allows Adaptive Modulation and Coding (AMC) to utilize the available link margin more precisely and avoid wasting transmit power.

The patent explicitly mentions the Adaptive Modulation and Coding (AMC) mechanism.

User data is encoded using LDPC. Data scrambling uses a 15-stage Linear Feedback Shift Register (LFSR).

The physical-layer packet header, analogous to the Wi-Fi SIGNAL field, is encoded using a 64-state (constraint length 7), rate-1/3 convolutional code with BPSK modulation. This is similar to the coding used for LTE control/broadcast channels such as the PDCCH and PBCH.

The packet header contains:

• Sequence number
• Modulation and Coding Scheme (MCS)
• Packet length

Within a radio frame, the physical-layer header of the first PDU contains 27 bits of information, while the headers of subsequent PDUs contain 23 bits.

PDUs are divided into data PDUs and signaling PDUs. Signaling PDUs are used for communication between MAC entities, such as the random access procedure (RACH) between the terminal MAC and the satellite MAC.

Starlink also employs a PN-based symbol scrambling method for modulated symbols. A Linear Feedback Shift Register generates a random 2-bit value that rotates each transmitted symbol by 0°, 90°, 180°, or 270°. This scrambling can transform a BPSK symbol stream into a QPSK constellation.

All frequency-domain subcarriers, including both data and pilot subcarriers, are scrambled using PN phase rotations generated by a 15-stage LFSR. As a result, BPSK pilot symbols become QPSK after scrambling.

The 128-sample base sequence used for the time-domain Unique Word (UW) is also originally BPSK and is converted to QPSK through PN phase rotation scrambling. UW scrambling uses a 7-stage LFSR.

A small change in clock rate is also caused by special (motion) and general (gravity) relativistic effects but it is quite small in low Earth orbits (about 0.2 ppb or parts per billion).

This is the relativistic effect considered by Starlink when analyzing synchronization error sources in an OFDM system.

The conclusion is that the clock-rate difference caused by relativistic time dilation is much smaller than other synchronization error sources, such as Doppler shift and sampling-time drift due to satellite motion, crystal oscillator manufacturing tolerance, and temperature drift. Therefore, it can be safely neglected.

Perhaps I simply have not read enough papers, but this is the first time I have seen relativistic effects explicitly discussed in the context of OFDM synchronization algorithms. （of course I know that GNSS does consider it)

I do wonder whether, in deep-space communication scenarios—such as solar probes or Mars missions—the clock errors introduced by relativity become significant enough to require explicit compensation for communication synchronization.

Although I have not yet finished reading the patent, I now strongly feel that this is not merely a patent. It is a comprehensive treatise on modern OFDM communication engineering, covering fundamental principles, system design, and implementation details with remarkable completeness. Anyone who thoroughly understands every section of this patent would gain an excellent foundation in communication theory, system design, and engineering practice.

The first author of the patent, Martin McCormick, once remarked with characteristic humility:

“I’ve earned the somewhat dubious distinction of holding more patents than anyone else working for Elon Musk. I’ve invented about 10% of SpaceX’s entire patent portfolio.”

After reading this patent, I understand that statement very differently. He was not simply writing patent applications—he was writing what is effectively a technical textbook. There is nothing “dubious” about that achievement. The breadth and depth of his expertise are truly remarkable.

It is also said that he was among the last students of Alan V. Oppenheim. If so, his work certainly lives up to that reputation.