Iridium is a satellite communication system, previously mainly used for satellite phone calls and remote control and tracking of scientific instruments or trucks. Recently, however, more and more lightweight modules were introduced to the market which allow for new applications in vehicles such as high-altitude balloons and miniaturized spacecraft.
The goal for my GSOC development was to improve the existing ground station coded for the MIRKA2-RX KSat experiment in order to get a more flexible and versatile platform that can be easily modified and fitted to the needs of any experiment.
Java is used as main programming language.
Several steps were needed to take the software to its current state. I want to give you a brief overview of what I did in order to get there but if you are only interested in the final result feel free to skip to the next section 😉
The first things I tackled were cleanups of the code and the migration from a pure NetBeans project to a Maven project to allow easy management of dependencies and modifications from other IDEs in the future.
A class diagram was created to visualize the current status of the code to other team members.
Then, I wrote JUnit tests for currently existing classes/ methods and for those that were soon to be implemented. Unit tests (JUnit in Java) are a way of automatically testing your code for bugs that might occur while adding new features. Writing those right at the beginning, before starting to code, can save a lot of time as you don’t have to test everything by hand.
Consequently, while writing those I also worked on the first ideas for implementations of the configuration file and a suitable layout of the xml file that would be used for easy structure modification of messages sent from the experiments.
I wrote the controller for parsing the messages and finalized the design for the .xml files with Florian Grabi (who is the guy in charge of the software for the MIRKA2-ICV KSat mission). The MIRKA2-ICV mission was the next mission the ground station would be used for. So I also implemented features requested by the MIRKA2-ICV team for the flight campaign that was to be launched in South Africa in mid/late July.
Coming up with a good structure was harder than I previously thought. After many hours of tinkering, however, the final results seem to be a very promising base for future development.
An overview of the final internal ground station structure can be found in the picture below.
I also modified the existing GUI so that it can handle the new controller for the messages. This allowed us to carry out tests with the hardware using the new ground station and data structure and, hopefully, also gives Victor an easier job as he can use this code as an example of how to integrate the controller with the GUI once he works on that part.
I implemented the NASA World Wind SDK which is used for displaying GPS coordinates on a world map. It turned out to be quite tricky to get this API to do exactly what you wanted, but finally, I did come up with code that now generates a pretty visualization.
Lastly, I did a lot of documentation and write ups so that my code will be helpful not only to me but also to future developers working on it.
Now you’re probably wondering what it looks like… ?
Current state of the software
Well here it is:
Pictured above is a screenshot of the Java Swing version of the ground station I created for the GSOC project. If you want to see the new JavaFX version you can check out Victor’s GSOC article.
The software currently has several features:
- You can import data automatically via e-mail or over a serial connection. Alternatively, you can import data manually using a file chooser.
- Imported data gets parsed internally using a predefined protocol scheme. This protocol scheme is saved as a .xml file (more on that later on)
- Sensor data gets displayed in charts. GNSS Data can be visualized using the NASA World Wind API that was implemented in the ground station.
- Sensor data can be internally modified (e.g. displaying roll/pitch/yaw instead of quaternions), this needs to be done separately for every experiment in the DataModification.java file.
- Data (both modified and raw) can be exported to .csv files for further processing. (e.g. in Matlab or Excel)
I now want to go a bit more into detail on all the features mentioned above. This is going to be more technical, but I tried to keep it as readable as possible 🙂
Importing data is one of the main tasks ground stations have to master. For doing this the ground station currently has three methods (serial, mail and file). Generally, once data has been read, the ground station’s main controller is notified that there is new data available for processing and takes it from there.
The serial communication is done using an external library (jssc for those interested). It provides the means of opening a serial port and then communicating over it by either writing data to it or reading data from it.
Communication via e-mail is done using the javax.mail API. This is rather simple and works like checking your normal e-mail client. Once a new e-mail with attachments is received, the file data is read and handed over to the main controller.
This is done similarly for the file method, the only difference is that you can choose the files you want to open yourself.
Once the data is in the ground station system, it is parsed according to the protocol file which the user needs to specify. There are already default protocols included in the program which were used on the MIRKA2-ICV mission. A protocol file is an .xml file with the following structure:
First, the protocol type is defined (at the moment only ‘SEQUENTIAL’ is supported).
Then the structure of the data is defined; here you have a header part where data that is for internal use only and doesn’t need to be displayed to the user is defined. And you also have the data part where various sensors can be described. For more info on this, please have a look at the user manual.
Using this message structure, the main controller of the program can make sense of the incoming data and can correctly display it to the user.
Once the data is parsed internally, it still needs to be displayed to the user somehow. With the Swing GUI this is done using the JFreeChart library for displaying charts, NASA World Wind for displaying GNSS coordinates on a world map (shown in the video below) and a text field for displaying raw data and error messages as a continuous stream of text.
Sometimes data gets transmitted differently than how you want it to be displayed. It doesn’t always make sense to read the sensor data in its raw form. If that’s the case, the values need to be modified before displaying them to the user. To achieve this, there is a DataModification Java class that does this for you.
Just insert your sensor data and you’ll get nice, pretty sensor data back. However, since this is very experiment specific, if you want to use this, you need to write the code (or reuse the existing one) to fit your specific needs. The user manual holds all the information on how to do this.
Data export is currently only available in the .csv format. This is a very simple file format where data values are saved in a file separated by commas. This has the advantages of being very easy to implement and also being readable by almost any program that you might want to use for further processing of the data.
Exporting files is rather easy – once you hit the export button you only need to specify a file name and the folder you want to save to (using the normal file chooser that you are used to).
The image below shows the same set of data displayed in the ground station, Excel and in a Matlab figure.
There is always stuff to improve on, and working on the ground station for quite some time now, I naturally have a list of enhancements that I believe would make handling the software easier or increase its efficiency. (The list has no particular order)
- Getting rid of necessary user code changes
Currently users of the ground station will still need to make code changes when adapting the software to fit their experiment. Changes such as methods for modifying the sensor data still need to be implemented in the code. Ideally this would be replaced with a GUI element where users can choose how to manipulate the data.
- Drag&Drop for GUI elements especially charts
The same applies to the GUI elements, changing them still requires some effort. It would be ideal if you were able to build your own custom charts and to use drag&drop for a convenient ‘live’ rearranging of the GUI while using the application.
- More ways to get data into the ground station
Currently there are only three options for getting data into the ground station. Especially the file option could be enhanced with an automated search for new data in a specified folder.
- Adding prebuilt conversion
This one is quite similar to the first item on this list. Having prebuilt conversions (e.g. quaternions to euler angles) would greatly benefit future users of this ground station.
- Better internal error handling
This one is kind of on the technical side. Internal error handling is not well done at the moment. This would be enhanced by throwing custom exceptions, which would allow for easier internal communication of occurring errors.
- Localization (Adding more languages)
The program is currently only available in English. Adding localization would allow the program to be available in other languages. Furthermore, it would also make internal handling of Strings prettier J
- Adding user preferences
Adding user preferences would not only allow users to make customizations to the program, but also make it possible to preserve window state (i.e. size, position, …) over various uses of the program.
- Adding possibilities to have easy transmission error controlling
Especially when communicating via a serial communication port it can become necessary to have error controlling such as forward error correction implemented into the program.
- Check validity of protocol documents before loading
Currently there are no sanity checks of the protocol files when they are loaded. Only at runtime, when the first messages are parsed, errors can occur. This should be done already at loading of the file and clearly communicated to the user.
For final remarks I want to thank the whole Aerospaceresearch.net team for this wonderful opportunity of taking part in GSOC. I learned a lot and I hope to stay part of this community in the future.
Big Thanks to all of you! 😀
Here is a list to the work I did and other stuff:
Victors blog post: link
Words that might tripped you over
GSOC – Google Summer of Code. If you are reading this you propably know what this is. If you don’t, this explains it really well 🙂
IDE – Integrated development environment. An application that helps developers write code more efficiently than if they were using only a simple text editor. (Wikipedia)
NetBeans – An IDE for developing Java applications. (homepage)
Maven – Maven is a tool that allows you to easily include libraries (code other people wrote) into your projects. (Wikipedia)
KSat – Small Satellite Student Society University Stuttgart. KSat is a student group from students for students who conduct experiments related to space. They are fast growing and have many cool projects 🙂 Check them out here.
API – Application Programming Interface. An API is a set of tools and building blocks that can be used when developing a program. (Wikipedia)
GUI – Graphical User Interface. Everything you see on your screen is a GUI. It basically refers to everything you see on the screen when using a program.
Swing – Swing is a Java API that provides the tools for building a GUI. (See how all those words make sense now 😀 ). However Swing is a bit outdated and not actively developed anymore.
JavaFX – JavaFX is a newer Java API for GUIs, it basically does everything that Swing does but in a modern way.