Architecture
The main concept of the GSC is based on core architecture, which means that all main features are provided by a functional core block, in which all interaction with other utilities is strictly defined. The architecture is portable, which means that it can be moved without almost any changes to other Linux-based platforms (f.e., Raspberry PI, Debian, Ubuntu, Mint, etc). The product is written in C and compiled with CMake.
The architecture consists of the following subsystems:
- Configuration server
- Configuration parser
- Block for orbit prediction
- Block for antenna handling
- Block for SDR interaction
- Block for scheduling satellites
- Notification system
Antenna rotators’ controllers are programmed by rotctld daemon. It is a part of Hamlib library, which is widely used as a software controlling unit for ground stations all around the world. It is a standard Linux-based utility that supports a lot of controllers of antenna rotators. Widely used for numerous prediction programs like GPredict, libpredict library for orbit prediction has found an application in this project too. The system is configured from a config file (all static variables, f.e., latitude, longitude, azimuth offset compensation, etc.) and via network requests (dynamic configuration, f.e., configuration for tracking). GSC uses a network server to process JSON configuration requests. To provide a reliable solution, libev library for network events handling has been integrated. Last but not least, libjson-c, a C-based library for parsing JSON requests, has also been chosen as a lightweight JSON parsing library.
The digital signal processing is done in the GNU Radio, which makes you simply modify the currently existing data chains. The latest flowgraph is available by the URL.
The entry point of data begins at the osmocom Source, which represents the SDR board. You may see the frequency set among the sampling rate. The frequency is set according to the variable value, which is not seen here (please refer to the flow graph pdf). The output of this block is Real (I) and Imaginary (Q) (IQ) samples taken with the sample rate of 480k samples/sec. Each of them holds the imaginary and quadrature information about the signal, which means that all parameters of the signal, including amplitude, frequency, and phase, can be measured. The IQ form is the form of a complex number, represented by 32-bit integer values. This will be important for the next blocks and during the demodulation stage. The same block also configures the hardware to amplify the signals: it supports Low-Noise Amplifier (LNA), Intermediate Frequency (IF), and Base band (BB) amplification. Every signal has a maximum bandwidth, beyond which the information cannot be obtained. To simplify further processing, it is often the case when the bandwidth is being reduced by applying a digital low pass filter, which attenuates the frequencies out of the needed range. The cutoff frequency is set from the variable based on the parameters of a particular satellite (variables will be discussed later). This filter also has a parameter of Decimation: the factor which determines how deeply the sampling rate of the signal will be decreased. In our case, it’s equal to 10, which allows resampling 480k signals to the 48k sampling rate, which is basically the frequency of the most common audio cards used. This approach enables compressing Work performed 19 the most important part of the signal (primary) and debugging it with the sound equipment (secondary). The compressing becomes important when we look at the next element, which is the File Sink. This block is used to store the raw and downsampled IQ signal, which is helpful during debugging. The raw signal is connected to the particular block to build a Waterfall Plot. As it was mentioned above, instead of using a real-time signal, it is sometimes helpful, especially for debugging purposes, to use one recorder during the other operation. This can be seen below when the Wav File is read and converted to the complex form. The selector is used to change the signal source within the flow graph and is controlled by the special variable as well.
Depending on the modulation used (satellite-depending variable), the other selector then distributes the preprocessed signal to the respective chain: for BPSK, GMSK, or AFSK modulation. For demodulation, the gr-satellites blocks are used. After it's done, the signal goes to the relevant deframer. At this time, those modulations and deframers are supported:
Modulations:
- BPSK
- GMSK
- AFSK
- FM
Deframers:
- AX25
- AO-40
- FOSSASAT
- GOMSpace U482C
- GOMSpace AX100 (Reed-Solomon)
- GOMSpace AX100 (ASM + Golay)
The Doppler correction is external, using XML-RPC protocol.
Interaction with the GSC is implemented with the help of XML-RPC protocol, which is a commonly used Remote Procedure Call (RPC) method in this kind of task and which functionality is supported by GNU Radio. The basic structure of the XML-RPC protocol is straightforward. There are two instances engaged: the sender, which requests the command, and the receiver, which executes it and sends the reply back. By using a special Extensible Markup Language (XML) format, the sender specifies the name of a procedure to execute, all the arguments needed and sends a Hypertext Transfer Protocol (HTTP) request to a specific IP address and port. Receiving this packet, the receiver looks for such a procedure, checks the presence and types of the arguments passed, and gives control to this procedure. Afterward, the result is sent back with the same HTTP reply, including the status code of the procedure.
There are two configuration files used for the operation:
- GSC configuration file Used to specify the configuration of the Ground Station Core:
- Open network ports A network port for the configuration JSON requests (satellites scheduling, moving antenna, retrieving status, etc), network ports to communicate with rotctld daemons that control antennas
- Path to a flowgraph A very important parameter that allows having multiple GNU Radio flowgraphs. Normally, only one is used.
- LNA, BB, and IF gains Parameters of the SDR that are used to improve the quality of reception and usually doesn’t change
- Calibration parameters Over time, an antenna positioning error increases. To eliminate this, calibration is used. The ‘calibrate’ parameter specifies the number of passes, after which the new calibration should take place.
- Latitude & Longitude of the GS The ground station needs to know its location to be able to estimate the passes.
- GNU Radio configuration file
This one is configured personally for each pass and includes the configuration of the modulation used, Remote Agent target port for the inbound data, baud rate, bandwidth, etc. Created by the GSC, used by the GNU Radio flowgraph.
This is explained on the figure below:
During the operation of the ground station, there are some actions to take at the beginning of the tracking and the end of it. In the scope of this project, those actions are called ‘pre-action’ and ‘post-action’ correspondingly. They are briefly described below:
Pre-actions:
- Create the directory where the resulting files (both raw and restored frames) will be stored;
- Select the needed antenna for the reception
Post-actions:
- Move all the results to the directory created in pre-actions;
- Send an email notification to all people concerned
- Push data to another place
The relevant actions are called from the GSC before the start or before the end of the tracking. Architecturally, this was a wise decision to put such actions outside of the GSC to allow people to add any new actions on top without rebuilding the whole project. The implementation can be found in the python script ‘command_handler.py’. The implementation of the notification system is also provided there.
The antenna selection command communicates with the RF Antenna Switch module. The implemented communication involves the USB to UART connection and the transmission of the antenna identifier to the device. The firmware processes the request and selects the antenna. When it’s done, a confirmation message from the board is sent.
The notification system allows you to configure sending of the results of the observations. The letters contain the attachment of the recent data:
For the mission control center, understanding the current status of the available hardware is a question of utmost importance. The statistic is available through a JSON /GET /status request.
The collecting statistics include:
-
Amount of satellites scheduled
-
Amount of satellites tracked
- Overall
- In the VHF frequency band
- In the UHF frequency band
-
Amount of satellites preempted (how many intersected satellites was rescheduled - the measure of overload of a ground station)
-
What is the current azimuth and elevation of the GS
-
Text and the corresponding numeric state that can be one of:
- ‘Not set up’
- ‘Waiting’
- ‘Calibrating’
- ‘Parking’
- ‘Tracking’
-
The name of the nearest satellite approaching
-
The next AOS of the nearest satellite approaching
-
Current progress - what percentage of the pass has been elapsed (if the GS is being in the ‘tracking’ state at the moment)
-
The uptime (constantly increasing time of operation)