It was in May 2020 when we announced the two projects that Libre Space Foundation would have under its mentorship as part of the Google Summer of Code. A few weeks ago we presented to you the first of the two projects of this year’s GSoC 2020 titled Deep Learning and Space Weather. So now is the time for us to present to you the second project we have been mentoring. The project is SatNOGS-RF collisions: A python library to calculate RF collisions during Satellite observation. Our mentee, Ravi Charan had been working on this project over the summer months and here is what the project is about.
SatNOGS-RF Collisions Library
The project’s main goal was to create a tool to be able to calculate and predict Radio Frequency collisions during a Satellite and a ground station communication. In the future, the tool is meant to be integrated into SatNOGS. (The worldwide, open-source network of satellite ground stations).
The Case
As the number of deployed satellites keeps increasing it is often that satellites transmit within the same or near frequency range. The overlapping in frequencies may easily interfere with the results of the observations and it may affect their accuracy. This interference in the observed results is what we refer to as Radio Frequency collision.
The Solution
The SatNOGS-RF collisions library is designed to deal with exactly that problem. It attempts to calculate efficiently and predict the Radio Frequency Collisions for a given location(s) of a ground station(s) or for a given satellite(s) and orbit(s) over a time range.
Having a more detailed look into the project
The SatNOGS-RF Collisions library is built on python and it is divided into two submodules: the GSS and the Onlysat.
The GSS submodule
The Ground Station-Satellite submodule aims at detecting the possible collisions between multiple satellites at a single or multiple ground stations over a time period. This is achieved by taking into consideration certain parameters. These include the ground station ID(s) (or) the coordinates, the elevation of a ground station, the satellite details and the time range. With the time-range into mind, the user can check if any of the satellites mentioned pass or fall under the Field of View of the Ground Station. As soon as the list of all the satellites is composed, then all the transmitters of these satellites are checked to detect if they fall within a close frequency range.
In order to deal with the Doppler shift effect successfully and having in mind that satellites revolve around the Earth at a faster velocity than the Earth’s rotation, the downlink frequency of a Satellite wouldn’t be the same as the observed frequency at the ground station.
As Ravi analyses in detail in his article:
An external library PyEphem is used to compute the relative velocity of the satellite at the given point of time. We also make use of the PyEphem library to extract the dynamic meta-data of the Satellites that changes with time as it provides an implementation for SGP4 models which is used to get essential data of the Satellite given the TLE of the Satellite.
With the GSS submodule, the users can either choose to detect if there will be a Radio Frequency collision or to detect and compute the collision details.
The detect_collision methods return boolean values indicating if the collision is possible among the satellites in the given time range whereas, the compute_collision methods return collisions in a JSON format which include metadata of the collisions including Groundstation details, time period of the possible collision, and the transmitter frequencies of the satellites at which the collisions take place.
The Onlysat submodule
This is an extension module excluding the ground station from being a parameter. Instead, what it does is to locate the region on the surface of the Earth where a potential Radio Frequency collision might take place. The parameters that need to be specified include the satellite details as well as the specific time range for which the possible collision must be detected and the results are returned in a GeoJSON format.
This submodule first computes the footprints of each satellite and then it computes the intersection of the footprints. Once the latter is checked, the Satellite transmitters are checked too, particularly those that transmit within a near frequency range over the specific region. And that is what is marked as a Radio Frequency collision. You can find out more on Computing the footprint of Satellites in Ravi’s full article.
As was the case with the GSS, the Onlysat submodule also allows the user to opt between detect_collision and compute_collision where the latter also returns the region over which an RF collision might take place. The calculated area is returned in the GeoJSON format as part of the metadata.
SatNOGS- RF Collisions: Next Steps
Both submodules require further work and testing in order to be integrated fully into SatNOGS. When this is completed the users of SatNOGS will have at their disposal a tool with which they will be able to calculate Radio Frequency collisions efficiently.
Conclusion
By collaborating closely with his mentor, Ravi Charan devoted his time, effort and knowledge for the SatNOGS-RF collisions library for GSoC 2020. This collaboration provided a valuable hands-on experience for him and from our part, we would like to wish him the best of luck for his future!
If you are a developer yourself, interested in space technologies and wishing to gain practical and hands-on experience in developing space technologies, do not hesitate to join our community forums and our SatNOGS/element Channel. All you have to do is state your interest and you might be able to work and contribute in inspiring projects allowing you to obtain actual experience, hone your development skills and get an insight look at space technology development processes. Our Communities at Libre Space Foundation and SatNOGS are always accessible and welcome projects, ideas and collaborations that promote, enhance and support open-source technologies and methodologies. So feel free to join us any time!
