• Tianwen-1 remote sensing orbit

    On November 8, the Tianwen-1 orbiter made a manoeuvre to move itself to the remote sensing orbit, as reported by Chinese media. This orbit is the final orbit in the mission, as depicted in this figure from Wikipedia. The main goal of this orbit is to study the geophysical properties of Mars with all the orbiter instruments (see this paper) and to continue acting as a communications relay for the rover Zhurong.

    As usual, AMSAT-DL has been collecting telemetry from Tianwen-1 with the 20 metre antenna at Bochum observatory, including spacecraft state vectors. This allows us to study the orbit change manoeuvre and the properties of the remote sensing orbit. This post is a first look at the state vector data.

    The last state vector received by AMSAT-DL before the orbit change manoeuvre was:

    2021-11-08 10:21:08.224700 -1514.7500329949896 5445.415055351603 1023.398127898517 0.38327883545518154 -2.0631665185917996 2.482739708978983

    Shortly after receiving this state vector, the telemetry signal was lost at Bochum, probably due to the spacecraft changing to the low gain antenna for the orbit change manoeuvre.

    The first state vector received by AMSAT-DL after the orbit change was already on the next day:

    2021-11-09 10:42:09.169800 1786.3925178639424 -3521.8603918686213 -12884.286672718548 -0.21100179119659598 0.9822409035982982 -0.7303411191821157

    The orbital parameters before the orbit change were:

    • Inclination: 86.3 deg
    • Period: 1/3 Mars sidereal day + 114 seconds
    • Periapsis altitude: 407 km
    • Apoapsis radius: 15895 km
    • RAAN: 104.9 deg
    • Argument of periapsis: 94.0 deg

    The parameters of the new orbit are

    • Inclination: 86.3 deg
    • Period: 2/7 Mars sidereal days + 170 seconds
    • Periapsis altitude: 275 km
    • Apoapsis radius: 14138 km
    • RAAN: 104.8 deg
    • Argument of periapsis: 88.4 deg

    There are several things to note here. The first is that since the beginning of September, the periapsis has moved north and was almost over the north pole before the orbit change. In September the argument of periapsis was 121.8 deg (see this post), so it has changed by 27.8 deg. We have also seen that the periapsis moved north between June and September (it was roughly over the equator in June). In principle, we don’t know whether this movement of the periapsis was caused by manoeuvres or by natural orbit perturbations, since we don’t have a continuous time series of data from Bochum (due to the dish motors failing in June and the Mars solar conjunction in October).

    The second remark is that the orbit period is very close to 2/7 of a Mars sidereal day. This gives a ground track that repeats every 2 Mars sidereal days, after 7 revolutions, and so it is good for scheduling communications with the rover (and probably also for some remote sensing tasks).

    This news article gives more information about these things. I’m using Google translate to read it, so some details might not be completely accurate. The article states that remote sensing with high resolution can be achieved from low altitude, and that the periapsis moves in latitude due to orbital perturbations. First it moves from south to north, and then from north to south. Due to this movement, all the surface of Mars can be surveyed from a low altitude.

    This south to north movement is just what we have been seeing between June and November, so it seems that the cause is natural perturbations. To understand this better, it might be interesting to revisit the techniques I used for the analysis of Longjiang-2’s elliptical lunar orbit perturbations, though in that case the main perturbing force was Earth’s gravity. In this case it will be either the non-spherical gravity of Mars, the gravity of the Sun, or a combination of both.

    The article also mentions that the orbiter does 3.47 revolutions per “day” (understood as a Mars sidereal day). This is a bit less than 3.5 = 7/2, and agrees with the fact that the period we are seeing is slightly larger than 2/7 sidereal days. Arguably, this difference in period from the nominal 2/7 sidereal days could be corrected with station keeping manoeuvres, and in fact we have seen such deviations in the reconnaissance and communications orbits, which were station kept to pass over the rover’s location. However, the period slightly longer than 2/7 sidereal days is probably intended, and would agree with the 3.47 revolutions quoted in the article. This would cause the ground track to slowly drift west, at a rate of 4.8 degrees per 2 sidereal days (or 7 revolutions), giving equal coverage to all the surface of Mars. This advantage of a non-repeating ground track is also mentioned in the article.

    The remote sensing orbit is shown in the figure below in inertial coordinates. We see that the periapsis is almost over the north pole of Mars.

    Remote sensing orbit in inertial coordinates

    In Mars-fixed coordinates the orbit is repeating (or almost repeating). After 7 revolutions the spacecraft is close to where it started. The orbit roughly traces some of the diagonals of a heptagon. In particular, there are seven longitudes along which the spacecraft descends from north to south or ascends from south to north. The figure below shows the view from the north pole.

    Remote sensing orbit in Mars-fixed coordinates (north pole view)

    The view from the south pole shows a similar heptagonal pattern.

    Remote sensing orbit in Mars-fixed coordinates (south pole view)

    The ground track shows the seven longitudes along which the spacecraft ascends and descends. Presumably the ground track would drift west at a rate of 4.8 degrees per 2 Mars sidereal days.

    Remote sensing orbit ground track

    Let us call “tracks” these seven longitudes along which the spacecraft ascends and descends. Currently, the rover Zhurong is more or less in the mid point between two of these tracks. The separation of 360/7 = 51.4 degrees between adjacent tracks is probably small enough that the rover can use the passes along its two closest tracks to stablish communications with the orbiter. If these is true, the number of potential communication sessions would be 4 for each 2 sidereal days.

    As usual, I have compared the pre-burn and post-burn state vectors with the goal of measuring the delta-v of the burn. In this situation where both the periapsis and apoapsis altitudes have changed, in principle it would be possible to have two burns: one around periapsis, to lower the apoapsis, and one around the next apoapsis, to lower the periapsis. Since there is a gap of roughly one day (which corresponds to more than 3 revolutions) in the data collected by Bochum, we wouldn’t be able to distinguish the effects of each of the burns separately.

    However, this doesn’t seem to be the case. The trajectory propagated forwards with the pre-burn state vector and the trajectory propagated backwards with the post-burn state vector intersect roughly at the time when the first burn would happen. This supports the idea that only one burn was made. The figure below shows the distance between the pre-burn and post-burn trajectories. There is a clear intersection at 11:30:02 UTC (spacecraft event time), where the minimum distance of 2.7 km is achieved.

    This places the single burn at 11:30 UTC. The periapsis was passed at 10:49 UTC.

    According to the change in the velocity vector of these trajectories, the magnitude of the delta-v was 81.1 m/s. This matches quite well the figure of 78 m/s given in this news article. The delta-v vector in Mars-centric body inertial coordinates was

    [-14.52,  36.69,  70.86] m/s

    In the VNB frame this gives

    [-80.45,  -0.09, -10.32] m/s

    As expected, the burn happened in-plane, since N is close to zero. Most of the burn went into the -V component, in order to lower the apoapsis. However, there is also a noticeable component of the burn along the -B vector. The effect of burning along -B is, roughly speaking, to lower the half of the orbit following the burn and raise the half of the orbit preceding the burn. In this case it might happen that if only a burn along -V was done to lower the apoapsis, then the final periapsis altitude would be too low. In any case, for this kind of single-burn transition between orbits, the location of the burn and the delta-V vector needs to be assessed carefully to choose the optimal manoeuvre, so it’s not easy to explain why this orbit change was done in this particular way without further study.

    The plot below compares the orbit altitude of the pre-burn and post-burn trajectories, in an span of a few hours around the burn, which is marked with a vertical line. The altitude is shown in a logarithmic scale. The two trajectories intersect at the burn, but elsewhere the post-burn trajectory is always lower than the pre-burn trajectory.

    Since I’ve lost track of the mass of the orbiter after the rover was released, it isn’t easy to estimate the burn duration or the fuel spent. The news say that four 120 N thrusters were used for 260 seconds, so assuming a specific impulse of 321.6 s, that would give a spacecraft mass of around 1600 kg, and a fuel consumption of 41 kg.

    The GMAT script used for the calculation of the pre-burn and post-burn trajectories can be found here. The remaining computations and plots have been done in this Jupyter notebook.

  • An update about Lucy’s telemetry

    In my previous post I presented a description of the X-band telemetry of Lucy, including a GNU Radio decoder, some recordings from the Allen Telecope Array, and an analysis of some of the telemetry received in the two days following the launch. This is a short post with some updates about the telemetry analysis of the Lucy mission.

    As described earlier, immediately after launch Lucy was using 60 kbaud (~10 kbps) PCM/PSK/PM with a subcarrier of 281.25 kHz, using r=1/6 Turbo coding. At some point before 2021-10-19 19:55 UTC, it changed its modulation to 120 kbaud (~20 kbps), maintaining the rest of the parameters. A couple days later, before 2021-10-21 20:41 UTC, it changed the modulation again to PCM/PM/NRZ, that is, baseband residual-carrier phase modulation. A baudrate of 300 kbaud was used to achieve a net rate of ~50 kbps. The Turbo code parameters stayed unchanged. The spacecraft has remained in this mode since then.

    Since my last post, I have analyzed the following recordings. On 2021-10-19, Iban Cardona EB3FRN made some recordings with his 2.4 metre dish. Lucy was already using 120 kbaud, and the SNR was borderline to decode. I tried to optimize the decoder, and made this flowgraph. Only around 35% of the frames could be decoded successfully. In one of the recordings the decodes stopped after a few minutes, even though an SNR drop wasn’t noticeable. Still, the decodes were enough to take a look at the telemetry (see the Jupyter notebook).

    Comparing this data with the one I obtained with ATA on 2021-10-17, it was apparent that some telemetry values that on 2021-10-17 seemed completely stationary, on 2021-10-19 had started to change with time. In particular, among keys 1202-1210 from APID 5, the only one which changed with time on 2021-10-17 was 1206, which showed a very clear linear slope. However, on 2021-10-17 all of these keys except 1208-1210 showed a linear slope.

    As an example, this figure shows key 1204 on the UTC morning of 2021-10-17. We see that the average value is 0.462, and the value only oscillates 2e-6 about the average.

    However, on the UTC evening of 2021-10-19 the behaviour changed, and we can see the value of key 1204 change linearly with time. The gap between 21:35 and 21:50 corresponds to the gap between the two recordings that Iban made.

    Still I have no clue of what these telemetry values are, but the fact that we can notice a change in their behaviour comparing the data from 2021-10-17 and 2021-10-19 is interesting.

    The APIDs in use on 2021-10-19 and their distribution seems to be more or less the same as in 2021-10-17, and other characteristics such as the number of virtual channels haven’t changed either.

    Iban also made some recordings on the UTC evening of 2021-10-20 UTC. Only very few frames could be decoded from these recordings, but this is in fact amazing, since the increase in free space path loss placed the SNR below decoding threshold. The telemetry is analysed here. It is very similar to that recorded on 2021-10-19. After this day, given the change to 300 kbaud and the further increase in path loss, it would be completely impossible for Iban’s 2.4 metre dish to decode anything.

    On the UTC morning of 2021-10-23 I made a long recording with ATA using two 6.1 metre antennas. Using the RHCP data from only one of the antennas, the SNR is not good enough, and only a few frames can be decoded. I hope that with the 3dB SNR increase that comes from arraying the two antennas I’ll be able to decode most of the frames. However, I haven’t done this yet, since I need to prepare something to correct for the delay difference between the antennas, and to adapt my auto-polarization block to work with 4 channels instead of 2 (so that it does phase-only beamforming by using the residual carrier as a phase reference).

    Peter Gülzow DB2OS, from AMSAT-DL, used the 20 metre antenna at Bochum observatory to record some IQ data on 2021-10-24. I decoded the 300 kbaud signal with this flowgraph and obtained the frames that are analysed here. The recording lasts 4 minutes, and almost all of the frames could be decoded correctly, since the SNR was good.

    The behaviour of the telemetry seems very similar to that decoded from Iban’s recording. I would say that there hasn’t been any major change in the telemetry since the change to the high-gain antenna and the change to 120 kbaud. It is noteworthy that the rate at which real-time telemetry is sent is still quite low, so with a 50 kbps signal most of the frames are idle.

    As always, all the data, flowgraphs and telemetry analysis I have for Lucy can be found in this folder.

  • Decoding Lucy

    Lucy is a spacecraft that will study the Trojan asteroids, during a twelve year mission. It was launched last Saturday at 9:34 UTC from Cape Canaveral on an Atlas V rocket. Its telemetry downlink is on X-band, at a frequency of 8445.768 MHz.

    Iban Cardona EB3FRN made a 30 minute recording of the telemetry downlink at 19:00 UTC on Saturday, as the spacecraft first appeared over Europe after launch. r00t.cz did a brief analysis of this recording overnight, and then published some more details about the telemetry data. On Sunday, at 8:52 UTC, I did a long recording with one of the dishes in the Allen Telescope Array. This recording lasts 3 hours 26 minutes, and ends when the spacecraft set below the 16 degree elevation mask of the ATA. In this post I give a first analysis of the telemetry data in both recordings.

    The recording done at ATA can be downloaded from the following datasets in Zenodo:

    Iban used a 2.4 metre antenna and RHCP polarization, and the ATA dishes are 6.1 metre and have dual linear polarization. The SNR in both recordings is enough to decode the telemetry, though unfortunately in Iban’s recording there is loss of IQ samples, which makes decoding of many frames fail.

    The telemetry downlink is modulated using PCM/PSK/PM with the telemetry on a subcarrier whose frequency is approximately 281.25 kHz. The symbol rate is 60 kbaud, and the coding is CCSDS r=1/6 Turbo code with 8920 bit frames. The data link frames are CCSDS AOS frames with the usual CRC-16 in the frame error control field.

    During these two recordings the spacecraft was still using its low gain antenna. As of 2021-10-19 19:55 UTC it has changed to the high gain antenna and doubled the symbol rate to 120 kbaud.

    The figure below shows the GNU Radio decoder flowgraph used for the ATA recording. It has an auto-polarization block that combines the two linear polarizations with the appropriate coefficients that maximise the SNR (so RCHP is synthesized taking into account phase offsets and gain offsets). The rest of the decoder is quite similar to other decoders of deep space probes shown in this blog. The flowgraph uses some blocks from gr-satellites and the Turbo decoder from gr-dslwp.

    Lucy decoder GNU Radio flowgraph

    The GNU Radio flowgraph used to decode Iban’s recording is lucy_eb3frn.grc, and the flowgraph used to decode the ATA recording is lucy_ata.grc.

    The figure below shows the GNU Radio decoder processing Iban’s recording. The top plot shows the symbols in the time domain. The middle plot shows the spectrum at the output of the PLL, with the real part in blue, which contains the residual carrier, and the imaginary part in red, which contains the data sidebands. The bottom plot is the constellation diagram, in which we can see the two BPSK symbols even though the constellation is noisy.

    Lucy decoder GNU Radio flowgraph GUI

    The AOS frames use spacecraft ID 0x31, matching the SANA registry. There are two virtual channels in use: virtual channel 0, which contains telemetry data, and virtual channel 63, which contains Only Idle Data (as it should, since virtual channel 63 is reserved for that purpose).

    Interestingly, the frames in virtual channel 63 contain an M_PDU header with the first header pointer value of 2046, indicating that the packet zone contains only idle data. From reading the blue book, I think it is more common not to have an M_PDU header in the frames in the Only Idle Data virtual channel. The packet zone of these idle frames is filled with 0xaa bytes.

    Virtual channel 0 contains CCSDS Space Packets using M_PDU. The Space Packets contain a 5 byte secondary header. The first four bytes are a timestamp given as the seconds elapsed since the J2000 epoch (2000-01-01 12:00 UTC), and the fifth byte probably indicates fractions of a second, but it is difficult to be sure of this.

    The figure below shows the APIDs in use in the recording done with ATA. APID 2047 is the APID dedicated to idle packets, which are filled with 0x55 bytes. Most of APIDs have packets of different lengths.

    In the recording done earlier by Iban the distribution of the APIDs in use is slightly different, perhaps hinting at some changes in the enabled subsystems between the two recordings. The plot is shown below. Due to the lost IQ samples in Iban’s recording, only about 40% of the AOS frames could be decoded correctly. Even so, the decodes are good enough to get an idea of what was being transmitted. The lack of APIDs 7 and 1032 is interesting. Looking again at the ATA’s data, it seems that APIDs 6 and 7 are mutually exclusive, and that APID 1031 and 1032 are only sent when APID 7 is sent.

    Given that we have only one frame from APID 4, it is very difficult to get an idea of what it contains. APID 5 is perhaps the most interesting (or easiest to reverse-engineer). The dump of this APID from the ATA recording is shown below. Each row of the image corresponds to one packet, and shows all the bytes of the packet except for the primary header. Bytes are colour coded using the Viridis colour map (purple is 0x00 and yellow is 0xff).

    As r00t has pointed out, this APID contains fields following a key-value scheme. The keys are two bytes long, and the values can be either 2, 4 or 8 bytes long and have integer or floating point format depending on the key. All the packets in this APID are laid out in exactly the same way, with the same keys in the same positions, so it is not difficult to guess which positions correspond to keys and what are the lengths of their corresponding values.

    I have obtained a complete list of the keys and their data types used in APID 5. I have noticed that some of the values that r00t interpreted as int32 make more sense when interpreted as float32 (in fact, for those fields that have values centred on zero the difference can be spotted due to the fact that floats are encoded in sign-magnitude format and ints are encoded in two’s complement). Still, for some fields it is not clear from the data if they should be interpreted as floats or ints, or whether they are signed or unsigned ints.

    It is difficult to guess what telemetry value each of these keys is encoding. When plotted, many keys look more or less like Gaussian noise (maybe not completely Gaussian, but Gaussian-like). The most peculiar keys are plotted below.

    According to r00t, APID 6 also contains data in key-value format, but it is more difficult to parse because the packets have different lengths and contain the keys in different orders. I haven’t looked at the data in this APID in detail. Here is a plot of its contents in the ATA recording. Since there are frames of different length, here and in the plots below the shorter frames have been zero padded on the right to make them all have the same length.

    APIDs 7 and 8 are very similar to APIDs 5 and 6 respectively, so even though I haven’t looked at them in detail it seems that they have the same structure. Here are their contents.

    APID 1028 contains mostly static data. APIDs 1029 through 1032 are very interesting. It is not obvious what they contain. At first they might appear to have very high entropy, but when many packets are plotted it is apparent that the data is not uniformly distributed. It seems that APIDs 1029 and 1031 have the same structure, and also APIDs 1030 and 1032 have the same structure.

    APID 2047 is not interesting, as it only contains idle packets of different lengths.

    The analysis of the frames was done in this Jupyter notebook for Iban’s recording, and in this one for ATA’s recording. The same folder in the repository also contains binary data files with the decoded frames. The frames in these files are stored back-to-back. Each frame has a size of 1113 bytes, since the CRC-16 is removed by the GNU Radio decoder.

  • GNU Radio 3.9 in Buildroot

    Recently I’ve had to cross-compile GNU Radio for an ARM embedded system. I have decided to use Buildroot to build GNU Radio and its dependencies, since I’m fairly familiar with using Buildroot to generate embedded Linux images. Earlier this year, Jean-Michel Friedt and
    Gwenhaël Goavec-Merou     presented in FOSDEM their work about adding a GNU Radio package in buildroot. They gave a talk called “Never compile on the target!“.

    Unfortunately, the version they used was GNU Radio 3.8, and the package hasn’t been updated to GNU Radio 3.9 yet. I wanted to use GNU Radio 3.9, so I decided to try to update the Buildroot package. After some assorted problems, I have managed to get GNU Radio 3.9 running on my ARM target. The fixes I’ve done are really horrible, so I’ve been quite tempted not to share my changes. I’ve finally decide to share this even though it’s far from perfect, because it might save someone from having to replicate this work, and because if anyone wants to do this properly and update the upstream package, this could be useful as a starting point.

    The changes to the Buildroot tree are in the gr39 branch of my Github fork of Buildroot. This patch applies against the current stable release, which is the 2021.08 tag, but it could possibly apply cleanly to other versions.

    These are the difficulties I’ve had to solve. First, the detection of NumPy with CMake didn’t work, even though NumPy was correctly installed to the STAGING and TARGET directories, and in fact it was possible to import numpy in the target. I am not totally sure how this works, but from glancing at GrPython.cmake, it seems to me that this runs the host Python and tries to import NumPy. This seems bound to give problems, because NumPy has been built for the target, and might not be present in the host. To get around this problem, I have simply modified the CMakeLists.txt so that not finding NumPy doesn’t cause a fatal error.

    A related problem is that, during the build, some .h header files from NumPy could not be found, because the correct include path wasn’t passed to g++. I tried without success to use -DNUMPY_INCLUDE_DIR when running cmake (inspired by this). Finally, I’ve decided not to spend more time and set this by hand in -DCMAKE_CXX_FLAGS.

    After getting GNU Radio to build, I found a real oddity. The library libgnuradio-digital.so had an undefined symbol: gr::digital::map_bb_impl::s_map_size. This is a static constexpr that is only used in a few places in map_bb_impl.h and map_bb_impl.cc.

    Why g++ would create a symbol for this instead of just replacing the constant value in the generated code escapes me. I’ve tried to search for some clues and understand the subtleties of constexpr, but after finding some references to ODR-used and remembering this joke, I decided to replace the static constexpr by a #define macro.

    Finally, the dynamic libraries generated by pybind11 are missing the .so extension in the target directory. This will give import errors in Python. They need to be renamed to add the .so extension. I haven’t included this in the patch in my gr39 branch, because I renamed them by hand. These libraries are found in usr/lib/python3.9/site-packages/gnuradio and usr/lib/python3.9/site-packages/pmt in the target directory and have names ending in _python, such as blocks/blocks_python. They should be renamed to blocks/blocks_python.so, etc. I haven’t investigated why this happens.

    And this is it. Hopefully someone will find this post useful eventually.

  • Tianwen-1 communications relay orbit

    As you may have seen in my last post, lately I have been reviewing some of data we have from Tianwen-1. In the days following the landing of Zhurong, back in May, we had so much data in our hands that I couldn’t post about it in a timely manner. We were wondering if we could use this data to plan for a number of experiments with the 20 meter antenna at Bochum observatory. These included trying to receive data from the rover relayed by the orbiter, and trying to detect the rover’s direct X-band link to Earth. We didn’t manage to do any of these, unfortunately, as they had a great deal of luck involved.

    During the summer I’ve been involved in several activities such as collaborating with the SETI Institute and BSRC REU summer student programmes by teaching some GNU Radio lessons, and preparing material for GRCon21 (a talk, a workshop and paper). Now I have more time at hand, so it’s good to revisit this data. In this post I’ll look at Tianwen-1’s orbit after the release of the lander.

    On May 14, Tianwen-1 released the rover Zhurong on the surface of Mars. I reported the event in this blog post. After the collision avoidance burn, the orbiter still remained on orbit with a period of nearly 2 Mars sidereal days. This orbit had an apoapsis radius of 60970 km, a periapsis altitude of 442 km, an inclination of 89.2 deg, and argument of periapsis of 163.7 deg.

    The periapsis of this orbit was passed on 2021-05-17 00:28:32 UTC. In this moment, Tianwen-1 made a manoeuvre to lower the apoapsis and pass to an orbit with a period of 1/3 of a Mars sidereal day. The first telemetry indicating this change that was received by AMSAT-DL with the 20 metre antenna at Bochum observatory corresponded to 2021-05-17 08:59:26 UTC (spacecraft time). By then, the spacecraft had already passed the first apoapsis of the new orbit, at around 08:40 UTC. According to the telemetry, the new orbit had a periapsis altitude of 266 km, so apparently a periapsis lowering burn was made at the 08:40 UTC apoapsis. The apoapsis radius was 16011 km, the argument of periapsis 175.6 deg (a slight change from the 2 day orbit), and the inclination was still 89.2 deg.

    The purpose of this new orbit was to provide more frequent passes over the rover, so that the orbiter could be used as a communications relay. The change to this orbit was made at periapsis when the orbiter passed over the rover. As a consequence, every Mars sidereal day the orbiter would pass again on its periapsis over the rover, since the orbiter would have completed 3 revolutions, and Mars would have completed a revolution with respect to the inertial frame. The geometry would repeat every sidereal day.

    Moreover, 1.5 revolutions after these periapsis passes, the orbiter would be passing its apoapsis over the rover. The orbiter would be at apoapsis, at a position opposite to its periapsis passage over the rover, and Mars would have rotated 1/2 revolution, so the rover would also be at a position opposite to that corresponding to the periapsis passage.

    In summary, regarding passes over the rover, the new 1/3 Mars sidereal day orbit gave one periapsis pass and one apoapsis pass every Mars sidereal day. It is interesting that the 1/3 Mars sidereal day period seems the optimal if one is interested in getting repeating passes over the rover. For this, the period should be \(1/n\) sidereal days, with integer n, if we want the geometry to repeat every day. Moreover, \(n\) should be relatively small if we want not to spend too much delta-v in lowering the apoapsis.

    It turns out that when \(n\) is even, only one periapsis pass per day happens over the rover. No apoapsis passes happen over the rover, but there are two apoapsis passes whose sub-satellite point longitude is \(180^\circ/n\) away from the longitude of the rover. These are the passes that are closer to the rover without being immediately above it. In contrast, when \(n\) is odd, one periapsis and one apoapsis pass per day happen over the rover. Besides these, the closest passes are two apoapsis passes and two periapsis passes whose sub-satellite point longitude is \(360^\circ/n\) degrees away from the rover longitude.

    Under the assumption that both periapsis and apoapsis passes over the rover are useful, and that \(n\) is going to be small enough that passes \(180^\circ/n\) away from the rover are not useful, we see that \(n=3\) is the best choice. This is the smallest value of \(n\) that gives two useful passes per day.

    Regarding the communications systems between the orbiter and rover, shortly after the landing of Zhurong, the following image of some presentation slides was shared in Twitter.

    https://twitter.com/yangchengkai/status/1394015222675955712

    I asked for some help translating this. The slide says the following:

    • UHF communications, once per day, 8-10 minutes, totalling ~20 Mbit
    • X-band communications, every three days around apoapsis at 15000 km distance, totalling some 50 Mbit at ~32 kbps rate. Limitation due to power.
    • X-band communications between the rover and Earth, 16 bps

    All this makes a lot of sense. As we will see below, 8-10 minutes matches the useful communications time that can be obtained during a periapsis pass. The corresponding data rate to transfer ~20 Mbit would be between 33 and 42 kbps.

    X-band makes sense for communications around the apoapsis. Zhurong has a small X-band dish antenna, shown in the image below. The gain of this antenna in comparison to the low-gain UHF antenna is needed to close the link at 15000 km. On the other hand, on the periapsis passes the angular speed of the orbiter on the sky is probably too high to track it with this X-band antenna, so UHF needs to be used. Somewhat surprisingly, the X-band system consumes a lot of power, so it can be used very sparingly. 50 Mbit at 32 kbps corresponds to 26 minutes, while the spacecraft spends several hours near apoapsis. Moreover, apparently the power consumption can only be afforded every three days.

    Panoramic taken by Zhurong (credit: CNSA)

    The slide also contains some other interesting information about the orbiter communications. We are already familiar with the nominal and high speed modes.

    • Nominal mode: uplink 2000 bps, downlink 16384 bps
    • Safe mode: uplink 7.8125 bps, downlink 32 bps
    • High speed: 16k – 4096 kbps

    The figure below shows how the 1/3 Mars sidereal day orbit looks like in GMAT. The periapsis is close to the equator and the spacecraft descends from north to south during the periapsis passes.

    1/3 sidereal day communications orbit (inertial frame)

    The same orbit in Mars-fixed coordinates looks interesting. The longitude corresponding to the rover location can be seen on the front of the image. We can see that the orbit repeats every 3 revolutions, and that one periapsis pass and one apoapsis pass happen over the rover.

    1/3 sidereal day communications orbit (Mars-fixed frame)

    The figure below shows the elevation (blue) and distance (orange) of the orbiter, as seen from Zhurong, during a Mars sidereal day. There are actually three passes per day. The first we see here corresponds to the periapsis pass, which is shown in more detail in another figure below. Then Tianwen-1 is again briefly visible near apoapsis, but it is very low in the sky for practical communications. Finally, we have the apoapsis pass, which lasts around 6 hours, and has distances ranging between 5000 and 14000 km.

    Here we see the periapsis pass. The pass lasts around 15 minutes and the distance ranges between 400 and 2500 km.

    In the skyplot we can see that the periapsis pass is almost overhead, going from north to south. The apoapsis pass draws an S-curve shape from south to north.

    This kind of orbit was maintained at least until June 3. In that date, the 20 meter antenna at Bochum suffered a failure due to a thunderstorm, and some servos had to be replaced. For this reason, we did not receive any telemetry from Tianwen-1 until September 1, after the antenna was repaired at the end of August. When we checked the new telemetry, we found the spacecraft in a new orbit. We do not know when the orbit change happened.

    The new orbit still has a period of 1/3 of a Mars sidereal day. The apoapsis radius is 15854 km, the periapsis altitude is 330 km, and the inclination is 87.0 deg. These are small changes compared to the previous orbit. The remarkable change is the argument of periapsis, which is now 121.8 deg. This places the periapsis further north. The figure below clearly shows the change.

    1/3 sidereal day communications orbit in September (inertial frame)

    In Mars-fixed coordinates the orbit looks as shown below. The location of the rover is on the front. We can see the spacecraft near the apoapsis pass over the rover, which now is very far south.

    1/3 sidereal day communications orbit in September (Mars-fixed frame)

    It is interesting to compare the elevation and distance profiles of the orbits in June and September to try to understand the reason why this orbit change was made. Here we see the apoapsis pass at the beginning of the plot. The elevation is much lower, and only reaches 20 deg. The periapsis pass happens near the middle of the plot.

    The detailed view at the periapsis pass shows that it is much longer, lasting almost 30 minutes. The distances are also much larger in the second half of the pass. The spacecraft has already passed periapsis and its altitude is increasing, unlike in the June orbit, in which the spacecraft passes periapsis shortly after passing over the rover.

    In the skyplot we see that the periapsis pass is still almost overhead. However, the apoapsis pass is a low elevation pass along the south-west.

    I do not know the reasons motivating this orbit change. Trying to optimize the communications passes with the rover might be one reason. Another reason has to do with the relative position of the sun and the orbital plane. At the beginning of July, the sun passed through the orbital plane, in front of the periapsis. With the original orbit that the spacecraft had in June, this means that the spacecraft would pass through Mars’s shadow during every apoapsis, and spend relatively long periods without sunlight (the spacecraft spends most of its time around apoapsis). By moving the apoapsis south, the shaded area would be crossed some time after apoapsis, and so the spacecraft would take much less time to cross it.

    At the beginning of August, the Earth also passed through the orbital plane in front of the periapsis. With the original orbit, from the perspective of Earth the spacecraft would pass relatively long periods behind Mars, impeding communications. This is probably not as problematic as not receiving sunlight, but moving the apoapsis south also helps limit the duration of these communications blockages. In any case, this is just a guess for the reason to change the orbit.

    The GMAT script used in this post can be found here. The figures have been made in this Jupyter notebook.

All posts

10ghz astronomy astrophotography ATA ccsds ce5 contests digital modes doppler dslwp dsp eshail2 fec freedv frequency gmat gnss gnuradio gomx hermeslite hf interferometry jt kits les lilacsat limesdr linrad microwaves mods moonbounce noise orbital dynamics outernet polarization radar radioastronomy radiosonde rf amplifiers satellites sdr signal generators tianwen vhf & uhf vlbi