Daniel Estévez – Scientific & Technical Amateur Radio

June 1, 2020June 3, 2020

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.

May 31, 2020May 31, 2020

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”.

May 23, 2020May 23, 2020

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.

May 17, 2020May 17, 2020

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.

May 3, 2020May 3, 2020

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.

April 19, 2020April 19, 2020

Wiggles in the QO-100 local oscillator

Some days ago, Hans Hartfuss DL2MDQ sent me an email about some frequency measurements of the QO-100 NB transponder BPSK beacon that he had been doing. The BPSK beacon is uplinked from Bochum (Germany) through the transponder, and as the beacon is generated using a very good Z3081A GPSDO as a reference, the frequency drift observed on the beacon downlink is caused by Doppler and the drift of the local oscillator of the transponder.

In his measurements, Hans observed some small oscillations or “wiggles” that didn’t seem to be caused by Doppler. Decided to investigate this, I started to do some measurements of my own. This post is an account of my measurements and findings so far.

April 11, 2020April 11, 2020

LES-5 RFI experiment telemetry

In previous posts, I have talked about the attempts of decoding LES-5 telemetry done by Scott Tilley VE7TIL and me. Now Taylor Bates KN4QGM has joined us in our efforts, and with their help I think I have figured out most details of how the telemetry of the RFI experiment works. One of the payloads of LES-5 was a radio frequency interference experiment that scanned the 255-280 MHz band and made spectrum measurements. The receiver of this experiment was also used as the telecommand receiver for the spacecraft. We are very interested in studying the telemetry of this RFI experiment to see to what extent the receiver is working and if the spacecraft could actually receive commands.

April 6, 2020April 6, 2020

Idle data in BepiColombo X-band signal

Yesterday I posted about decoding the data in an X-band recording of BepiColombo. I only made a very shallow analysis of the data, which consisted of CCSDS TM Space Data Link frames. However, I showed that most of the data was transmitted on virtual channel 7. A few hours later, Oleg_meteo in Twitter noted that this data in virtual channel 7 was just a 511 bit PN sequence. After some analysis I’ve confirmed what Oleg_meteo said and shown another interesting and unexpected property of this data.

All the Space Data Link frames in virtual channel 7 have a first header pointer field of 2046, which means “idle data only”. When the payload in these frames is concatenated (there are 8792 payload bits per frame) we obtain an infinite sequence that fits the following description.

April 5, 2020April 5, 2020

Decoding BepiColombo

BepiColombo is a joint mission between ESA and JAXA to send two scientific spacecraft to Mercury. The two spacecraft, the Mercury Planetary Orbiter, built by ESA, and the Mercury Magnetospheric Orbiter, built by JAXA, travel together, joined by the Mercury Transfer Module, which provides propulsion and support during cruise, and will separate upon arrival to Mercury. The mission was launched on October 2018 and will arrive to an orbit around Mercury on December 2025. The long cruise consists of one Earth flyby, two Venus flybys, and six Mercury flybys.

The Earth flyby will happen in a few days, on 2020-04-10, so currently BepiColombo is quickly approaching Earth at a speed of 4km/s. Yesterday, on 2020-04-04, the spacecraft was 2 million km away from Earth, which is close enough so that Amateur DSN stations can receive the data modulation sidebands. Paul Marsh M0EYT, Jean-Luc Milette and others have been posting their reception reports on Twitter.

Paul sent me a short recording he made on 2020-04-04 at 15:16 UTC at a frequency of 8420.535MHz, so that I could see if it was possible to decode the signal. I’ve successfully decoded the frames, with very few errors. This post is a summary of my decoding.

April 4, 2020April 4, 2020

Earth rotation corrections for range and range-rate in GNSS

In GNSS, when considering the propagation of signals from the satellites to a receiver, it is easier to work in an ECI reference frame, since (ignoring the gravitational potential of Earth), light travels in straight lines in ECI coordinates. However, it is often common to do all the calculations in an ECEF frame, as the final goal is to obtain the receiver’s position in ECEF coordinates, and the ephemerides also use ECEF coordinates to describe the satellite positions. Therefore, a non-relativistic correction needs to be applied to account for the fact that light no longer travels in straight lines when one considers ECEF coordinates. Often, the correction is done as some kind of approximation. These types of corrections are known in the GNSS literature as the Sagnac effect.

The goal of this post is to discuss where the corrections arise from, the typical approximations that can be made, and how these corrections affects the calculation of range and range-rate. I didn’t find a good source in the literature where this is described in detail and in a self-contained way, so I decided to write it myself.