The next project I will be embarking on is researching the possibility of setting up an Internet (or HAMNET as known to amateur radio operators) connection over the QO100 amateur radio geostationary satellite. The QO100 satellite has two transponders: the narrow band transponder used for SSB voice, SSTV and digital voice, and the wideband transponder, which can be used for amateur radio digital television (DVB-S most frequently) or other types of amateur radio wideband transmissions, which could include the Internet over satellite type of research.
In the last two years, I worked a little on the IP-over-the-air capability of QRadioLink and managed to use the PlutoSDR as an Internet modem using GNU Radio on the 430 MHz (70 cm band) and 1290 MHz (23 cm band) frequencies for physical links in a place where the WiFi signal could not reach (over a hill). The IP modem is point-to-point full-duplex only so it does not allow multiple access on the same frequency, and it used the DQPSK single carrier modulation for a symbol rate of 125 ksymbols per second, resulting in a bitrate of about 240 kbit/s, minus the Ethernet frames and IP headers overhead. At first, the modem required continuous transmission of the signal which had the downside of wasting energy when there are no IP packets being transmitted.
To overcome this limitation, I was forced to do some optimization of the GNU Radio code parameters in order to achieve faster burst synchronization and clock acquisition, which would get rid of the requirement of a continuous carrier and enable bursts of signal to only be transmitted when there is actually data to be sent, in a similar way that WiFi works.
Since I was also contemplating using cheaper and less power hungry FM amplifiers, I also added a second modem using the 4FSK (with a root-raised-cosine symbol filter) modulation type, which is similar to the modulation used by DMR or Yaesu System Fusion transmissions. This new modem offers a slightly lower bitrate, with 50 ksymbols per second resulting in 100 kbit/second rate or about 80 kbit/second useful payload. This is not a lot higher than dial-up modems in the late 90's offered, however it can support one or two VOIP streams being carried over it.
The bandwidth occupied by the radio signal is 320 kHz in the case of the DQPSK modem, suitable for 500 kHz channelization, and 250 kHz for the 4FSK modem. If you are wondering why it takes up such a large bandwidth, it's because the data is protected by convolutional encoding FEC (forward error correction) with a rate of 1/2, which doubles the amount of data symbols sent and thus increases the bandwidth to twice of what would be needed if no FEC was used.
Under the hood, the TUN/TAP Linux device is used by QRadioLink, a TAP interface is created, and it can then be bridged to another local interface or DNAT forwarded as needed. The TAP interface supports all types of IP packets, including UDP, TCP/IP and ICMP. Unlike the the TUN interface, the TAP interface type also contains Ethernet frame encapsulation, which adds some overhead, but this is something that I wanted to use for more advanced purposes which I might expand on later.
Technical details about the structure of the radio frames sent by the GNU Radio modem:
The main issue most likely to come up here is ping latency, which, for reasons of some sub-optimal code that I wrote once, is not that great, ranging from 200 milliseconds to 600 milliseconds. So I will have to do further work in this area to optimize latency. Due to the speed of light and the large distance to the geo-stationary orbit of QO100, this latency problem will only become worse, raising the question if it is not too high to be able to establish an IP connection over the satellite. This is one question that I aim to get answers to with this particular project.
Since the satellite transponder is just a full-duplex "bent-pipe" with the input in the 2.4 GHz band and the output on the 10 GHz band, and because it is geo-stationary, I don't expect other issues like multipath or Doppler effect which would only bring more complexity to the GNU Radio modems. However, I will be looking closely at the phase noise introduced in the signal by the transponder.
For terestrial IP-over-radio links I have used so far both the PlutoSDR and the LimeSDR-mini devices, usually transmitting on one frequency band and receiving on another frequency band (430 MHz and 1290 MHz band or 1290 MHz and 2300 Mhz bands) to avoid needing large filters. Since the satellite is full-duplex, I do not need an RF switch and relay board to handle switching from RX to TX so this simplifies the RF path a lot. As a note, solid state RF switches these days can achieve switch times of less than 10 nanoseconds which is impressive.
Both devices mentioned above can tune to the required frequencies and are capable of at least 0 dBm output power in the bands I am interested in (2400 MHz transmit and 700 MHz receive).
The same LNB and circulary polarized 2400 MHz feeder can be re-used from my previous attempts of using QO-100.
A transmit gain module is required to get from 1 milliwatt of power to 100 milliwats which can attack a larger power amplifier. For this gain module, I am currently using the GALI-84+ gain block, which has a P1dB of 20 dBm in the 2.4 GHz band. Unfortunately, using the same cheap 2 Watt "WiFi amplifier" as for the narrow-band transponder won't be enough, since the signal is much wider than a voice signal. We can calculate the link budget with precision, however finding out how much power we need can be done just by approximating starting from the Shannon-Hartley formula:
C = B * log2(1 + S/N)
Finally, I see many challenges ahead with this project and a lot of uncertainty. The system might not work well enough to create an Internet connection over the QO100 satellite. Or the hardware demands might be just too big. However, the payoff could also be good if it does work (at least for some amateur radio operator stuck somewhere in Africa with no other way to get an IP link up). The amateur radio hobby is a lot about experimentation and finding different ways of communication with off-the-shelf or self made hardware. Even if I fail here, I will have learned something useful while doing it.