I replaced the previous software-controlled AD9361 frequency-hopping implementation, which achieved 10,000 hops per second [1,2], with hardware-controlled hopping, enabling measurements at 80,000 hops per second.
The AD9361 measurement system channel is switched every 12.5 µs, allowing all eight Starlink channels to be scanned in just 100 µs.
Although the AD9361 datasheet specifies a channel-switching settling time of 20–30 µs, my measurements show that 10 µs is sufficient for stable in-band energy measurements (not checking the signal quality, EVM, SNR etc.). The remaining 2.5 µs is used for energy integration.
The new hardware-controlled frequency-hopping system successfully reproduced the RF behavior previously observed using software-controlled hopping [1,2,3,4], further strengthening confidence in the validity of these Starlink terminal measurement experiments.
Using two SDRs and two LNBs to simultaneously measure Starlink terminal transmissions [1,2] and receiver LO leakage [3,4], I confirmed that, during normal operation, the terminal consistently selects the same channel number for both uplink and downlink. In other words, the uplink and downlink channels are paired via choosing the same channel number (TDD switching between UL and DL), even though their center frequencies are different (FDD).
Starlink downlink channel numbers 0–7 correspond to eight 500 MHz channels spanning 10.7–12.7 GHz. Uplink channel numbers 0–7 correspond to eight 62.5 MHz channels spanning 14.0–14.5 GHz.
Another finding that surprised me was the relatively strong RF signals radiation from an ordinary consumer Starlink terminal. I am not sure whether this degree of radiation level is expected behavior or not, what I do observe is that even at a distance of several meters, an normal satellite TV LNB can still pick up clearly detectable transmission signals and receiver local-oscillator leakage, even when its feed horn is pointed away from the back of the terminal’s phased-array antenna.
This measurement deliberately used such a configuration, with the LNB positioned several meters away and facing away from the terminal’s back. Otherwise, adjacent-channel leakage would have been much more prominent.
In theory, a Starlink terminal communicates with a satellite using a narrow, pencil-shaped beam with a beamwidth of approximately 1–2 degrees. Such a narrow beam should, in principle, have a low probability of interception. In practice, however, the terminal’s phased-array antenna appears to produce detectable signals in multiple directions (side lobe or Spurious emission?), including behind the antenna, at distances of several meters, using nothing more than an ordinary satellite TV LNB.
These observations may provide a basis for estimating the off-axis RF (Tx signal and Rx LO Leakage) power level of an ordinary consumer Starlink terminal through link-budget calculations.
Real-time visualization
I also vibe-coded a real-time visualization interface, making it possible to observe uplink transmission activity and downlink LO leakage simultaneously by human eyes. Those N*15s period channel switching event can be seen very obviously by human eyes.
When a Starlink speed test is started, uplink transmissions become significantly denser, appearing almost continuous in the plots. This confirms that the measurements are indeed capturing actual ongoing Starlink terminal activity rather than random environmental interference.
Below are several screenshots captured during real-time measurements.
Each row represents one channel. Vertical axis: Signal strength (dB). Horizontal axis: Time (seconds), with a total span of 70 seconds The left panel shows activity across the eight uplink channels (measured by scanning 8 possible UL frequencies of transmitted RF signals). The right panel shows activity across the eight downlink channels (measured by scanning 8 possible DL frequencies of receive local-oscillator leakage).
During ten minutes of visual observation, I did not observe a single instance in which the uplink and downlink channel numbers differed.
[1] Measure Starlink Channel Switching: 10,000-Hop/s Fast-Frequency Measurements by AD9361
[2] Starlink Terminal Cold-Start RF Emission Behavior Fingerprinting
Faster Than You Think! Starlink Channel and Satellite Switching
[3] Starlink Terminal Local Oscillator Leakage Reveals Rx Scanning and Further RF Calibration Discussion
]]>The answer is counter-intuitive: The server doesn’t need to know. It just send the packet to a nearest/arbitrary Starlink gateway/PoP.
Another counter-intuitive thing is that: Starlink Aviation heavily relies on the fiber on the ground.
The well-known paper “Measuring Starlink Aviation Around the World” was recently made publicly available in its entirety. Out of curiosity, I looked into the anycast mechanism mentioned in the paper and wrote this article about it (99.2% confidence). I haven’t worked much with network protocols myself, so this has also been a learning experience for me.
At the end, I’ll also introduce the first-generation Starlink aviation solution for mobile IP, which resembles the HLR/VLR architecture used in early era of mobile communications, as well as the second-generation solution based on dynamic aircraft IP addresses (GeoIP prefixes). I’ll discuss the advantages and disadvantages of each. After that, you’ll have a much better appreciation of the elegance of the current, third-generation solution of Starlink aviation.
Let’s get started.
1 . First, Think About Your Home Wi-Fi Network
We all know that a home Wi-Fi network has something called a gateway—for example, the device supplied by your internet service provider (ISP).
This gateway is actually a router. It has its own IP address, which is generally a fixed address assigned by your ISP. Because it remains connected to a fixed port on an upstream router at the ISP’s facility, there is usually no need to change its IP address. After all, your house doesn’t grow legs and move around!
The Wi-Fi router routes packets between your home network and the external internet, allowing the various devices in your home to communicate with other devices and servers online.
For example, suppose an internet server needs to send a packet to a device on your home Wi-Fi network, such as the phone you’re using to binge-watch a TV series. The packet leaves the server, passes through multiple routers, and eventually reaches your home Wi-Fi router. The final hop is from your home Wi-Fi router to your device.
How do routers across the internet know which router to forward a packet to next?
Because routers exchange routing information using various protocols and maintain routing tables—a kind of map of reachable network destinations. When a packet arrives, a router examines its destination IP address and consults its routing table to determine the next hop.
When your phone accesses the internet over your home Wi-Fi, it has an IP address within your home network, and the internet knows to send packets destined for your connection toward your home Wi-Fi router. When your phone accesses the internet at work, packets destined for it are instead routed toward your company’s Wi-Fi router.
2 . An Aircraft Equipped with Starlink Is Like a Flying Home
An aircraft equipped with Starlink is similar to a home Wi-Fi network. Imagine the aircraft as a house in flight. The cabin Wi-Fi is equivalent to the Wi-Fi network in your home, and passengers use the Starlink router to access the internet.
But unlike a stationary house, an aircraft-mounted Starlink router continually connects via satellite to different Starlink ground gateway sites, or Points of Presence (PoPs), depending on the aircraft’s location and flight path. These PoPs provide the aircraft with access to the internet.
Now, let’s think more carefully about that Starlink router on the aircraft. This is where things get interesting.
As mentioned earlier, a home gateway router has its own IP address, which is generally fixed because it has a stable connection to an upstream router at the ISP’s facility.
But an aircraft-mounted Starlink router might be in Asia one moment, Europe the next, and the Americas later on. Although this router can also have a fixed IP address—and the current, third-generation solution does indeed work this way—the aircraft is constantly moving between different network access points.
Suppose a passenger is streaming a TV series on the aircraft. Netflix’s servers know that packets destined for this passenger’s connection must be sent to the aircraft’s Starlink router IP address, after which the router forwards them to the passenger’s device.
But Netflix’s servers are not located inside the Starlink gateway/PoP site to which the aircraft is currently connected via satellite. Netflix simply sends packets destined for the aircraft’s IP address into the internet.
How does the vast internet know where to send those packets? The aircraft is constantly moving and changing PoP! With so many Starlink PoPs around the world, which one should the internet routes the packets to so that they can reach the aircraft?
To explain this, we first need to clear up a misconception about the internet itself. In a sense, the internet doesn’t actually exist as a single, unified network!
3 . The Internet Is Really a Network of Networks
There is no single company, ISP, or organization that builds, operates, and manages the entire internet as one unified network.
What we call the internet is actually a collection of countless interconnected Autonomous Systems (ASes).
You can think of an AS as a network built and operated by a company or network operator to serve its own customers. Every AS is assigned an Autonomous System Number (ASN).
Google’s network is AS15169, while Starlink’s network is AS14593. AT&T also has AS number(s).
Within its own AS, an operator can provide connectivity between its customers. For example, one AT&T customer can communicate with another AT&T customer.
But what if customers within one AS could communicate only with other customers in the same AS? That would be rather inconvenient.
Suppose a AT&T customer wanted to communicate with a customer of european operator. Would they have to register as a customer of the european operator and establish a dedicated link across the Atlantic Ocean just to communicate with that person?
Of course not.
As a customer of AT&T’s AS, you can communicate with users on other ASes without becoming a customer of those networks. The solution is to interconnect the ASes.
To enable its customers to communicate with users on other networks, each AS establishes connections from one or more of its border routers to border routers belonging to other ASes.
If the routers belonging to two ASes happen to be in the same facility/data-center, connecting them may be as simple as plugging in a fiber-ethernet cable. But what if they are far apart—for example, on opposite sides of the Atlantic Ocean?
No problem. Specialized companies provide connectivity services between networks. Of course, you have to pay for it.
So, the internet is essentially a vast collection of independently operated networks interconnected in a variety of ways.
4 . How BGP Connects These Networks
Traffic between ASes flows through their border routers. These routers use a protocol called BGP (Border Gateway Protocol) to exchange routing information.
In simplified terms, each AS announces which globally unique public IP address prefixes it has in use. Other ASes can then use this information to determine where to forward packets destined for those prefixes.
In effect, an AS tells other networks:
“These IP address ranges are reachable through my network. If you have packets destined for them, forward those packets to my network.”
For Starlink, the border routers connecting its network to other ASes are distributed across its global network infrastructure, including its ground gateway sites and PoPs.
Imagine that Starlink has obtained a large pool of public IPv6 addresses. When an airline becomes a customer, Starlink installs one or more Starlink routers on the aircraft and assigns each router one or more fixed public IP addresses.
Starlink can then announce the relevant IP prefixes to other networks through multiple PoPs around the world.
The message to the rest of the internet is essentially:
“These IPv6 addresses are reachable through the Starlink network. If you have packets destined for them, you can forward those packets to an Starlink PoP.”
5 . Anycast: Send the Packet to Any Starlink PoP
Now we can return to our original question.
Regardless of which AS hosts the ground server an aircraft passenger is accessing, when that server needs to send a packet to the aircraft’s Starlink router, it can forward the packet toward a Starlink PoP selected by the internet’s routing system.
Starlink makes the aircraft’s IP address reachable through multiple PoPs. Each of those PoPs can act as an entry point into the Starlink network.
In that sense, the internet can send the packet to any Starlink PoP, because Starlink’s routing announcements make the relevant destination reachable through multiple entry points.
This is the idea behind anycast:
To reach a particular IP address, send the packet to any one of the multiple network entry points announcing reachability to that address.
The ground internet does not need to update its routing tables every time the aircraft changes location. The externally visible routing information can remain unchanged even while the aircraft moves between satellite links and ground gateway sites.
Once the packet reaches a Starlink PoP, the remaining task becomes much easier.
The packet has entered Starlink’s own AS. Starlink’s internal network and network control systems can determine which PoP is currently serving the aircraft and forward the packet accordingly.
The packet can then travel along a dedicated path within the Starlink network—for example, using an MPLS tunnel over dedicated fiber network—to the PoP currently connected to the aircraft. That PoP sends the packet to the aircraft via satellite.
Starlink operates dedicated long-distance fiber-optic links within its network, potentially supplemented by inter-satellite links. These connections can allow packets to move rapidly between Starlink PoPs without relying entirely on the external internet for the long-distance portion of the journey.
An Example
Imagine a server on the US West Coast needs to send a packet to a Starlink router aboard an aircraft flying over Asia. The aircraft is currently connected via satellite to a Starlink ground PoP in Asia.
The server only needs to forward the packet to a Starlink PoP near the US West Coast.
That PoP then forwards the packet across Starlink’s private, high-speed trans-Pacific network connection to the Asian Starlink PoP currently serving the aircraft.
Finally, the Asian PoP transmits the packet via satellite to the aircraft.
This is the essence of Starlink’s current approach: an aircraft-mounted router can retain a fixed IP address while flying around the world, without sacrificing efficient network paths.
This is the third-generation solution. Let’s look at the first two generations and understand why the third is so elegant.
6 . First Generation: Always Route Through the Home PoP
In the first-generation solution, an aircraft would always use its designated home PoP, regardless of where it was flying. This might be a Starlink ground PoP near the airline’s headquarters or primary operational base.
The concept is similar to the Home Location Register (HLR) and Visitor Location Register (VLR) used in early mobile communication networks.
The routing tables of the public internet would not need to change as the aircraft moved. They would direct packets destined for the aircraft ALWAYS to its home PoP, which would then forward them to the aircraft, either directly via satellite or through Starlink’s internal network or a satellite backbone.
The disadvantage is obvious.
Suppose a server on the US West Coast needs to send a packet to a Singapore Airlines aircraft also flying nearby over the US West Coast, but the aircraft’s home PoP is in Singapore.
The packet first travels across the public internet, crossing the Pacific to reach the Singapore-based home PoP. That PoP then uses Starlink’s internal network or a tunnel—over fiber, satellite, or both—to send the packet back across the Pacific to the US West Coast PoP, because it knows that the aircraft is currently connected to that PoP.
The packet has effectively traveled halfway around the world and back.
In reality, the packet could have been delivered directly to the US West Coast PoP and sent to the aircraft via satellite. Instead, it takes a substantial detour, resulting in unnecessary latency and inefficient traffic distribution.
7 . Second Generation: Change the Aircraft’s IP Address as It Moves
In the second-generation solution, the aircraft changes its IP address as it moves between Starlink PoPs.
The aircraft’s IP address reflects its approximate geographical location through a GeoIP prefix—a globally coordinated arrangement in which public databases map IP address ranges to approximate geographic locations.
When a ground server needs to send a packet to the aircraft, the internet can use the aircraft’s current IP prefix and the associated routing information to direct the packet toward a Starlink PoP serving the relevant geographic area. That PoP then forwards the packet to the aircraft via satellite.
The main advantage is that packets no longer need to make the long detours associated with the first-generation approach.
However, the second-generation solution has two disadvantages:
The aircraft’s IP address changes during flight. Some higher-layer network applications and protocols, including TCP connections, may be interrupted and require reconnection when the IP address changes.
The external internet independently determines the route to the PoP. Because traffic travels through networks outside Starlink’s control, Starlink has less control over the resulting latency and quality of service.
8 . Third Generation: Fixed IP, Efficient Routing
The third-generation solution retains the second generation’s main advantage—avoiding unnecessary detours—while addressing both of its major drawbacks.
First, the aircraft’s IP address remains unchanged. Higher-layer applications and protocols, including TCP, therefore do not need to reconnect merely because the aircraft moves between PoPs.
Second, the internet only needs to deliver the packet to any (could be the closest one to the traffic source) Starlink PoP. Starlink then handles the long-distance forwarding entirely within its own network, using an efficient internal path—for example, an MPLS-based private fiber path—rather than relying on the external internet to carry the packet all the way to the aircraft’s current location.
This gives Starlink greater control over routing, latency, and quality of service.
The key idea is to separate the aircraft’s stable network identity from its constantly changing physical location.
The internet gets the packet into Starlink’s network via any PoP. Starlink takes care of getting it to the aircraft.
If you’ve made it this far and found the article helpful or learned something new, please consider liking, supporting, and sharing it.
And if you spot anything inaccurate or incorrect in the article, I’d welcome your feedback!
]]>More than 20 years ago, people discovered that Linksys/Cisco Wi-Fi routers ran Linux. The resulting legal pressure forced the companies to release the corresponding source code. This helped pave the way for the OpenWRT project. Today, many Wi-Fi routers are built on Linux and OpenWRT. In principle, you can request the corresponding source code from a manufacturer. If it fails to comply with its GPL obligations, legal action may be an option to enforce those rights.
So, does Starlink comply with GPLv2 and responsibly release its Linux source code?
The answer is yes. However, the publicly released version lags significantly behind the versions used in widely deployed Starlink terminals.
1 . What has SpaceX open-sourced?
On its official website, Starlink states on the Software License & Usage Terms page that its terminals contain open-source software. The page includes the following statement:
You may request access to the code for our Open Source Components through your Starlink account.
In addition to allowing Starlink customers to request source code, SpaceX has published code on GitHub under its official account, SpaceExplorationTechnologies.
Its public repositories include:
- OpenWRT: Code for two generations of Starlink Wi-Fi routers.
- U-Boot: The Linux bootloader, licensed under GPLv2.
- enterprise-api: API interfaces for enterprise customers, such as maritime and aviation customers, etc.
- sssd: A Linux device management and configuration component, authored by Chadwick Banning and licensed under Apache 2.0.
- linuxptp: Software for high-precision time synchronization, licensed under GPLv2. Time synchronization is particularly important because Starlink terminals and the network reportedly change configurations approximately every 15 seconds.
- Linux kernel: A version of the Linux kernel used by the Starlink modem (confidense 98.1%), licensed under GPLv2.
2 . Which Linux kernel is relevant to the Starlink modem?
The Starlink terminal, also known as Dishy, can be compared to a portable 5G Wi-Fi hotspot. The main difference is that the 5G cellular modem connecting to terrestrial base stations is replaced by a phased-array antenna and modem that communicate with Starlink satellites.
The Wi-Fi subsystem in both 5G Wi-Fi hotspot and Starlink terminal can function as a conventional OpenWRT-based router. However, the OpenWRT Wi-Fi subsystem is not the focus of this article.
The key component is the satellite modem, which runs Linux. The kernel source code discussed above is believed, with approximately 98.1% confidence, to correspond to this modem.
SpaceX has published two versions of its modem Linux kernel modifications that can be found on their github linux repository:
- sx_2022_04_29
- sx_2020_11_25
The sx prefix presumably stands for SpaceX, while the suffix indicates the release date.
The corresponding U-Boot releases have similar dates:
- sx_2022_05_03
- sx_2020_11_25
The linuxptp repository also has a release named sx_v2020_08_06, dated close to the earlier releases above.
Analysis of the newer kernel release, sx_2022_04_29, indicates that the modem is named Catson, and SpaceX’s modifications are based on Linux kernel version 5.10.90.
3 . What have reverse engineers discovered?
There have been three notable rounds of publicly available reverse engineering of the firmware running on Starlink terminals.
3 . 1 KU Leuven researchers, 2021
In 2021, researchers at KU Leuven in Belgium published reverse-engineering findings for the U-Boot bootloader and Linux in the first- or second-generation circular Starlink terminal.
The bootloader version was:
2020.04-gddb7afb
This predates SpaceX’s sx_2020_11_25 release.
The Linux kernel image was created on:
2021-04-16 21:10:45 UTC
This timestamp falls between the two SpaceX kernel releases, sx_2020_11_25 and sx_2022_04_29. The exact kernel version was not identified.
3 . 2 Quarkslab, 2023
In 2023, Quarkslab published firmware reverse-engineering findings covering the V2 circular terminal and the V3 rectangular terminal.
Their analysis identified the Linux kernel in the firmware as version 5.15.55, whereas the kernel version published by SpaceX was 5.10.90.
This shows that by 2023, researchers had already identified a substantial gap between SpaceX’s publicly released kernel source and the newer kernel version found in actual terminal firmware.
3 . 3 Starlink-Research, late 2024
The most recent firmware reverse-engineering findings discussed here were published by the GitHub account Starlink-Research in late 2024. They targeted the V4 terminal.
The firmware contained the following Linux kernel build information:
Linux version 6.1.38-rt12 (buildroot@buildroot) (aarch64-sxbr-linux-musl-gcc.br_real (Buildroot -ga67e963) 12.3.0, GNU ld (GNU Binutils) 2.39) #1 SMP PREEMPT_RT Fri Jun 21 16:20:33 UTC 2024
Several details are worth noting.
First, the kernel is based on Linux 6.1.38, with an -rt12 suffix indicating a PREEMPT_RT patch level. The base version 6.1.38 is way newer than the one SpaceX published on github.
Second, the PREEMPT_RT designation strongly suggests that SpaceX uses a real-time-patched Linux kernel. Such patches reduce scheduling latency and improve the predictability of task execution.
This makes sense for satellite communication equipment, where precise timing and predictable response times can be important.
A useful historical detail: PREEMPT_RT had been under development for roughly 20 years before its integration into the mainline Linux kernel in September 2024, with Linux 6.12. Before that integration, obtaining the full PREEMPT_RT functionality generally required applying the external patch set to a compatible kernel.
The Starlink V4 kernel was built in June 2024, before Linux 6.12 was released. Its use of PREEMPT_RT patches is therefore consistent with the state of Linux development at that time.
If future Starlink terminals use Linux 6.12 or a newer kernel, they may no longer need a separate PREEMPT_RT patch set to obtain the functionality incorporated into the mainline kernel. Because the exact configuration and enabled features will be in the kernel natively.
4 . An interesting detail: Catapult
By the way, the well-known engineer Oleg discovered a modem named Catapult in the Starlink firmware. It appears to be a newer modem generation than Catson.
This is another indication that Starlink’s modem hardware and software continue to evolve, while the kernel source code publicly released by SpaceX may represent an older generation.
Conclusion
SpaceX does publish Linux kernel source code for Starlink terminal modem, and its public repositories include several other open-source components used in the Starlink ecosystem.
However, the publicly released modem kernel is based on Linux 5.10.90, while reverse-engineered firmware has revealed Linux 5.15.55 in earlier terminals and Linux 6.1.38 with PREEMPT_RT patches in the V4 terminal.
The central question is therefore not simply whether Starlink releases Linux source code, but whether the source code made available to users corresponds to the kernel versions actually shipped in their terminals, as required by the applicable GPLv2 obligations.
You might argue that only the dishy user can request the source code access, so most of the poeple (non dishy user) can’t see the code publicly on github. That is possibly true. But personally I believe that the possibility is quite low. The reason is that: the dishy user who receives the source code has rights to re-distribute it again according to GPLv2. So, if any dishy user has received the source code from SpaceX, we might already see it on internet when some user re-distribute it on internet according to the GPLv2 rights. But so far, there isn’t any.
]]>Deep cold start: Power on the Starlink terminal after it has been powered off for several days.
New finding: During a deep cold start, in addition to the 8-channel scanning transmission we previously observed around 24 seconds after the Starlink terminal starts up (https://sdr-x.github.io/starlink-UL-cold-start/), another mysterious, drifting signal can also be observed. This signal can’t be observed during the normal cold start.
It starts at a relatively low frequency, gradually becomes stronger, and moves toward higher frequencies.
It finally disappears with a rapid “swoosh” at an even higher frequency.
The center frequency of 1356.25 MHz shown in the screenshot is the center frequency of Starlink uplink channel 3: 14 + 0.03125 + 2 × 0.0625 GHz = 14.15625 GHz. after downconversion by a Ku-band LNB with a 12.8 GHz local oscillator.
The phenomenon has been verified with two different SDRs, which largely rules out the possibility that it is caused by the SDR hardware. It has also been observed in two deep cold-start experiments.
Below are more screenshots and videos (https://x.com/jxjputaoshu/status/2103834385359454399?s=20). They show that the starting and ending frequencies of this drifting signal can appear at either lower or higher than the center frequency.
Well-known Starlink researcher Professor Jianping Pan from the University of Victoria, Canada, recently presented a paper titled Measuring Starlink Aviation Around the World at the IMC’26 conference in Germany. The first page of the paper has been made public, although the full paper is not yet available.
Based on the publicly available first page of the paper, the basic principle appears to be roughly as follows (confidence: 90%):
1 . First, build a list of candidate addresses
Starlink publicly provides IPv6/GeoIP information:
https://www.ietf.org/slides/slides-ipgeows-paper-position-paper-starlink-00.pdf
This information can be used to obtain a large number of Starlink IPv6 prefixes. Based on Starlink’s address allocation patterns, researchers can then generate possible customer-router addresses, such as ::1 within a /56 prefix.
2 . Send packets to these addresses from a computer or ordinary ground-based server
There is no need to be on a Starlink-equipped aircraft and connected to its in-flight Wi-Fi. Researchers can probe candidate addresses from a home IPv6 network, a university network, cloud servers, or other Internet-connected locations using tools such as ping6 and traceroute6 to determine which addresses are actually online.
3 . Look for IPv6 addresses that “move”
A typical Starlink residential user is associated with a relatively stable network region. But an aircraft-based Starlink user has a distinctive property: the IPv6 address of the aircraft’s Starlink router remains unchanged, while the Starlink PoP it connects through changes as the aircraft flies.
For example:
IPv6: 2605:xxxx:xxxx::1
↓
Doha PoP (Starlink Network to Internet interface in Doha, Qatar)
↓ aircraft in flight
↓
New York PoP (Starlink Network to Internet interface in New York)
The IPv6 address stays the same, but the network access point changes.
This PoP information can be observed from information returned by tools such as traceroute.
4 . Continuously record path changes
Run traceroute measurements every few minutes from multiple locations and record:
IPv6 address + time + RTT + PoP + MPLS information
If a particular IPv6 address is found to:
- remain online for a long period, comparable to the duration of a flight;
- remain unchanged throughout that period; and
- continuously switch between Starlink PoPs in different geographic regions;
then it is very likely to belong to a Starlink router installed on an aircraft.
5 . Finally, match the observations with flight data
The activity period, PoP changes, and latency variations of the IPv6 address can then be compared with ADS-B data and flight trajectories to further determine:
IPv6 address
↓
a specific aircraft
↓
an airline
↓
a specific flight
The paper calls this Starlink aviation measurement technique “outside-in”: instead of measuring from inside the aircraft toward the Internet, measurements are performed from Internet-connected ground nodes toward the aircraft.
Most previous research has used an “inside-out” approach, in which researchers or users must actually board a Starlink-equipped aircraft and measure and record Starlink performance through the in-flight Wi-Fi network. There are also several crowdsourced datasets containing Starlink in-flight performance measurements reported by passengers via this “inside-out” way.
The paper also cross-validates the “outside-in” approach against established and reliable traditional “inside-out” measurements, demonstrating the effectiveness and accuracy of the outside-in method.
There is little doubt that the publication of this technique could spark considerable interest among researchers worldwide—and perhaps among hackers as well. It may lead to a chain of follow-up developments. How long this “outside-in” research window will remain open remains to be seen.
]]>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
]]>