Yesterday I posted about decoding the data in an X-band recording of BepiColombo. I only made a very shallow analysis of the data, which consisted of CCSDS TM Space Data Link frames. However, I showed that most of the data was transmitted on virtual channel 7. A few hours later, Oleg_meteo in Twitter noted that this data in virtual channel 7 was just a 511 bit PN sequence. After some analysis I’ve confirmed what Oleg_meteo said and shown another interesting and unexpected property of this data.
All the Space Data Link frames in virtual channel 7 have a first header pointer field of 2046, which means “idle data only”. When the payload in these frames is concatenated (there are 8792 payload bits per frame) we obtain an infinite sequence that fits the following description.
The infinite sequence is composed by a repetitions of a 511 bit PN sequence which is obtained from an LFSR with polynomial \(x^9 + x^5 + 1\). The first 9 bits in this PN sequence are ones. Note that these two conditions define the PN sequence uniquely. For the record, the beginning of the sequence is 0xff 0x83 0xdf 0x17 0x32 0x09 0x4e (an interesting side note is that this sequence is ubiquitous: it is found everywhere from toilets to interplanetary spacecraft)
Unexpectedly, the repetitions of the sequence are restarted every 2250752 bits, even though 2250752 is not an integer multiple of 511. In other words, to get the \(j\)-th bit in the infinite sequence, we first need to reduce \(j\) modulo 2250752 to get some \(k\) with \(0 \leq k < 2250752\), and then we reduce \(k\) modulo 511 to get an \(l\) with \(0 \leq l < 511\). The \(j\)-the in the infinite sequence is the \(l\)-th bit in the 511 bit PN (whose bits are numbered \(0,1,\ldots,510\)).
Another way to view this reset of the sequence is that after having produced 2250751 bits, the sequence is producing its 2250751-th bit (starting to count by zero), which is the 307-th bit of the 511 bit PN sequence. The 2250752-th bit is not the 308-th bit of the PN sequence, but rather the 0-th bit, and then the sequence continues by the 1-th bit of the PN, etc.
Finding the 2250752 period and checking that the sequence fits this description has been a somewhat convoluted process, with some dead ends. After sorting out all the details, I have updated the Jupyter notebook with some kind of “success story” that shows the steps that worked and can be used an example of how one could go about finding these details without previous knowledge of the structure of the data.
So what is so relevant about the number 2250752, you may ask? I was asking myself the very same question, but finally noted that 2250752 = 256 * 8792. Since 8792 bits is the size of the payload of a Space Data Link frame, this means that the sequence resets every 256 frames. In fact, what happens is that whenever the virtual channel frame counter wraps down to zero (this is an 8 bit counter), the payload of the frame starts again the PN sequence by the beginning, regardless of the fact that the previous frame in this virtual channel didn’t finish the last repetition of the PN sequence.
So why does the PN restart? That’s a good question, as having it looping indefinitely regardless of how it aligns itself inside the Space Data Link frames would perhaps be the most natural choice. It might happen that all the 256 frames are precomputed and stored in memory. This seems a bit strange, since that’s already 275kB of data (or 319kB if you count headers), and the master channel frame count is deemed to change each time that these frames are used, so the CRC, Turbo encoding, etc. can’t be precomputed.
Another good question with a more definite answer is why is it helpful to have a PN sequence in the payload of idle frames, rather than having all zeros, since the TM Space Data Link layer already has a scrambler. This is explained in the TM Synchronization and Coding blue book. The pseudorandomizer for the Space Data Link layer is a 255 bit sequence. If the data is a constant sequence of zeros (or something else with very simple structure), the scrambled symbols will produce spectral lines at 1/255 of the baudrate. This is undesirable, especially for higher baudrates.
By using a 511 bit PN in the payload of idle frames, we manage to combine two scramblers with coprime periods (ignoring for a moment the effects of frame headers and Turbo encoding). The result is that the combined sequence takes very long to repeat, so it doesn’t produce spectral lines. If we consider frame headers and Turbo encoding, the effect is more or less the same.
4 comments