In the previous post, I had a look at the 5 GHz Wi-Fi of the Starlink router at close range for maximum throughput. In this post, I’ll have a look at the completely opposite scenario: How Starlink’s Wi-Fi performs when used to bridge a larger distance. This wasn’t actually a theoretical test, but the scenario I bought my Starlink terminal in the first place: Fast Internet connectivity in ‘underserved’ places. As you can see in the picture above, I put the satellite antenna itself in a courtyard, while the router and the 230V power supply (more about that in a follow up post) was in the car next to it.
A Samsung S22 at the window for in-house distribution
I estimate the distance to the router to be about 30 meters, give or take a bit. To make the scenario more challenging, both the Starlink Router and the Wi-Fi client device were behind glass windows. On the client side, I used a Samsung S22 smartphone and Wi-Fi tethering at first, which delivered around 30 Mbps in the downlink direction and around 15 Mbps in the uplink direction to a notebook when running iperf3 throughput tests. Between the Starlink router and the S22, the two devices chose to use the 2.4 GHz band, the 5 GHz band was too weak to be useful. However, since I set the S22 to use the 5 GHz band for Wi-Fi tethering, the in-house tethering part to my notebook was done over the 5 GHz band. I would not have expected that a smartphone could have two Wi-Fi’s active at the same time, so I was positively surprised.
A Linksys Router at the Window for in-house distribution
A smartphone might not be the ideal device for long range Wi-Fi connections, I took a full grown Linksys 1200 AC Wi-Fi router with me. As I ran the Linux based OpenWRT OS on the Linksys, I could configure it to my heart’s desire and open a remote SSH shell to get to more detailed link status information. Even with bigger antennas, however, I couldn’t use the 5 GHz channel to connect to the Starlink router. So I configured the Linksys router as a client for the Starlink router on the 2.4 GHz band. Like with the S22, I then chose the 5 GHz band for in-house distribution. With this setup, I could get speeds between 35 and 50 Mbps in the downlink direction and 15 to 20 Mbps in the uplink direction. A bit more, but actually not that much more, at least not at close range.
Where is the Bottleneck?
While those speeds were not bad at all given the circumstances, Starlink can deliver much higher speeds. And indeed, when connecting to Starlink’s own Wi-Fi at close range, I could get well over 130 Mbps. Therefore, the bottleneck must have been somewhere else. I then ran an iperf3 downlink test between the Linksys router and the Starlink terminal, and could reach the same speeds as before. In other words: The bottleneck was the 2.4 GHz connection to the Starlink router. Next, I had a look at the parameters announced in Starlink’s beacon frames for the 2.4 GHz band:
TSF: 9978354977 usec (0d, 02:46:18)
freq: 2412
beacon interval: 100 TUs
capability: ESS (0x1431)
signal: -72.00 dBm
last seen: 200 ms ago
Information elements from Probe Response frame:
SSID: xyzabc
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
HT capabilities:
Capabilities: 0x1ad
RX LDPC
HT20
SM Power Save disabled
RX HT20 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT RX MCS rate indexes supported: 0-23
HT TX MCS rate indexes are undefined
HT operation:
* primary channel: 1
* secondary channel offset: no secondary
* STA channel width: 20 MHz
VHT capabilities:
VHT Capabilities (0x33c279b1):
Max MPDU length: 7991
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
SU Beamformer
SU Beamformee
+HTC-VHT
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-8
2 streams: MCS 0-8
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 260 Mbps
VHT TX MCS set:
1 streams: MCS 0-8
2 streams: MCS 0-8
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 260 Mbps
VHT operation:
* channel width: 0 (20 or 40 MHz)
* center freq segment 1: 0
* center freq segment 2: 0
* VHT basic MCS set: 0xffe5There are a number of interesting things in here: As already established in the previous post, the current Starlink router is based on a Wi-Fi 5 (802.11ac) chipset. While that’s not so much of an issue for the 5 GHz band, it’s not ideal for the 2.4 GHz frequency band, as 802.11ac was only specified for the 5 GHz band. Well, at least theoretically. That means that the older 802.11n standard has be used in the 2.4 GHz band, which has a very limited feature set. Here’s a dump of the connection details between the Linksys and the Starlink router on the 2.4 GHz channel, taken on the Linksys router:
root@Linksys-1:~# iw wlan1 station dump
Station 00:00:00:00:00:00 (on wlan1)
inactive time: 10 ms
rx bytes: 2215416139
rx packets: 1600475
tx bytes: 640216467
tx packets: 917347
tx retries: 0
tx failed: 0
beacon loss: 0
beacon rx: 21799
rx drop misc: 81
signal: -70 dBm
signal avg: -69 dBm
beacon signal avg: -70 dBm
tx bitrate: 39.0 MBit/s MCS 10
rx bitrate: 86.7 MBit/s MCS 12 short GI
rx duration: 0 us
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 1
beacon interval:100
short preamble: yes
short slot time:yes
connected time: 2442 seconds
When transferring data over the 30m distance and through 2 glass windows, Modulation and Coding Scheme (MCS) 12 was used most of the time (16-QAM, 2 MIMO streams, 3/4 coding) with a maximum data throughput of 86.7 Mbps on the physical layer. That’s around 60-70 Mbps at most on the IP layer. With a stronger signal, MCS 15 with 64-QAM could have been used over 2 streams, with a maximum throughput on the physical layer of 144 Mbps. Almost twice, but still not enough for Starlink.
In addition, the Starlink router only supports a 20 MHz channel on the 2.4 GHz band. That’s a bit of a shame, a 40 MHz channel, despite the rather bad signal conditions might have improved the throughput. Again, I’ll chase up this thought in a follow up post. Also, it looks like Starlink might launch a new router with 802.11ax support soon, which might just do that. Have a look here for details. On the other hand, I can understand Starlink’s decision to use the 2.4 GHz band for maximum range rather than to optimize throughput.
VHT on 2.4 GHz!? How Strange!
There is one other noteworthy point in information contained in the beacon frame caught on the 2.4 GHz channel: There’s a VHT section! VHT stands for ‘Very High Throughput’ and is part of the 802.11ac (Wi-Fi 5) standard. As mentioned above, it’s not standardized for the 2.4 GHz range. So what does this do in here? A online search revealed that there seem to be proprietary extensions of the standard to allow the use of 802.11ac modulation and coding in 802.11n on the 2.4 GHz band. And indeed, when checking the MCS information during data transmission, I could detect the use of VHT MCS’es every now and then. How interesting!
Opening a Window
In a final step, I opened the window to see how this would change the data rate of downlink transmissions. And indeed, I could immediately get downlink speeds of around 60 Mbps. So, yes, glass windows are quite a data blocker I’m afraid.
Summary
Overall, I’m very happy with the result achieved over the weekend and I learnt a great deal while using Starlink in an ‘underserved’ area. I wished the 2.4 GHz Wi-Fi link had performed a bit better, but the transmission was clearly power limited and hence, I’m not sure how a 40 MHz channel or 802.11ax support on 2.4 GHz would have helped.