The last three months I’ve been working on gr-leo, a GNU Radio project that aims to provide blocks for the simulation of the telecommunication channel between an orbiting satellite and a ground station.
More specifically, using gr-leo, one is able to:
- Define a satellite given its operating characteristics (i.e RX/TX frequencies, antenna types) and a valid TLE.
- Define a tracker by providing its coordinates, operating frequencies, antenna types and an observation timeframe.
- Define the communication channel model using the appropriate GNU Radio block. Currently, only the LEO model is supported and provides the option of enabling different types of impairments such as Doppler shift, free-space path loss, antenna pointing loss and attenuation due to atmospheric gases and rainfall.
Then the gr-leo channel model block will attenuate the input signal according to the defined channel model and the orbit of the satellite described by the TLE.
You are more than welcome to test the project, report bugs and provide feedback and suggestions for future development.
You can clone the project from the dev branch https://gitlab.com/librespacefoundation/gr-leo. For more information you can visit the wiki https://gitlab.com/librespacefoundation/gr-leo/wikis/home and the documentation https://librespacefoundation.gitlab.io/gr-leo/
Just to add some interesting use cases of this module and why is worth trying!
- Mission planning
- TX/RX simulation
- Characterize the performance of decoders
- TLE or/and frequency drift validation (received versus simulated frequency)
Any performance data regarding the maximum allowed sample rate for a specific HW?
We would like to test it with a LIMESDR and a 2MSPS BPSK modulated signal.
That’s a good question! I just made a measurement and the Channel Model block can handle an input signal at about 21 MSPS at my i7-2600K.
It’s great that you want to use gr-leo. Please don’t forget to report back your results and provide feedback.
As regards to your question, I haven’t yet any performance related results, but I’m sure you can trust @surligas reply.
Also, take into consideration the “time resolution” parameter in the tracker variable block. It refers to the interval between each calculation, so it will surely affect the performance of your simulation.
Can we use Gr-leo for doppler correction for uplink instead of gpredict?
Using only doppler correction and no noise, if we use “downlink” instead of “uplink” does that mean doppler compensation?
The “uplink” and “downlink” options in gr-leo are only used for the selection of the appropriate frequency and antenna setup according to the blocks you have added in your GRC flowgraph.
In example, for the “uplink” case the calculations will be made using the tracker’s TX frequency, whilst for “downlink” the RX frequency of the tracker.
Maybe there is some space for modifications there in order to be more clear.
gr-leo produces an output shifted by F(doppler).
Is it possible to add an option where the input is shifted by -F(doppler)?
If you can implement this feature it will be a better doppler compensation tool than gpredict!
Perhaps I’m misunderstanding something in the discussion, but…
The Doppler shift is positive before the time of closest approach and negative after. Both gpredict and gr-leo work like this because it’s the laws of physics, not an option.
Sorry for the confusion.
I thought gr-leo is a simulator.
At the begining of the satellite pass it adds F(doppler) to Fcarrier so that the Receiver will get the shifted signal.
What I want is an option for changing Fcarrier such that Fcarrier-F(doppler) is transmitted and the receiver at the satellite gets Fcarrier-F(doppler)+ F(doppler)= Fcarrier.
Yes, it is a bit confusing when you are saying “it will be a better doppler compensation tool” since gr-leo is not a doppler compensation tool but a simulator for simulating signal reception from a satellite. This means that it will simulate Fcarrier + F(doppler), where F(doppler) is positive at the beginning of a pass and negative at the end of the pass.
Still, Adding doppler compensation to gr-leo would eliminate the need of installing an using an external program to do the job.
You can actually get the estimated Doppler shift that is exported in the CSV port and use it however suits you best. I could add a separate message port for the frequency shift in a next commit, but still the main purpose of gr-leo is what @csete described.