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.
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.
In my last post, I spoke about the future lunar impact of DSLWP-B on July 31. Edgar Kaiser DF2MZasked 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.
Future impact of DSLWP-B on the far side of the Moon
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.
Impact of DSLWP-B on the near side of the Moon if a correction manoeuvre is applied
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.
On January 24, the periapsis of the lunar orbit of DSLWP-B was lowered approximately by 500km, so that orbital perturbations would eventually force the satellite to collide with the Moon. This was done to put an end to the mission and to avoid leaving debris in orbit. It is expected that the collision will happen at the end of July, so there are only three months left now for the DSLWP-B mission. Here I look at the details of the deorbit.
I am curious about studying again the Doppler at this point in the mission, to see how accurate the GEO orbit is. I am also interested in collaborating with other Amateurs to perform differential Doppler measurements, as I did with Jean Marc Momple 3B8DU. Here I detail the first results of my measurements.
If you’ve been following my posts about Es’hail 2, you’ll know that shortly after launch Es’hail 2 was stationed in a test slot at 24ºE. It remained in this slot until December 29, when it started to move to its operational slot at 26ºE. As of January 2, Es’hail is now stationed at 26ºE (25.8ºE, according to the TLEs).
The new GEO orbit at 26ºE is much more perfect than the orbit it had at 24ºE. This is to be expected for an operational orbit. Since December 30, I’ve been recording Doppler data of the satellite moving to its operational slot, and I have found some interesting effects of orbital dynamics in the data. This post is an account of these.
Recently, the STRF satellite tracking toolkit for radio observations by Cees Bassa has been gaining some popularity. This toolkit allows one to process RF recordings to extract frequency measurements and perform TLE matching and optimization via Doppler curves. Unfortunately, there is not a lot of documentation for this toolkit. There are some people that want to use STRF but don’t have a clear idea of where to start.
While I have tested very briefly STRF in the past, I had never used it for doing any serious task, so I’m also a newcomer. I have decided to test this tool and learn to use it properly, writing some sort of walk-through as I learn the main functionality. Perhaps this crash course will be useful to other people that want to get started with STRF.
As I have said, I’m no expert on STRF, so there might be some mistakes or omissions in this tutorial that hopefully the experts of STRF will point out. The crash course is organized as a series of exercises that explain basic concepts and the workflow of the tools. The exercises revolve around an IQ recording that I made of the QB50 release from ISS in May 2017. That recording is interesting because it is a wide band recording of the full 70cm Amateur satellite band on an ISS pass on May 29. During a few days before this, a large number of small satellites had been released from the ISS. Therefore, this recording is representative of the TLE lottery situation that occurs after large launches, where the different satellites haven’t drifted much yet and one is trying to match each satellite to a TLE.
The IQ recording can be downloaded here. I suggest that you download it and follow the exercises on your machine. After you finish all the exercises, you can invent your own. Certainly, there is a lot that can be tried with that recording.
A number of supporting files are created during the exercises. For reference, I have created a gist with these files.
