Over the last few days, I’ve been looking at some recordings of the DSCS-III A-3 X-band beacon made by Scott Tilley VE7TIL. The beacon has a central carrier, which is BPSK modulated at 800baud and whose details we know pretty well due to this Master’s thesis by James Coppola. It also has two subcarriers modulated with 1kbaud BPSK of which we know very little. In this post I explain what I’ve been able to find about the data in this 1kbaud subcarriers (which isn’t that much, to be honest).
As I already suspected in my other post, the 1kbaud beacon data is differentially encoded. The data is structured in frames of 61440 bits, which matches the detail of 61K bits that Scott found in some technical report (this one was about EMC testing, so the 61K bit frame size was only mentioned in passing).
The first 100 bits of each frame are a synchronization pattern which is composed by 18 repetitions of the pattern 11110 followed by two repetitions of the pattern 00001, as shown here.
The figure below shows the correlation of the stream of (differentially decoded) bits, where we can see that the correlation pattern appears every 61440 bits.
The frames are too long to plot completely in a raster plot, so the figure below shows the first 1024 bits of each frame (as a row). The remaining part of the frame looks just like the right hand side of this plot.
Now, we see three distinct regions in the plot above. The first is the synchronization marker. The second region, between bits 100 and 600, corresponds to 100 bits sent at 200baud, so each group of 5 bits has the same value. Besides this, the data in this region looks random. The third region starts at bit 600 and continues until the end of the frame. This region also looks random and is sent at 1kbaud.
This is all I’ve been able to find so far. Since the data looks pretty much random, it might be that it is encrypted (which wouldn’t be at all surprising in a military communications satellite), or at least scrambled.
It is quite interesting the fact that 100 bits at the beginning of the frame are sent at 200baud, most likely to increase reliability. What could this data be? It certainly has to be something important. It might be that failure to receive this part renders the rest of the very long frame useless. If cryptography is used, it might be an IV, but I’m just speculating wildly here.
I’ve updated the Jupyter notebook with this plots. The data is also in the same repository, so maybe someone wants to have a go at this and see what they can find.