Yesterday I published a post explaining how Tianwen-1 is transmitting real time state vectors for its own orbit in its telemetry and how we’ve used those to propagate its orbit and track the spacecraft with the Bochum observatory 20m dish. However, there seemed to be some problem in the way we were interpreting the state vectors, since the ephemerides derived from these had a pointing error of a few degrees when compared with observations from Bochum and other smaller Amateur stations.
As of writing that post, I believe I have found the problem. It has to do with the way that the timestamps from the state vectors are interpreted. After correcting this problem I am getting an orbit that matches the observations well. Here I explain this problem and show some more details about the corrected ephemerides.
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.
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.
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.
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.
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.
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.
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.
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.
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.