In this article, I would like to discuss Starlink GPS implementation, potential problems, and ways to improve.
Let’s agree that the paper will focus on GNSS in general, but for convenience, I will call it GPS.
Why does Starlink need GPS?
To successfully communicate with satellites, the Starlink terminal requires the position of each satellite with the ability to predict this position. The Starlink antenna is not moving much but uses a phased array to steer a narrow RF beam electronically and point to the required satellite in the sky.
It’s relatively easy to calculate a given satellite position with TLE data. You only need the latest TLE data, station coordinates, and precise time. And that’s where GPS comes into play.
Starlink uses a built-in GPS receiver as a source of coordinates and time to calculate the position of the satellites in the sky. Also, GPS provides a stable time pulse (1PPS) to discipline clocks. The correct clock is crucial since Starlink uses time-division access and provides a schedule for all terminals in a given cell.
After turning on and booting, the Starlink terminal starts the “sky search” procedure. Basically, it scans the whole sky, looking for familiar signal bursts. Then, after successful network entry, Starlink can download the latest TLE from the “constellation” data server (which is unavailable on the internet). From this moment, it’s possible to calculate the precise position of all Starlink satellites and support stable sessions based on the network schedule.
Thus, Starlink should acquire GPS position and time (GPS fix) before the “sky search” procedure. If the fix is not available, Starlink will stuck in the “booting” state.
This state is somehow misleading. The Starlink terminal is fully booted but stuck on some top-level initialization procedure. It might be a lack of the GPS Fix or some problem with the antenna array (failed self-calibration). Always check “debug data” to find what’s gone wrong.
Starlink without GPS
It’s not a secret that the Starlink constellation could be used for navigation. Starlink terminal can be switched from using GPS data to its constellation data. There is a special switch in the Starlink mobile app.
This option is super helpful when you don’t have a stable GPS reception or GPS data is not trustworthy. Civilian GPS is vulnerable and could be jammed or spoofed in some locations. Or the GPS receiver could be broken. Using Starlink constellation allows using Starlink in such conditions.
But everything comes with a cost. Calculating position based on Starlink constellation requires more resources, and it’s not so fast. Plus, It can’t be used correctly in motion. Accumulated errors may be so significant that Starlink will not be able to work.
Starlink GPS implementation
All versions of the Starlink terminal use an automotive-grade Teseo GNSS receiver from the ST.
This is a multisystem GPS/Galileo/GLONASS/BeiDou/QZSS receiver. It’s pretty reliable and feature-packed. But of course, it’s jammable, plus it’s relatively easy to damage built-in LNA with a strong enough RF signal. So, never try to radiate your Starlink terminal from a short distance with a GPS jammer/spoofer.
Both ICs have a similar NMEA interface and could be configured to provide specific data for different GNSS constellation usage. In this article, I will not share the exact configuration Starlink uses.
Antennas also differ. Some users noticed that round UTs (rev1 and rev2) are getting GPS faster, even in bad conditions. This is not surprising.
Round Starlink terminal (rev1 and rev2) was much bigger with plenty of space. Thus, there, we can see a quarter wavelength patch antenna. The gain is unknown.
On the most common square terminal (rev3), SpaceX switched to a compact ceramic chip antenna. There are two known versions of this antenna.
This is a low-gain (~3 dB) omnidirectional antenna. They don’t have a lot of free space on the rev3 PCB, so I guess this cheap antenna was the best choice. It works in most cases.
The main problem with the Starlink GPS antenna is not the low gain but the radiation pattern that allows this antenna to “hear” everything: satellites in the sky and possible jamming/spoofing sources nearby.
Also, both antennas are linearly polarized, but GNSS signals are circularly polarized. Thus, the Starlink antenna loses some fraction of the useful signal. At the same time, it might be more sensitive to a jam signal that propagates in the same polarization plane.
Typically, this leads to a forever “booting” state or damaging the STA8089 IC in the worst-case scenario.
Fortunately, many issues could be fixed with a proper external GPS antenna or even a CRPA antenna (if there are some special requirements).
It’s possible to connect both passive and active patch-antenna. Circular polarized directional patch Antenna could provide better protection from jamming signals and faster GPS lock. In the case of jamming protection, I mean sources that are placed somewhere far from the main lobe of the antenna. Actual sidelobe suppression depends on antenna type. As an example, I will use the rev3_prot2 user terminal.
The external antenna cable could be connected directly to the Starlink PCB instead of the chip antenna. There is a convenient 50-ohm feed line.
First, remove the chip antenna. Second, solder coaxial cable directly to the PCB. It’s convenient to solder cable shielding to the bottom ground pin.
Please try to secure the cable somehow to avoid the pads ripping off.
The cable could be connected directly to a passive external antenna or to Bias-T to power an active antenna. It’s possible to use Bias-T with the passive antenna. Just be careful and don’t short it to the ground.
It’s convenient to get 3.3 volts from the Dishy PCB. There is a voltage regulator nearby. It’s capable of providing enough power for one more little device.
I used a popular and cheap Bias-T module. It’s good enough and works nicely on 1575 MHz. It’s possible to glue this module directly to the Dishy heatsink. The position was adjusted, so it’s still possible to install a back cover of the user terminal. Sitting on the top side, this module doesn’t affect the heatsink performance much.
In this design, an additional water-proof SMA connecter was mounted to the backside. This allows easy disconnect and swaps of GPS antennas.
I run tests with three GPS antennas. Numbers 2 and 3 are very similar inside. Test conditions were intentionally non-optimal, with a partially blocked sky.
Here are the results in comparison to the standard chip antenna:
|Antenna||Uptime to GPS Fix||Number of satellites||GPS valid (sky search started)|
|Built-in chip||3 minutes||5||Yes|
As you can see, all external active antennas provide faster startup time and more satellites, which might be important in some cases.
My friends helped to test this modification in the area with constant suppression of the GPS bands. Thanks, Team 14 😉
In addition to signal suppression, the test site wasn’t optimal with additional obstacles.
Two devices took part in the testing: an unmodified one and one with an external active antenna. The results are below.
|User terminal type||Uptime||Number of satellites||Online|
|Modified, active GPS antnenna||2 minutes||13||Yes|
|Modified, active GPS antnenna||5 minutes||17||Yes|
|Modified, active GPS antnenna||30 minutes||15||Yes|
Additionally, it’s possible to integrate a small passive patch antenna into Dishy in the case of custom (automotive) housing.
This antenna has a relatively small gain, but it still provides good enough amplification and directivity.
It looks scary, but it’s safe to cut PCB here to fit the antenna carefully.
Result – 11 satellites and Online in less than a minute:
Thanks for reading!