BepiColombo is a joint mission between ESA and JAXA to send two scientific spacecraft to Mercury. The two spacecraft, the Mercury Planetary Orbiter, built by ESA, and the Mercury Magnetospheric Orbiter, built by JAXA, travel together, joined by the Mercury Transfer Module, which provides propulsion and support during cruise, and will separate upon arrival to Mercury. The mission was launched on October 2018 and will arrive to an orbit around Mercury on December 2025. The long cruise consists of one Earth flyby, two Venus flybys, and six Mercury flybys.
The Earth flyby will happen in a few days, on 2020-04-10, so currently BepiColombo is quickly approaching Earth at a speed of 4km/s. Yesterday, on 2020-04-04, the spacecraft was 2 million km away from Earth, which is close enough so that Amateur DSN stations can receive the data modulation sidebands. Paul Marsh M0EYT, Jean-Luc Milette and others have been posting their reception reports on Twitter.
Paul sent me a short recording he made on 2020-04-04 at 15:16 UTC at a frequency of 8420.535MHz, so that I could see if it was possible to decode the signal. I’ve successfully decoded the frames, with very few errors. This post is a summary of my decoding.
The X-band signal from BepiColombo is very similar to that of Solar Orbiter that I decoded a couple months ago, so I’ve been able to reuse most of the software. The signal is PCM/PM/Bi-φ modulated at approximately 700kbaud and uses an r=1/2 Turbo code with a block length of 8920 bits. Thus, the only difference between BepiColombo and Solar Orbiter is the baudrate (Solar Orbiter used approximately 555.5kbaud).
The SNR in this recording of BepiColombo is lower than in the Paul’s recording of Solar Orbiter, so my decoder didn’t work: the constellation locked, but it was too noisy for the Turbo decoder to correct all the bit errors. Therefore, I have tried an alternative decoding approach that seems to work better.
The decoder can be seen in the figure below. A PLL is used to track the residual carrier, phase demodulation is done, and the signal is resampled to 10 samples per symbol. After that, there is a FIR filter whose taps are a sequence of five -1’s and five +1’s. This should be thought as a matched filter to the Manchester pulse. At the appropriate sampling points, the taps of the filter are aligned with the Manchester clock and the filter wipes-off the Manchester modulation. After this we run clock recovery with the Gardner algorithm and then detect the 64bit ASM that marks the beginning of Turbo codewords.
I’m not completely sure that it’s impossible for this decoder approach to false-lock at 1/2-symbol offset from the correct symbol clock, but so far it seems to work well.
The GNU Radio decoder flowgraph can be found here. As in the case of the Solar Orbiter decoder, it uses gr-dslwp for Turbo decoding, so the flowgraph is for GNU Radio 3.7, as gr-dswlp hasn’t been ported to 3.8 so far. Note that Turbo decoding is very CPU intensive, so it would be really difficult to run the decoder in real time. When I run it on my i7-2620M laptop, the demodulator goes through the recording pretty fast, but the Turbo decoder stays running for many minutes until it finishes processing all the frames.
The decoder can be seen running in the figure below. The spectrum of the in-phase and quadrature branches of the PLL-locked signal is plotted, showing clearly the phase-modulated data sidebands in the quadrature component. There are many bit errors, but even so the Turbo decoder is capable of correcting all of them.
A total of 1808 frames were decoded from Paul’s 46.5 second recording. Only one of these has incorrect CRC. The frames are TM Space Data Link frames. According to the master channel frame count field, only 8 frames were lost in my decoding process.
Four different virtual channels are used to transmit the data. The relative usage of these can be seen below.
Virtual channel ID 0: 38 frames Virtual channel ID 1: 99 frames Virtual channel ID 2: 39 frames Virtual channel ID 7: 1631 frames
The contents of the virtual channels can be seen below. Each frame is plotted as one row of the graph, with colour-coded bytes. It can be seen that the data on each virtual channel is rather different. Virtual channel 2 is perhaps the most interesting, since it seems to have very long sequences of zeros. Virtual channel 7, where the bulk of the data is sent, shows some repetitive structure that doesn’t match the frame size.
I haven’t looked at the data in any more detail yet. What I’ve been curious about are the peaks that can be seen in the quadrature branch near the carrier. In fact, there are several peaks, as it can be seen in the figure below, which shows a close-in spectrum of the PLL-locked signal.
I’ve measured the frequency of these peaks to be 12490Hz, 22088Hz, 24981Hz, and 37417Hz, accurate to 1Hz or so. The last two are then 2nd and 3rd harmonics of 12490Hz. The 12490Hz and 22088Hz tones seem to be related by the fraction 4016/2271. This numerology is perhaps too much of a guess, but since 4016 and 2271 are coprime, it supports the idea that these are ranging tones. Indeed, 12490Hz/2271 is quite close to 5.5Hz (the error is 40ppm, which could be explained by Doppler and clock drift).
So my guess is that the 2271th and 4016th harmonics of a 5.5Hz clock are used for ranging. The ranging ambiguity is given by the 5.5Hz clock, and is approximately 5.5 millions of km. Regarding ranging performance, with a loop SNR of 20dB on the 22088Hz tone (which perhaps is not possible to achieve with this recording, but certainly it is not too far off), the tracking jitter of this tone would be 0.1rad RMS, which is equivalent to 216m, so this is actually not bad at all. However note that resolving the integer ambiguities would require averaging the phase jitter on the 22088Hz tone down to significantly less than 1mrad, so the SNR needed for unambiguous ranging is certainly much more than what is present in this recording.
When researching these tones I also measured the baudrate accurately by using cyclostationary analysis. It turns out that it is 699070.5 baud (accurate to around 1 baud), so I don’t think that the baudrate is related to the frequencies of these ranging tones.