Over the last few days, I’ve been looking at some recordings of the DSCS-III A-3 X-band beacon made by Scott Tilley VE7TIL. The beacon has a central carrier, which is BPSK modulated at 800baud and whose details we know pretty well due to this Master’s thesis by James Coppola. It also has two subcarriers modulated with 1kbaud BPSK of which we know very little. In this post I explain what I’ve been able to find about the data in this 1kbaud subcarriers (which isn’t that much, to be honest).
Category: Amateur radio
Reverse-engineering the DSCS-III convolutional encoder
One thing I left open in my post yesterday was the convolutional encoder used for FEC in the DSCS-III X-band beacon data. I haven’t seen that the details of the convolutional encoder are described in Coppola’s Master’s thesis, but in a situation such as this one, it is quite easy to use some linear algebra to find the convolutional encoder specification. Here I explain how it is done.
A look at the DSCS-III X-band beacon
The DSCS satellites are a constellation of US military communication satellites. While the constellation is old and it is being replaced by WGS, there are still several active DSCS-III satellites. A few days ago, Scott Tilley VE7TIL tweeted about the DSCS-III-A3 X-band beacon. The satellite DSCS-III-A3, also known as USA-167, is the second most recent DSCS-III satellite, having been launched in 2003. It has an X-band beacon at 7604.6MHz.
Scott’s tweets included a very impressive and interesting find: a Master’s thesis about a DSCS-III beacon decoder made by James Coppola in 1992. The thesis contains a wealth of information about the beacon, as well as the complete C source code for the decoder.
Scott has also been kind enough to share with me some recordings that he made of the beacon, so in this post I’ll be looking at these and how they relate to the information in the thesis.
Ranging through the QO-100 WB transponder
One of the things I’ve always wanted to do since Es’hail 2 was launched is to perform two-way ranging by transmitting a signal through the Amateur transponder and measuring the round trip time. Stefan Biereigel DK3SB first did this about a year ago. His ranging implementation uses a waveform with a chip rate of only 10kHz, as it is thought for Amateur transponders having bandwidths of a few tens of kHz. With this relatively slow chiprate, he achieved a ranging resolution of approximately 1km.
The QO-100 WB transponder allows much wider signals that can be used to achieve a ranging resolution of one metre or less. This weekend I have been doing my first experiments about ranging through the QO-100 WB transponder.
Advances with delta-range and delta-range rate observations in GMAT
A month ago I started modifying the GMAT EstimationPlugin to support delta-range observations. This work is needed in order to perform orbit determination with the VLBI observations that we did with DSLWP-B (Longjiang-2) during its mission. Now I have a version which is able to use both delta-range and delta-range rate observations in simulation and estimation. This is pretty much all that’s needed for the DSLWP-B VLBI observations.
The modified GMAT version and accompanying GMAT scripts for this project can be found in the gmat-dslwp Github repository. This post is an account of the work I’ve made.
Decoding Crew Dragon Demo-2
The launch last Saturday of Crew Dragon Demo-2 undoubtedly was an important event in the history of American space exploration and human spaceflight. This was the first crewed launch from the United States in 9 years and the first crewed launch ever by a commercial provider. Amateur radio operators always follow this kind of events with their hobby, and in the hours and days following the launch, several Amateur operators have posted reception reports of the Crew Dragon C206 “Endeavour” signals.
It seems that the signal received by most people has been the one at 2216 MHz. Among these reports, I can mention the tweets by Scott Tilley VE7TIL (and this one), USA Satcom, Paul Marsh M0EYT. Paul also managed to receive a signal on 2272.5 MHz, which is not in the FCC filing, so this may or may not be from the Crew Dragon.
Scott has also shared with me an IQ recording of one of the passes, and as I showed on Twitter yesterday, I have been able to demodulate the data. This post is my analysis of the signal.
LES-5 telemetry Grafana dashboard
Scott Tilley VE7TIL is making a serious effort and a great job of recording and processing LES-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”.
Update on the QO-100 local oscillator wiggles
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.
gr-satellites v3.0.0-rc1
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.
Simulating delta-range observations in GMAT
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.