An Open Source Program that allows users to interact with a Spacecraft in a lab environment, pre-launch.
For those who are new to the Space Industry and it's terminology, please refer to the Background section.
Also refer to the OSSAT Glossary for explanations of any terminology.
Otherwise, head to User Setup if you want to use the software, or Development Setup if you want to develop.
NOTE: This software is useful for lab testing a spacecraft, pre-launch. Different software would be used to communicate with the spacecraft in orbit. The communications protocol is not suitable for in-orbit communication, see The Spec for further details.
Once a Spacecraft is in flight, operators will need to communicate with it. This is normally facilitated via Ground Stations located around the globe that use a radio link to send and receive packets of data.
During a typical mission, a Spacecraft will send stats down to the ground, which we call Telemetry. This could be temperature, battery charge, sensor readings, or any data point that you can think of. However, the Spacecraft would usually only transmit the most important Telemetry by itself due to limitations with the radio link. A Ground Station can request a particular Telemetry point by sending a Telemetry Request.
The Ground Station doesn't just monitor a Spacecraft's Telemetry, an operator can send commands to tell it to do things. This could be switching on a particular system, turning towards the Sun to charge batteries, synchronising the on-board time to the Ground or a variety of mission specific functions. These are facilitated by something called a Telecommand.
The Ground Station also needs to upload and download files. This could be downloading images taken by a Spacecraft camera, or uploading an operating schedule or code update to the Spacecraft.
Mercury GS fulfils the need to send Telemetry Requests, Telecommands and to display the Telemetry generated by the Spacecraft. It does this using a simple (non-flight) communications protocol. It also includes functions to synchronise the time and to upload and download files.
It represents a simple solution to test spacecraft functions without reliance on the complex protocols available for spacecraft communication.
In the future, we are hoping to integrate the Mercury GS functions into a Continuous Integration environment that will test the spacecraft functions continuously throughout the development.
Maybe you could help with this development?
The manual, which describes how to use Mercury GS, is located in the repo here.
NOTE: This initial version of Mercury GS only fully supports Windows. Linux and MacOS support is expected after further development.
If you wish to run Mercury GS as a User, follow these steps.
Run the batch file build_env.bat, you only need to do this once. Then execute run_env.bat when you want to run MercuryGS.
Run the shell script build_env.sh, you only need to do this once. Then execute run_env.sh when you want to run MercuryGS.
If you wish to develop Mercury GS, follow these steps.
A minimal Python3 installation is required, it is recommended to use virtualenv for clean Python installation and then install PyQt bindings. You can either run the scripts as shown in User Setup or manually like so:
Clone the repo and navigate to its directory.
Create a new virtual environment.
python -m venv MercuryGSEnv
5. Install the required packages.
pip install -r requirements.txt
6. Make sure the following packages have been installed.
python3 -m pip install PyQt5
python3 -m pip install pyserial
python3 -m pip install PyQt5-tools
python3 -m pip install QtPy ``` Another solution is to install a full Python IDE like Pycharm and install the packages through its package manager.
NOTE: For further information, design and requirements. You can find the Specification for Mercury GS here.
The low level drivers talk over a COM port that is configurable in the GUI. To emulate a connection with a SpaceCraft we must spoof a connection between two ports.
Download a program like HHD Virtual Serial Port Tools, create a virtual pair between two ports (for example COM1 and COM2), and then open a terminal program like TeraTerm to listen on one of them (COM2 for example). Settings are default 9600 baud, 8 data bits, 0 parity bits, 1 stop bit. The baudrate is configurable in the GUI on the "CONFIG" tab.
NOTE: This solution is only for Windows.
Frames can be sent to MercuryGS via a terminal, these are located in the Test Frames folder.
HHD Free Hex Editor was used to create these frames.
If you wish to edit the GUI, you will need Qt Designer.
For Qt Designer install, it's suggested to download the package from here, it is used to edit the UI layout - platform-comms-app.ui.
To use the qt ui file from the Qt designer, we need to build it to a python file.
You can do that by running:
pyuic5 platform-comms-app.ui -o platform_comms_app.py,
or by running the build script from the Scripts directory.
The built code of the current version of Mercury GS is included in the repo, so you will only need to rebuild the GUI if you make changes to it.
To run the files built by the last step, run "main.py" either via command line or through a Python compatible IDE.
Mercury GS includes other open source software, for licensing details, see here.
If you wish to contribute directly to the development of Mercury GS, have a look at the existing Github issues and register here.
Description: Ability to detect open serial ports and set the drop down menu in the Config tab to the available ports. Demo: 1. Run Mercury. Navigate to Config tab. Observe open ports in drop down menu. 2. Follow Demo 1, then open a new port. Observe the new port added to the list. 3. Follow Demo 1, then close an open port. Observe the port disappear from list.
Hi, really interesting project. I think that the current pip requirements list is missing the adafruit rfm69 package required by comms.py, I noticed as I was getting the workspace setup. Since version 2.1.5 of the adafruit rfm69 package was released around the time the rfm69 code was pulled into main, I added that to the requirements list.
Description: Ability to detect baud rate of incoming datastream and synchronise to it. Requirement: 00025 Demo: 1. Send Telemetry Response via Tera Term at a baud rate that differs from the one configured in Mercury GS. 2. Observe the baud rate in Mercury GS synchronise.
Description: Ability to download files to specified destination, following a Download Request message. Requirement: 00220, 00230 Demo: 1. Send Download Request. 2. Observe Request on Tera Term. 3. Transmit file via Tera Term. 4. Observe file saved to destination specified in Download Request.
Description: Ability to upload Files to the Spacecraft. With a button to abort the upload. Requirement: 00210, 00215 Demo 1: 1. Upload file 2. Observe file displaying in Terminal program.
Demo 2: 1. Upload file. 2. Press abort function before upload completes. 3. Observe Upload abort.
Description: Log Telemetry to a file. With a check box to enable/disable logging. Requirement: 00175, 00176 Demo: 1. Send Telemetry Responses via Tera Term 2. Observe Telemetry displayed on Mercury GS, but no file being created. 3. Tick box to enable logging. 4. Send Telemetry Responses via Tera Term. 5. Observe file being written to with Telemetry data.
Release 2.1.1 Prepares MercuryGS for being made Open Source. A manual has been created, as well as a fully fleshed out Readme. Changes have also been made to improve stability, speeds and to squash some bugs.
Full Changelog: https://github.com/Open-Source-Satellite/Mercury-GS/compare/GSRel2.1...GSRel2.1.1
Release 2.1 Integrates Reception of Telemetry Request Rejection Response Frames and displays the channel along with the rejection code (reason) on the GUI.
This is Release 1 of Mercury GS.
To get going with this release. Please follow the Setup section of the User Guide in the Readme.
For documentation describing this release. See the Mercury GS Spec.
spacecraft ground-station cubesat satellite space microsatellite microsatellites testing telemetry open-source