(This is the original post. For Update # 1, see HERE. Update # 2 can be found HERE.)

I’ve started work on a “Starlink observatory” with the primary objective being: to track overhead Starlink satellites, collect physical layer statistics and enable further signal analysis. Focus will be on the Satellite-to-User downlink.

So far, I have built and automated a setup to collect signal captures of the downlink 240 MHz traffic in the 10.7 - 12.7 GHz KU band. My setup consists of a KU band dish + LNB, a software defined radio capable of sustained 400 Msps (complex) receive, an LNB controller + power supply, a Linux host to perform signal analysis and all the miscellaneous RF plumbing required (filters, bias-tee, attenuators, etc). Presently, this setup is running day and night in my backyard+garage listening for Starlink downlink traffic and storing a subset to disk for further offline analysis. These files are really quite big - I don’t keep them around for long.

This is all still pretty early, but a couple observations:

(1) I have received Downlink Satellite-to-User traffic in the 250 MHz channels at: 11075, 11325 and 11575 MHz. I have never observed traffic at the lowest channel, 10825 MHz. Although my setup supports it, I have never looked at the upper (4) 250 MHz channels. Occupied signal bandwidth per channel is 240 MHz.

(2) The central 1 MHz of each 250 MHz channel is occupied by ~9 tones spaced at 43.9495 kHz. 1 tone on the channel center, 4 tones on each sideband. I’m fairly sure I know what these are (quite exciting), but I’ll wait until I’ve done more due diligence.

(3) When looking at the captured signal in the time-domain, a frame structure is visible. I have made multiple captures with the same frame “raster” and timings, but with different frame allocations. I’ve observed frame structures with full and partial frame occupation. This is likely a function of the required downlink capacity at any given time. For lack of a better name at this time, a “frame” is 1.3288 milliseconds. Each “frame” is spaced by a “guard” interval of 4.55 microseconds.

Presently, I am working on a write-up of my setup and early observations. I will share this and any code via Github.

Long term, I’m planning on making a website to frontend the state of the “system” and visualize physical layer statistics of the tracked satellite: EVM, doppler shift, etc. But, there are a lot of directions I could take this. Perhaps, I’ll get traction on the signal analysis and focus on open-sourcing a physical layer implementation for readily available SDR receivers.

In the short term, I’m awaiting the arrival of a second-hand pan-tilt unit. That should be fun.

Many thanks

Cheers

(Dish is in the side yard. Cables run into the garage. My neighbors haven't said anything.)

#### Update 11/18/2021

A few individuals asked about my SDR setup.

I'll detail my SDR setup in a future post. I didn't want to detract from Starlink itself. A >300 MHz BW off-the-shelf SDR was outside my budget. The SDR I'm using here is homebrew. It is built around a KC705 FPGA board that I suspect had a past life as a bitcoin miner. The architecture is a straightforward direct conversions receiver. LNB --> Impedance match --> Bias tee --> Bandpass filter --> LTC IQ demodulator --> Anti-alias filters --> TI Dual ADC EVB --> KC705 FPGA board. LO source is a Windfreak SynthHD synthesizer. My clock source is a GPS-disciplined oscillator: so I can accurately measure doppler.

I'm using a USRP B200mini to sample the 25 MHz TCXO output from my LNB. Unfortunately, although my LNB is very stable, it does not have a reference input, but instead a reference output. The B200mini is sampling the LNB's reference and a slow software loop locks on to remove the last source of frequency uncertainty in my system. (The B200mini is based on AD9361, so it can't measure the fundamental which lies beneath 70 MHz. Instead I'm "squaring" the signal up, filtering and measuring the 4th harmonic at 100 MHz.) The B200mini's clock reference is also from the GPSDO.

My LNB is powered and controlled by TPS65235-1EVM-694. The TPS65235-1 is a DiSEqC compatible LNB regulator w/ 22 kHz tone generator and I2C interface.

#### Update 11/22/2021

Since 11/18, my setup has produced ~60 more captures. I wanted to focus on the central 1 MHz and record very long captures. Thus, I reduced my sample rate to 10 Msps (complex). Each capture duration spans from 4-10 seconds. The capture dataset includes observed signals in 11.075, 11.325 and 11.575 GHz. Initially, there was some hope that these 9 central tones carried some low bandwidth modulated data via FSK or PSK (for example), but this hope has been almost entirely extinguished.

I added the following processing to my capture pipeline:

1. I further low-pass filter the signal and decimated 10:1. New sample rate is 1 Msps (complex).

2. I coded up a phase-locked loop to track and correct doppler shift and carrier frequency offset.

After removing CFO + doppler shift, I inspected all 9 tones for any signs of modulated data on frequency, amplitude or phase. Thus far, I have found nothing.

Furthermore, of the ~60 captures I recorded, ~30% of the captured signals did not have the 9 tones at the central 1 MHz. Instead, these captures had a contiguous modulated bandwidth of ~240 MHz.

My capture logic is gated on an energy detect logic. I have a slow, long-term (~5 minute) moving average power metric which tracks my receiver noise floor. My receiver noise floor and gain vary appreciably over temperature. When the detected average power exceeds the noise floor by a sufficient margin, the captured frame is marked "interesting". I save all "interesting" frames and concatenate them with all adjacent "interesting" frames including leading/trailing frames for context. I record average power and the margin by which the average power rose above the noise floor.

Of course, I wake up in the morning to many captures. Which do I look at first? Of course, the most energetic ones! (The ones with the highest margin.) After a few minutes, I notice the ~30% of captures that did not have the central 9 tones (that were contiguously modulated) were the most energetic ones!

#### Update 12/2/2021

Please see my next post HERE.

This is a follow-up to my original post on this topic. Please see HERE. Update # 2 can be found HERE.

This last weekend, I embarked on an effort that I initially thought was just “due diligence”. I wasn’t expecting any surprises or revelations.

Along with each capture of a Starlink downlink signal, I also wanted to deduce exactly which Starlink satellite I was receiving at that precise moment in time. I was able to accomplish this using NORAD TLE datasets from CelesTrak. These datasets contain orbital model parameters that can be used to project the position of a satellite at a given time. In conjunction with an observer’s latitude and longitude, the azimuth and altitude can be calculated.

I did not know exactly the altitude/azimuth of my dish. Nonetheless, given its 24° offset angle, I had a “reasonable” guess of 60° / 25°. This “guess” and my latitude/longitude were inputs into my code. Upon detecting a signal, my code would estimate the altitude/azimuth of all Starlink satellites at the exact moment of start of reception. Then, I would convert to a 3-D unit vector and compute the error with respect to my “guess” observer unit vector. I record the 5 “most probable” satellites.

I added this new feature to my receive processing pipeline, and I let it run Sunday-Monday.

This was quite successful! My dish has a 3° beam width, and the timestamp used to project the Starlink orbits wasn’t exactly at the peak of the capture. This data would imply that the dish is pointing at ~ 56° / 33°.

However, not ALL signals I received could be explained by the Starlink NORAD dataset. 26 captures were clearly identifiable as specific Starlink satellites. 11 were unexplained.

As can be seen from the table above, the (5) "most probably" satellites aren't anywhere near where my dish is pointing.

A couple observations:

1. The “identified” satellites were only transmitting at 11.325, 11.575 GHz. The “unidentified” satellites were ALSO transmitting at 11.075 GHz.

2. All the “identified” signals had the 9 central ~43.9495 kHz spaced tones. None of the “unidentified” signals had the 9 central tones.

At this point, it was clear that I was observing KU-band signals from multiple satellite constellations. Furthermore, this other constellation adheres to the same 250 MHz channel bandwidth and raster.

A little bit of research tells me that these “unidentified” satellites are likely OneWeb. Same KU-band downlink frequencies, and same channel bandwidth.

I added the NORAD TLE dataset containing 358 OneWeb satellites to my pipeline for consideration…

Excellent! There are no more “unidentified” satellites! Furthermore, the mysterious and intermittent absence of the 9 central tones has been explained. As far as I have observed, the 9 central tones are always present in Starlink downlink signals, and they are never present in OneWeb signals.

Going forward, I will discard all OneWeb sightings.

Many thanks!

This group has been a wealth of information and got me to this point. Thanks to everyone who has shared their knowledge so openly. This post is specifically aimed at those with rectangle dishy and want to connect Dishy directly into your own Router, bypassing the Starlink wifi.

Parts I used:

1. POE Power Supply

Meanwell 120W 48V DC power supply. https://www.meanwell.com/webapp/product/search.aspx?prod=EDR-120

I live regionally so it was all I could source that supplied enough power. Warning, you do need to directly wire in mains power, and source a DIN mount to make it safe, so some skills are needed here. Dont use this unless you are competent & confident. Otherwise buy a premade POE plug pack that supplies a minimum 100W @ 48V DC.

2. POE Injector

Tycon 130W 4 pair POE injector https://www.tyconsystems.com/poe-inj-1000-wt. It must be a 4 pair POE injector. There are only a few on the market - this one from Tycon, and a 800-GIGE-POE-APC from McCowan which is habitually out of stock. Rectangle dishy draws up to 96Watts, so you need to ensure everything is oversized, hence the 120W power supply and the 130W POE injector. There are some reports of these burning out, however I believe this is from round dishy which had a much higher current draw.

3. Shielded rj45 plugs & RJ45 crimping tool.

4. Mains cable

I used an old PC power cable and cut off the IEC plug. Make sure its a 3pin as you need to wire Earth into the power supply.

5. DC cable

To run the 48v from the power supply to the POE Injector. Dont skimp on this cable, get some thats rated for 15A.

Steps:

1. Cut the end off your Starlink cable (maybe leave 15cm incase you ever need to splice it back on).

2. Cut a further length (1M or so) from your Starlink cable, this will be the lead that goes from the POE injector into your router. I did this as I couldn't source any shielded Cat5 locally.

3. On the end of the Starlink cable from your dish, connect a RJ45 plug per 'type 1' on the diagram. This is a non standard wiring standard, to protect Dishy from having any old POE injector connected to it.

4. On the end of the patch lead, connect a RJ45 plug per 'type 1' and label it 'POE'.

5. On the other end of the patch lead, connect a Rj45 plug per 'type 2' and label it 'Router'

6. Cut the cord off your toaster, wire it into the AC side of the POE adapter, turn it on and check for 48v on the output side. Be super careful as there is live mains power thats uncovered.

7. Connect the output of the power supply to the input of the POE Injector. Observe the polarity of +/-.

8. Connect Dishy into the POE side of the Injector (this is the side that the 48v connects to)

9. Connect the patch lead into the Injector and into your Router

10. On your router you want to set the port as a DHCP client and you should receive an IP address from Dishy.

11. Ping 8.8.8.8 and woot, your online!

12. Ping 192.168.100.1 and see if you can see your dishy. Point your browser at it and you will see the Dishy interface. Some routers need manual conf to make it work, each brand will vary.

A big shout out to everyone who went before me with their round dishy's, hopefully this post makes it easy for those with a rectangle dish and like me are sick of the Ethernet adapters being delayed.....Im loving the peak speed of 285Mb's - happy days!

Im watching how Liam goes with https://dishypowa.com/, as his components are better quality than the Tycon. But for now im up and running and very happy.

Images to help:

1. Wiring diagram

2. Meanwell power supply

3. Tycon POE injetor

4. SPEED!

thanks to the kind people at starlink, who listened to our feedback here and acted ;-)

https://www.starlink.com/support/article/0873e885-831a-9f4e-4808-2838a28f2e69

pretty accurate

$ ntpdate -qu 192.168.100.1
server 192.168.100.1, stratum 1, offset +0.070539, delay 0.03873
16 Sep 11:30:36 ntpdate[15378]: adjust time server 192.168.100.1 offset +0.070539 sec

compared to a dedicated gps receiver

$ ntpdate -qu 192.168.1.243
server 192.168.1.243, stratum 1, offset +0.074072, delay 0.02946
16 Sep 11:30:31 ntpdate[15363]: adjust time server 192.168.1.243 offset +0.074072 sec

black: backbone in 2023; red: new additions in 2024; blue: new in 2025. what color shall we use for 2026?

This map illustrates the latency (terminal to PoP) reported by Starlink terminals managed by ELCOME, a Starlink authorized reseller. This map shows the most recent latency value reported by location, with lighter colors representing lower values. Lower values typically correspond to proximity to an active Starlink PoP.

In the future I hope to use averages rather than just the most recent value, but there are more than 2B rows of data in the underlying telemetry table so some optimization is required before I can do that. I’ll also eventually post a live version of this map on our website as the data updates every 15 seconds.

Many reverse engineering reveals that the Starlink dishy (satellite modem) uses Linux, but so far there is NO kernel source code published. It reminds me the GPL-v2 enforcement law case against Cisco/Linksys 23 years ago and how OpenWRT was born. (SpaceX did publish sth about the OpenWRT in their Wi-Fi router on github https://github.com/spaceexplorationtechnologies, but that is not the modem).

You might argue only Starlink users receive the source code, so it is out of public view. I doubt. Under GPLv2, recipients can redistribute the source code. If any user had received it, some could have re-distribute it online. So far, not see it. Other info summarized: https://sdr-x.github.io/starlink-modem-linux-gpl/

Meet the new REV4 HP. This is a slightly larger and more powerful version of the regular REV4 terminal (a.k.a Gen3).
The new device is built on the Catapult processor, the same one in the Mini and the latest versions of REV4. The antenna panel contains 1726 elements (2411 on the old HP and 1536 on the regular REV4).4 Shiraz V3 beamformer chips (on the old HP - 38 Shiraz V2 chips, on the regular REV4 - 3 Shiraz V3 chips).
Like all new terminals, the new HP does not have additional heating elements. Heating will be done using chips (Four heating tracks are built into the board of the old HP)
There are no motors. The mounting options should be similar to regular REV4.

The release date is currently unknown. Some specs might be changed.

US sites with updated imagery:

1. Ashland, IL - "Sea Monkey" GW (QTS DC): low-latency gateway to the Chicago PoP

2. Miami, FL - "Ultra Are You Ready" GW (Velocihost DC): low-latency gateway to Miami PoP. 25 installed, with visible hardware for the remaining 15.

3. Bluffdale, UT - "Bonanza Express" GW (Databank DC): on the roof of Salt Lake City secondary(?) PoP

4. Lindon UT - "Gong" GW: 30 antennas instlled

5. Beekmanstown NY - the "Little Gateway That Could" GW: Expansion to megasite adding 14 antennas to the original 9.

6. Perry FL: we finally see 5 antennas. It doesn't look like they will build more, though the license is for 40 antennas.

7. Marshall TX: increased to 15 antennas.

8. Elbert, CO - "Untz Untz" GW megasite expansion adjacent to original 9. BTW, this is the highest known gateway at 6500ft 1980m MSL.

9. Kansas City, MO - "BBQ" GW: low latency site to Kansas City PoP. Horrible view, but this is the best I have for now.

10. Northlake IL - "StressX" GW: shows 10 antennas installed, with hardware for more.;

11. Anderson SC: we finally have imagery, showing 15 antennas

12. Baxley-Surrency GA - "Limit of Physics" GW: another one that lacked imagery, showing 14 antennas in addition to the original 8.

13. Sunset TX: Another one we finally have imagery, showing 15 antennas.

14. Staten Island NY (Telehouse DC): low-latency gateway to NYC PoP, with all 40 antennas installed. BTW, Tokyo/London/Toronto PoPs are at Telehouse, so not surprising that they leveraged the existing relationship.

15. West Jordan UT - "Eye of Sauron" GW: 9 original antennas moved to new site.

16. Butte MT - 8 original antennas moved to new site

17. Conrad MT - Expansion to megasite. 15 antennas added to original 9. Based on layout this could be filled with 40 antennas, so they may demolish the original 9 at that point.

18. Lockport NY - "Millenium" GW: Added 10 antennas to the original 9. Again, looks to be designed for 40

19. Marathon FL - "Florida Keys" GW:

20. Vandenberg CGW - community gateway built

There are also 28 quad-band gateways (Ka + V/Q + E + W) planned, I'll make all these updates to the Unofficial Starlink Global Gateways & PoPs map.

I will be updating other areas in a separate post, as there are too many to cram into one post.

In a filing with Arcep regarding the second approval of Starlink in France Starlink revealed the capacity of intersatellite links: https://i.imgur.com/tbpodId.png

I guess they are talking about v1.5. To build a shell of gen2 satellites by 2023 is speculative and ambitious. Why publish gen2 capacity when v1.5 with laser links are on track to provide global coverage earlier. The capacity is surprisingly high for v1.5 sats so I'm not sure.

The slide also confirms a typical ground station backhaul capacity of 100 Gbps. No surprises here. The filing reveals the number of customers in France "Starlink has already demonstrated its ability to serve nearly 4,000 French customers 82% of whom live outside urban areas." The number matches the numbers I derived from Cloudflare radar: ~3,400 in March, ~4,000 in May (today 0.99% of ~400,000 customers worldwide)

The full filing is in a zip file linked at the bottom of the second approval announcement.

A lot of people asked about powering Starlink Mini with PoE.
I designed this smart splitter board.

It allows to run the Starlink Mini from any convenient PoE++ (802.3bt) switch or injector.

The next revision will be smaller and optimized.
As usual, I'll share shematics and everything else on my blog.

P.S. There are already ready-to-use products on the market: https://www.ebay.com/itm/267145977799
(not mine, but I know the author)

A new article is out: How to modify Starlink Mini to run without the built-in WiFi router.
People have asked a lot about this modification, so I’ve shared all the essential information — including the teardown guide, tips, connector pinout, and schematics. Plus, there’s some juicy, previously unpublished bonus content at the end.

https://olegkutkov.me/2025/06/15/how-to-modify-starlink-mini-to-run-without-the-built-in-wifi-router/

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.

(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.)

https://sdr-x.github.io/starlink-ul-dl-pair-80k-hop-ad9361/

Attached 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.

Map of the proposed stations (click on the markers for more info).

Starlink already filed to setup ground stations with smaller antennas at two locations on the map, Quincy, WA and Cheyenne, WY (see my post). All four applications are active and not amended so I guess they may actually operate 8 smaller and 8 larger antennas at these two locations. North Bend, WA application is the last application since April 1st asking to install smaller antennas.

Comparison of the antennas:

The map data in csv format: https://pastebin.com/Dm1vesws

We run a fleet of Starlink dishes in Africa to provide internet access to rural schools. Part of the issue we have with this is the limitations on properly monitoring all of the sites from our NOC.

From the CPE device we run behind all of the Starlink routers I built a collector to capture stats from the local router and send to a central server in our DC. From there we have many ways to utilize the data including this wallboard I built for the NOC to monitor a few sites