The Montgomery Knight Ground Station is operated from the M. Knight Building on Georgia Tech campus, and is the first ground station developed by Georgia Tech in 2013. It is able receive radio signals but unable to transmit signals. For more information on how to connect to and operate the M. Knight Ground Station, visit the integration page.
Getting Started
The M. Knight Ground Station does not require the user to initially enter the Pip environment in order to operate it. However, the station does require the user to download and install additional tools associated with their user. The program needed to properly operate the M. Knight Ground Station is RF Link Testing Tools which can be found on the Georgia Tech Github page. This additional program will allow the user to use additional commands like protocoldump which prints .kiss file text within the command terminal. This can be downloaded and installed within the M. Knight computer via the following command:
git clone https://github.gatech.edu/speet3/rf-link-testing-tools.git
Reading Received Data
Once in the home directory of the M. Knight Ground Station computer (desktop name: ae-glrg-405135) and RF Link Testing Tools has been installed for the user, the entire station can be operated from here. To read specific pieces of data from overhead satellites, use a command of the following form:
find /var/lib/groundstation/.local/share/groundstation/develop/data/ -mindepth 1 -maxdepth 1 -type d -iname "*RANGE*" -exec find {} -iname "*48000*.raw" \;
This command searches for signals received from satellites with the name RANGE. (In the case of this ground station, missions RANGE-A and RANGE-B will both be found.) To find a different satellite transmission, replace RANGE with the name of whichever satellite that data needs to be read from.
The number 48000 in this command refers to the sample rate at which the signal was received at. This command will display all received signals received at a sample rate of 48,000 kHz or higher. The clearest signals have a high sample rate, so it is best to keep this high enough to list only clear signals.
The list of signals received by M. Knight will be displayed in this command window along with their file path. A typical data file will take the following form:
ssdl_20210630_114939_437475000_48000_fc.raw
The first number, 20210630, represents the date in which the data was received. In this case, it was on June 30, 2021. The second number, 114939, represents the time in which the data was received. In this case, it was at 11:49:39. (Note that this system uses military time). The third number, 437475000, represents the frequency at which the signal was received. In this case, RANGE-B was transmitting at 437.475 MHz.
Find the date, time, and frequency of transmission which corresponds to the desired signal. Once this is found, open the directory containing this data file without including the data file’s name. In this example the command used would be:
ls -lah /var/lib/groundstation/.local/share/groundstation/develop/data/43773_RANGE-B_20210630_155235/
All of the data corresponding to this particular pass can be found within this directory. Waterfall plots of the radio signal can be found in the files that have the .png extension. The waterfall plots which contain dc directly before the .png have been “doppler corrected,” meaning the data has been edited to remove the effects of the doppler shift. When using a Linux device, these plots can be viewed with the following command (this cannot be done using PuTTY):
eog /var/lib/groundstation/.local/share/groundstation/develop/data/43773_RANGE-B_20210630_155235/ssdl_20210630_114939_437150000_48000_fc-dc.png
To view the typed message the satellite transmitted, it can be found within the files with the .kiss extension. KISS is an abstraction format used by the satellites to send messages. To view contents of the KISS file, use the protocoldump command.
protocoldump /var/lib/groundstation/.local/share/groundstation/develop/data/43773_RANGE-B_20210630_155235/ssdl_20210630_114939_437312500_2400_downlink.kiss
A typical packet of information will look something similar to this:
unpack requires a bytes object of length 40
KISS payload of size 174 bytes successfully deframed:
AX.25 non-ascii packet:
Source: KN4AQF
Destination: R4NGEA
Control Byte: 0xf0
PID Byte: 0xb0
Payload:
Python struct could not unpack the PDU, PDU length is 157 bytes
For the specified string, unpack requires a bytes object of length 40
0x0000 50 67 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c |Pg..............|
0x0010 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c |................|
0x0020 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c |.. !"#$%&'()*+,|
0x0030 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c |-./0123456789:;<|
0x0040 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c |=>?@ABCDEFGHIJKL|
0x0050 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c |MNOPQRSTUVWXYZ[\|
0x0060 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c |]^_`abcdefghijkl|
0x0070 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c |mnopqrstuvwxyz{||
0x0080 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c |}~..............|
0x0090 8d 8e 8f 90 91 92 93 94 95 2c 3b e7 51 |.........,;.Q|
This information can then be decoded by whoever needs it.