# How to design a ground antenna for sending & receiving from a satellite?

Let's suppose there is a wifi router or a cell phone or similar transmitter in an orbit of 3000 km.

How could one make a dish antenna to connect and receive the signal from that wifi router or cell phone or signal transmitting device?

• What all do you mean by "signal transmitting device"? That could cover almost anything. – Nathan Tuggy Jan 7 '18 at 14:18
• 3000 km? I suspect wifi and cell links will fail over that distance because they're not designed for that. You'll get timeouts because the router expects the receiver to be no more than a few km away. – Hobbes Jan 7 '18 at 14:39
• What you need, by the way, is a link budget. You have to know the transmitter power, receiver sensitivity and distance, then you can calculate the antenna size. en.wikipedia.org/wiki/Link_budget – Hobbes Jan 7 '18 at 17:12
• Besides the link budget information about the noise is important. The possible bandwith depends on signal to noise ratio. The acheivable bandwith might be too small for a wifi or cell phone connection. But the delay caused by the huge distance will be too high for a lot of transmission protocols designed for short distances. – Uwe Jan 7 '18 at 17:48
• You are free to your opinion. I am free to mine. Please stop raising arguments any time someone decides to use their vote to close. – Rory Alsop Jan 8 '18 at 11:22

This is an interesting question! There are (at least) two communications issues to consider. One is signal strength as the question asks about, the other is latency or delay. But the tl;dr is that this won't work using standard WiFi or cellular data equipment because the antenna would have to be kilometer sized, and the delays are incompatible with the protocols.

A link budget calculation (which you can see in this answer) would show that a smaller ground-based antenna would work, but you would still have to modify the protocol to deal with low data rates and long latency, and that means specialized hardware in your satellite and ground station rather than COTS WiFi or cellular.

## Signal Strength

A very quick way to roughly estimate the size of the collecting area needed would be to take simple ratios. Let's choose 2 GHz as an approximate working frequency. The corresponding wavelength from $\lambda = c/f$ is 3E+08 m s^-1 / 2E+09 s^-1 or 15 centimeters. A WiFi dipole antenna can be assumed to have an effective receiving area of roughly 1 wavelength squared, or 0.02 m^2, and a cell phone tower antenna about 1 x 10 wavelengths or 0.2 m^2.

Let's say for rough, round numbers that normal WiFi range in free space (no obstructions) is 100 meters, and useful, high speed cellular data range is 3 km. Cell phones may be able to receive data out to 30 km, but for transmitting high speed data the range will be less.

Your distance is 3,000 km. Since signal drops as $1/r^2$ those require antenna areas that are increased by factors of 10^9 and 10^6 respectively. That means ground antennas with an area of 2E+07 and 2E+05 m^2, or sizes of 4 km and 400 meters, respectively.

These are huge! In other words, if you keep everything about the equipment the same, and try to tackle the large distance by simply scaling the Earth-based antenna size, it's not going to work. The Square Kilometer Array is an example of a project where the total area of all the antennas together is roughly 1km x 1km, and that's a world-class project.

The largest dish used in the Deep Space Network system is only 70 meters in diameter, and yet it can communicate to distances of billions of kilometers. Why? The data rates at these distances are far, far slower than the minimum data rates for standard, commercial WiFi or cellular data. They use special protocols to beat the weak signals and large noise at these distances. In fact, you can trace the development of some commercial wireless data protocols directly from deep space communications technology by people who worked at CSIRO. See [WiFi History].6 They also use shorter wavelengths (improving gain) and cryogenic (cooled) receiver front ends to go deeper into the noise.

## Latency

The way commercial cell phone voice and data channels and WiFi router communications work normally, they need to establish two way communications first before they start sending data. At large distances, the time delay due to the finite speed of light will confuse commercial WiFi and cellular data communications. For example, GSM has a hard cut off at 35 km due to the maximum time-shifting allowed in the protocol. At 3,000 km the delay is TEN milliseconds, and for high-speed data, that's forever!

• It is possible to transport high speed data over larger distances than 3000 km using a suitable transmission protocol. The TAT-14 transatlantic cable has a total length of more than 15000 km and a capacity of more than 3 Tbit/s. But this speed is only possible using a lot of signal repeaters within the cable. But the delay is well over 10 ms. – Uwe Jan 8 '18 at 22:01
• @Uwe the question is about a WiFi router or cellular phone - standard commercial equipment, not about custom equipment built for long distance communication. – uhoh Jan 8 '18 at 23:56
• another factor that helps the DSN is that there are good antennas on both sides. A 3.6m dish on the satellite gives ~40 dB of gain over a wifi dipole. – Hobbes Jan 11 '18 at 10:16
• @Hobbes that's mathematically correct, but only if the spacecraft's on-board ADCS can reliably point that dish at the Earth station and slew it with +/-0.5°accuracy as it moves over the Earth's surface, and at that point the level of sophistication of the system is not really consistent with using a WiFi router or cell phone as the communications system. – uhoh Jan 11 '18 at 16:43

TL;DR: It should be possible to create a reliable connection between a ground station and a satellite in theory, given all assumptions in this post. However practically the fact that LEO satellites are moving quite quickly, and the need to track these with a motorised antenna, which means that there will be "gaps" in the link, when the antenna need to reposition to the next satellite.

As you specify "Wifi" or "GSM" in your question, lets assume you mean to have an application for the "consumer market"... e.g. "Internet over Satellite"

So we want to "exchange" digitalised information, and in order to do that we can use a conceptual model such as the 7 layers of the OSI model

We would be particular interested in Layers 1 thru 3, the so called "Media Layers".

• Layer-1 : Physical Layer -- This is where bits are transferred
• Layer-2 : Data Link Layer -- This is where frames are transferred
• Layer-3 : Network Layer -- This is where packets are transferred

Multiple bits make a frame, one or more frames make a packet

Now lets start breaking this down relevant to your question. I am going to jump around in those layers.

Layer-3

Layer-3 in this case is very simple, and for Internet connectivity, this is where IP (Internet Protocol) lives. IP is the part of the well known term TCP/IP, however technically speaking the TCP part is a Layer-4 protocol. We are concentrating on IP, Layer-3. And with that, lets concentrate for this example on IPv4

The biggest concern for long-distance communication is the restriction within the protocol specification in regards to latency and timeouts.

For IPv4 there is not timeout defined for the protocol, but in the dataframe header there is a TTL (Time to Live) field at offset 8, bits 0-7.

This field is a "seconds decreasing counter" and therefore we have a maximum of 255 seconds for the dataframe to live. Practically this counter is decreased everytime the dataframe "hits" a "router" and subsecond times are rounded to a second, so it decreases more rapidly than 255 seconds.

Eitherway; for choosing IPv4 as our layer-3 protocol, we can safely conclude that this protocol is robust enough for the distance we need to bridge. Proof of this is the current internet. We all work with servers around the world with 1-500ms of latency without any problems. In fact this very post you are reading is likely to be served to you from quite some distance.

Conclusion for Layer-3: by choosing the right protocol we can reliably bridge the distance from ground to LEO satellite, example protocol would be IPv4.

Great, so no problems on our Layer-3 if we choose IPv4. Lets look at another layer:

Layer-1

OK, this is the physical layer, the "pump" which just need to "pump bits around"... perfect, we are talking about Ground-To-Satellite, so we are talking about "radio waves".

As detailed in many posts on this site, and others, you need to calculate something called a Link Budget.

For this example, lets take indeed the link budget formula's as it is described in the linked article. There are far more complex calculations which are better, and will take into account various environmental factors, and bandwidth. If you are interested, here is an sample article

First we are going to make some assumptions, in order to get some sample numbers to work with:

• This is a consumer application, e.g. "Internet of Satellite"
• It needs to be reasonably priced consumer equipment for the ground station
• It needs to be reasonably shaped equipment for the ground station

Based on this, lets put some numbers out there:

• 150 cm diameter dish, 30 dBi Gain at 2.4 GHz
• Computer/rotor/software needed to point and track the dish
• 802.11g "WiFi" bridge, -110 dB noise floor, 20 dB SINAD
• 1 W power output

Please note that the 1 Watt power output, with a 30 dBi dish is about 10,000 times the legislated max in most countries (100mW ERP)

Ok, lets start with the uplink calculations. The formula for path loss is:

PL(db) = 20log(d) + 20log(f) + 32.44 - Gtx - Grx

Lets assume a distance from ground to satellite at 3000 km as per OP:

PL = Path loss in dB d = distance in km f = frequency in MHz Gtx = Transmitting Antenna Gain in dBi Grx = Receiving Antenna gain in dBi

Plug in the numbers:

PL = 20*log(3000) + 20*log(2400) - 30 - Grx

PL = 107 - Grx

With a similar spec receiver at the Satellite end (-110dB noise // 20 db SINAD), we need a signal of -90 dBm to reliably receive the signal.

Plugging in some more numbers, especially the 1 Watt (30dBm) power output, you get:

Rsignal = Poutput - PL + Grx = 30 - 107 + Grx = -77 dBm + Grx.

So even a modest receive antenna with 0 dBi gain, will do for the uplink. We have no problems here !

Lets move to the downlink, and calculate Power Output and TX antenna gain of the satellite needed to maintain a reliably link.

The path loss is the same, it is the same distance, the Gtx of the ground station will now become the Grx of the downlink. The calculation is the same.

With a modest transmitter in the Satellite, and a modest antenna, with a 150 cm moterised dish at the ground station, tracking the satellite, you can reliably build a connection.

Conclusion for Layer-1: it is certainly possible to build a modest ground station which can send/receive radio signals from-to a satellite, given the correct equipment. And at speeds approaching the speed of light, we would not expect more than 10-20 ms one-way latency on this link.

Perfect, we have Layer-1 and Layer-3 sorted !

One more layer to look at:

Layer-2

Well, as we have determined that we are working with "consumer grade" equipment, we will stick to a consumer protocol for this layer: the well known Wifi 802.11g

This is where it gets tricky.

Modern 802.11 implementations are using something called OFDM (Orthogonal frequency-division multiplexing), which in practice for 802.11g is 48 data carriers, and 4 pilot carriers, spanning a bandwidth of 22 MHz, of which actually 16.6 MHz is used (due to the space gaps between the carriers). This would mean that we may need more power in our Layer-1, as the power of the transmitter is now devided over this 16.6 MHz bandwidth needed. So that would be an integral fuction "under the bandwidth curve summarized" to calculate our dBm refernce to noise floor and SINAD. Just for sake of this example, lets leave that, and continue with this in theory, assuming Layer-1 is OK.

The real problem is the way this protocol is structured in regards to protocol "time spacing" or as they are called Guard Interval

In the 802.11 protocols, they are usually set to -.8 microseconds. This 0.8 microseconds will make it very error prone. You can get customised (open source) software to run on your Wifi equipment which allows you for further tweaking these settings, and some have been known to set this to 3.2 microseconds.

At a data rate of 24 Mbps (about half the maximum throughput of 802.11g), a frame takes 566 microseconds + 3.2 microseconds. which means that on a 3000 km link with a 10 millisecond delay, you will have 17 frames "in transit" at a fully loaded link.

On that 10 millisecond link, with those 17 frames, at a data rate of 24 Mbps, there is an average of 254,658 bytes "in transit" between ground and satellite or vice versa.

so, if you have a RTS/CTS (Request to send / Clear to send)cycles everytime the frame sent exceeds 2346 bytes (a common default value), you will interleave a lot of RTS/CTS package in that link, which are not yet acknowledged. When an RTS is send but not acknowledged with a CTS, the transmit will stop, until a CTS is received.

This RTS/CTS which is probably the of most hinderance in "Long Range Wifi" for large bandwidth applications.

Given customized open source Wifi software, you may be able to tweak these settings. Including sending smaller frames, under the configured RTS/CTS threshold. This packet fragmentation will of course significantly and negatively influence the throughput and bandwidth of the link.

The reality is that the traffic will be "paused" quite frequently, giving it a "bursty pattern" in regards to throughput. This will have an effect on the type of application (Layer-4 and up) running on the link. This would mean that time sensitive protocols (such as VoIP) would not be suitable, but others (such as FTP) would be no problem, albeit with a reduced bandwidth.

Conclusion for Layer-2: This layer will give most of the challenges in regards a stable link. But given a variety of open source software available, and the assumption that timers/thresholds can be tweaked, it should be possible to get a 3000 km link established. However the bandwidth/throughput of such would be significantly hindered by the internal operations of the Layer-2 protocol.

Overall conclusion:

It should be possible to create a reliable connection between a ground station and a satellite in theory, given all assumptions in this post. However practically the fact that LEO satellites are moving quite quickly, and the need to track these with a motorised antenna, which means that there will be "gaps" in the link, when the antenna need to reposition to the next satellite.

It would be interesting to do the same calculations with an omni-directional ground station antenna, such as a Quadrifilar-Helix or Lindenblad antenna, which would not have to be pointed to track a particular satellite. Given the wavelength of Wifi at 2.4 GHz, it would probably be an array of multiple antenna's. It would be nice to do extra research for alternative Layer-2 protocols more suitable for long range than 802.11, maybe something like 802.16 or 802.20. This would be another question and out of scope for this answer.