Scott Tilley VE7TIL is making a serious effort and a great job of recording and processingLES-5 telemetry. He is recording all the passes over his home in western Canada (which last several days, due to the sub-synchronous orbit), and sharing the data on a Github repository, together with Jupyter notebooks that analyse the data and plot some of the telemetry variables, such as the values recorded by the RFI experiment.
I am storing this data in InfluxDB 2.0 and using Grafana to plot it and explore it. The Grafana server has been running for quite some time now, but I never announced it publicly, so very few people have used it. I guess that now is a good time to share it with a wider audience. The server is at eala.destevez.net:3000 and the LES-5 dashboards can be accessed by using user “les5” and password “les5”.
This post is a follow up to my study of the “wiggles” observed in the local oscillator of the QO-100 NB transponder. After writing that post, I have continued measuring the frequency of the BPSK beacon with my station almost without interruptions. Now I have some 44 days of measurements, spanning from April 9 to May 23. This data can be interesting to look at, so I’m doing this short post to share the data and look at it briefly.
The Jupyter notebook with all the data can be found here. The data is also linked in my jupyter_notebooks Github repository, which now uses git-annex to store the data in my home server. See the README for instructions on how to download some or all of the data files in the repository.
The whole time series can be seen in the figure below. We note that the typical Doppler sinusoidal curve varies slowly due to orbit perturbations and sometimes suddenly as a consequence of a station-keeping manoeuvre. I tweeted about one of the manoeuvres a while back.
There are now too many days in order to see things clearly when the frequency curves for each day are overlaid, but hopefully the figure below gives a good idea. We can see that the wiggles still happen approximately between 21:00 and 06:00 UTC, and between 11:00 and 17:00 UTC.
If we add an artificial offset of -15 Hz per day to the curves to prevent them from overlapping, we obtain the figure below. We see that the pattern of the wiggles keeps changing slightly, but also remains quite similar.
In my last post about this topic I said that it seemed that the wiggles repeated with a period of a sidereal day. Now it is clear that it is not the case. The wiggles seem to repeat roughly with a period of a solar day (24 hours). In fact, in 44 days sidereal time “advances” 2.88 hours with respect to solar time. However, it is clear that the wiggles haven’t shifted that much in time.
In GRCon last year I presented the roadmap for a large refactor of gr-satellites that would eventually be released as gr-satellites v3.0.0. The refactor started near the end of September, and after nearly 8 months I have now arrived at a point where I feel that all the work I’ve done should be packed and released. Not all the ideas I had in my head when I started have made it to the release (some of them require a large amount of work), but I think that the new gr-satellites is still much better than the old one and I would like to start seeing people switching over. Therefore, I have released today v3.0.0-rc1.
Rather than summarising here all the changes that v3.0.0 brings, I invite you to head over to the new gr-satellites documentation and discover by yourselves.
As anything bringing large change, I think that gr-satellites v3.0.0 will probably break some old habits and workflows. However, I hope that it breaks them for good, and that you will find a better workflow with v3.0.0. If not, please head over to the Github issues and let me know what you’re missing in the new release.
A few more notes about project management: starting with this release, I have decided to concentrate all the support and discussion about gr-satellites in the Github issues. This is an idea I’ve stolen from Kate Temkin. In the past I’ve done a lot of discussion with gr-satellites users over email, and while I don’t have any objections to the use of email, Kate makes an extremely good point about the usefulness of having this discussion in public forums. Just the possibility of past issues appearing in Google searches when a user is looking for help makes it worth the effort.
To try to have better coordination with satellite teams planning to use gr-satellites for their missions (a few such as OPS-SAT and Quetzal-1 have already done so), I have written a note for them.
The plan is for v3.0.0-rc1 to become the final v3.0.0 at the beginning of June if no major issues show up. So please go ahead and check out all the new features that v3.0.0-rc1 brings, and let me know in the issues any problems you might find.
During the DSLWP-B (Longjiang-2) mission, we made a number of VLBI observations of the spacecraft’s UHF signal by performing GPS-synchronized recordings at Dwingeloo (The Netherlands), Shahe and Harbin (China), and Wakayama (Japan). The basic measurement for these observations is the time difference of arrival (TDOA), which measures the differences between the time that it takes the spacecraft’s signal to arrive to each of the groundstations. This can be interpreted in terms of the difference of distances between the spacecraft and each groundstation, so this measurement is also called delta-range.
One very interesting practical application of the VLBI observations is to perform orbit determination. The delta-range measurements can be used to constrain and determine the state vector of the spacecraft. This would give us an autonomous means of tracking Amateur deep-space satellites, without relying on ranging by a professional deep-space network. Even though the measurements we made showed good agreement with the ephemerides computed by the Chinese deep-space network, during the mission we never ran orbit determination with the VLBI observations, mainly due to the lack of appropriate software.
While GMAT has good support for orbit determination, it doesn’t support delta-range measurements. Its basic orbit determination data type is two-way round-trip time between a groundstation (or two) and the satellite, as shown in the orbit determination tutorial.
I have started to modify GMAT in the gmat-dswlp Github repository to implement the support for this kind of VLBI observations. As a first step, I am now able to create and simulate delta-range observations.