Last Thursday 2020-07-23 at 04:41 UTC, Tianwen-1, a Chinese mission to Mars consisting of an orbiter, a lander and a rover, launched from Wenchang. Usually, I would be posting an analysis of a recording of the telemetry signal, made by Paul Marsh M0EYT or another of my Amateur DSN contributors, as I did a few days ago for the Emirates Mars Mission. However, something amazing has happened that has kept me quite busy. Rest assured that the analysis of the signal will come in a future post, but here I’m going to tell a story about Tianwen-1’s orbit.
Tag: orbital dynamics
ESA NEOCC riddle 1
A few weeks ago, the ESA Nearth Earth Object Coordination Center started a series of NEOCC riddles about Near Earth Object orbits and related topics. The first riddle was about orbits with a peculiar characteristic: they spend 50% of the time inside some fixed radius from the Sun (1.3au in the riddle), and the remaining 50% of the time outside this radius. It was published on June 4. Shortly after that I submitted my solution. The deadline for sending solutions ended yesterday, so today NEOCC has published their solution together with the list of people that solved the riddle correctly. In this post I publish my solution and make some additional comments.
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.
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.
DOP geographical distribution for the Galileo and GPS constellations
I have been wondering about how the DOP for the different GNSS constellation varies geographically, owing to the different number of satellites and constellation geometries. There are many DOP maps, such as this Galileo HDOP map by the Galileo System Simulation facility, but after a quick search in the literature I couldn’t find any survey paper that made a comprehensive comparison. The closest thing I found to what I was looking for was Consellation design optimization with a DOP based criterion, by Dufour etl. This was published in 1995, so it compares the GPS and GLONASS constellations with prototypical constellations such as the Walker delta using different parameters, but it doesn’t mention Galileo, which wasn’t even planned back then.
Therefore, I have decided to do my own simulations and compare the DOP for the Galileo and GPS constellations. Since the actual distribution of the satellites can differ substantially from the slots designated in the constellation, I am considering both the theoretical reference constellations and the real world constellations, as taken from the almanacs at the beginning of 2020. This post is a detailed account of my methodology and results.
Trying to find the DSLWP-B crash site
As you may well know, DSLWP-B, the Chinese lunar orbiting Amateur satellite crashed with the Moon on July 31 as a way to end its mission without leaving debris in orbit. I made a post with my prediction, which showed the impact point southeast of Mare Moscoviense, in the far side of the Moon. Phil Stooke was more precise and located the impact point near the Van Gent crater.
Our plan is to get in contact with the LRO team and try to find the crash site in future LRO images. We are confident that this can be done, since they were able to locate the Beresheet impact site a few months ago. However, to help in the search we need to compute the location of the impact point as accurately as possible, and also come up with some estimate of the error to define a search area where we are likely to find the crash. This post is a detailed account of my calculations.
Precise orbit determination for Lucky-7
In one of my previous posts, I used measurements from the GPS receiver on-board the Lucky-7 cubesat in order to find the TLE that best matched its orbit, and help determine which NORAD ID corresponded to Lucky-7.
Now I have used the same GPS measurements to perform precise orbit determination with GMAT. Here I describe the results of this experiment.
Lucky-7 TLE matching using GPS data
SkyFox Labs is having some trouble identifying the TLE corresponding to their Lucky-7 cubesat. The satellite was launched on July 5 in launch 2019-038 and a good match among the TLEs assigned to that launch has not being found yet. Over on Twitter, Cees Bassa has analyzed some SatNOGS observations and he says that NORAD ID 44406 seems the best match. However, this TLE has already been identified by Spire as belonging to one of their LEMUR satellites.
Fortunately, Lucky-7 has an on-board GPS receiver, and the team has been collecting position data recently. This data can be used to match a TLE to the orbit of the satellite, and indeed is much more accurate than the Doppler curve, which is the usual method for TLE identification.
Jaroslav Laifr, from the Lucky-7 team, has sent me the data they have collected, so that I can study it to find a matching TLE. The study is pretty simple to do with Skyfield. I have obtained the most recent TLEs for launch 2019-038 from Space-Track and computed the RMS error between each of the TLEs and the GPS measurements. The results can be seen in this Jupyter notebook.
The best match is NORAD ID 44406, with an RMS error of 8.7km. The second best match is NORAD ID 44404 (which is what SatNOGS has been using to track Lucky-7), with an RMS error of 51.3km. Most other objects have an error larger than 100km.
Therefore, my conclusion is clear. It is very likely that Spire misidentified NORAD ID 44406 as belonging to LEMUR 2 DUSTINTHEWIND early after the launch, when the different objects hadn’t drifted apart much. NORAD ID 44406 is a good match for Lucky-7. It will be interesting to see what Spire says in view of this data.
DSLWP-B lunar impact location
A few days ago, I spoke about the future impact of DSLWP-B on the lunar surface, which will happen in the far side of the Moon around the end of July, and how the spacecraft could be manoeuvred to make the impact point fall on the near side of the Moon instead, so that it can be observed from Earth.
Philip Stooke made a very good remark in the comments saying that the impact might have been planned on the far side of the Moon deliberately in order to avoid Apollo landing sites and other heritage sites. This is a very valid concern. By all means, the crash should be planned to avoid disturbing heritage sites or other areas of specific interest.
DSLWP-B lunar impact prediction
In my last post, I spoke about the future lunar impact of DSLWP-B on July 31. Edgar Kaiser DF2MZ asked over on Twitter if the impact would be visible from Earth. As I didn’t know the answer, I have made a simulation in GMAT to find this out.
The figure below shows the orbit of DSLWP-B between July 28 12:00 UTC and the moment of impact, on July 13 14:47 UTC. The orbital state used for DSLWP-B is the 20190426 tracking file from dslwp_dev. The reference frame is arranged so that the +X axis points towards the Earth, and the Y axis lies on the Earth-Moon orbital plane. As we can see, unfortunately, the impact will happen on the far side of the Moon, where it is not observable from Earth.
However, it is possible to arrange a manoeuvre to modify the orbit slightly and make the impact point fall on the near side of the Moon, where it is visible from Earth. In the previous post we observed that, ignoring the collision with the lunar surface, the periapsis radius would continue to decrease after July 31, until reaching a minimum value in January 2020.
Therefore, it is possible to raise the periapsis radius slightly in order to delay the collision approximately half a lunar month, so that the periapsis faces the Earth at the moment of impact. The delta-v required to make this manoeuvre is small, as the adjustment to the orbit is subtle.
For instance, performing a prograde burn of 7m/s at the first apoapsis after July 1 delays the collision until August 13, producing an impact in the near side of the Moon. The resulting orbit can be seen in the figure below, which shows the path of DSLWP-B between July 28 and the moment of impact.
Adjusting the delta-v more precisely would make it possible even to control the time of the impact, so as to guarantee that the Moon will be in view of the groundstations at China and The Netherlands when the collision happens. However, this adjustment requires a very precise delta-v and is quite sensitive to the orbital state, so perhaps it is not feasible without performing a precise orbit determination and maybe some smaller correction manoeuvres following the periapsis raise.
Another possible problem that can affect the prediction of the impact point are the perturbations of the orbit caused by the lunar mascons, which can be noticeable when the altitude of the orbit starts getting small, and which haven’t been considered very carefully in this simulation (the non-spherical gravity of the Moon was only simulated up to degree and order 10).
The GMAT script used for this post can be found here.