As promised in this post, I will now speak about how to demodulate the Tianwen-1 telemetry signal. This post will deal with demodulation and FEC decoding. The structure of the frames will be explained in the next post. In this post I also give a fully working GNU Radio decoder that can store frames in the format used by the orbit state vector extraction Python script.
In my previous post I explained how our problems using the orbit state vectors transmitted in the telemetry of Tianwen-1 were caused by an incorrect interpretation of the timestamps attached to these vectors. The timestamp is a 32 bit counter with a 100us resolution, but the difficulty is that the epoch of this counter is not known. It seems that the epoch is around 2020-07-23 00:00 UTC, which is the day of launch, but not quite because approximately 57 minutes need to be subtracted from the epoch.
In my post I used some sort of experimental procedure to determine the correction that needs to be subtracted from the timestamp, and I obtained 3400.2 seconds, which I believe should be accurate to within a few seconds.
However, I found this correction somewhat unsatisfactory, as I wasn’t able to explain where it comes from. Now I think I have found a reasonable explanation.
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.
Last Sunday 2020-07-19, the first mission of United Arab Emirates to Mars, known as Emirates Mars Mission “Hope probe” launched from Tanegashima, Japan. This probe is expect to reach Mars in approximately 200 days and study its atmosphere over the course of two years. The scientific instruments onboard the probe are a digital camera, an infrared spectrometer, and an ultraviolet spectrometer.
Shortly after launch, several Amateur radio operators and Amateur spacecraft trackers received signals from the X-band beacon of the Hope probe at 8402.655 MHz and posted reports on Twitter, such as Paul Marsh M0EYT, Ferrucio IW1DTU, Edgar Kaiser DF2MZ, and others. Since the spacecraft was still near Earth, its signal was so strong that a data modulation with a main lobe of approximately 20kHz wide and several sidelobes could easily be seen in the spectrum, which is shown below.
Paul has been quite kind to send me a recording that he made with his station on 2019-07-19 at 23:29 UTC and I have been decoding the data in GNU Radio and looking at the frames. The recording can be downloaded here (193MB). It is an
int16 IQ recording at 99998 samples per second. This post is an account of my results.
Back on January, I did a post with a simulation about the DOP distribution for the Galileo and GPS constellations. In there, I computed the DOP for a grid of points on the surface of the Earth and then plotted maps with the average and worst DOP. I used three different kinds of constellation definitions, both for Galileo and for GPS: the base constellation, which has 24 satellites in both cases; an expanded constellation, which in the case of Galileo adds 6 spares and in the case of GPS has 27 satellites as defined in the 2008 SPS performance standard; and a real life constellation taken from the almanac at the beginning of January.
Since I wrote that post, the 2020 SPS performance standard came out in April. This defines a new expandable reference constellation of 30 satellites. Besides the three expandable slots on planes B, D and F, three new expandable slots are added on planes A, C and E, so that now there is one expandable slot per plane. All the RAANs and mean anomalies corresponding to the slots have also been updated, since the constellation is now referenced to an epoch on 2016 (the previous one had an epoch on 1993).
I have now run again my simulations using the 30 satellite expandable constellation, which provides a closer model to the real life constellation. Here I show briefly the results.
BY02 (also known as BY70-2) is an Amateur cubesat by the China Aerospace Science and Technology Corporation and Beijing Bayi High School. It was launched on July 3 on a CZ-4B rocket from Taiyuan together with a Gaofen Earth observation satellite. BY02 is intended as a replacement for BY70-1, which was launched on 2016-12-28 and was placed on a short-lived orbit that decayed in a few months because of a launch problem.
Today, Wei Mingchuan BG2BHC announced on Twitter at 09:14 UTC that BY02’s beacon was on and would be left on at least until 12:50 UTC. I believe that this is the first time that the beacon has been on for an extended period of time, since during the early operations the beacon was only active on passes over China.
Since at 11:39 UTC there was a good pass over Spain, I went outside with my handheld Arrow 7 element yagi to do a recording. This post is an in-depth analysis of this recording and includes an explanation of the coding and telemetry format used by BY02.
In my previous post I looked at the BGDs and related topics for the Galileo satellites. We saw that satellite E24 has atypically large BGDs, but everything else seems fine and consistent with that satellite. However, Bert Hubert from galmon.eu shows that several RTCM sources broadcast a clock correction of around -5ns for E24. Here we look at the possible causes for that correction, and discuss whether it might be problematic.
A few days ago, Bert Hubert, from galmon.eu noticed that Galileo satellite E24 was somewhat special because it had unusually large BGDs. This raised a number of questions, such as what is the physical interpretation of BGDs, what they have to do with broadcast clock models, and so on.
In this post I will explain a few basic facts about BGDs and related topics, following an approach that is perhaps different to that of the usual GNSS literature, and also study the current values for the Galileo constellation. People who know all the details about the BGDs or who just want to see a few pretty plots can skip all the first section of the post.