Thursday 8 September 2016

S2 Developments

I have managed to get a little further with the S2 (maybe S2X) decoder.
I now have a decoder for the bi-orthogonal code that S2 uses to
encode the Mode and Code field (MODCOD). Some Googling showed
that the way to do this is to multiply the received codeword by a
Hadamard matrix. You use the index of the maximum entry in the result
and it's sign to give you the received MODCOD value.
The Original S2 protocol used a (32,6) code and this works fine with the
Hadamard approach. S2X has extended this to (32,7) and it is slightly more
tricky to decode. What I have done is to decode it as normal save the maximum
value then subtract the extra line in the S2X generator matrix from the received
codeword then re-run the matrix multiply again. That way I can tell if the extra
bit in the S2X code is a 1 or a 0 by selecting which of the two matrix multiplies
results in the largest maximum value. If the bit is a 1 it means the waveform
conforms to S2X and if it is a zero then it is S2 so the receiver can handle
both standards. There is another bit that is differentially encoded in the
codeword as well which has to be detected and remove before the
bi-orthogonal decode can occur but that is fairly trivial to do.

I have tested it using a modified version of my S2 transmitter C++ class
so I know it is working (and correcting errors).

I noticed on Twitter yesterday that there is now a proposal to launch a
lunar orbiting Cubesat in 2018 Heimdallr Lunar Cubesat and that they are
proposing that a S2X 1/5 code be used as part of the experiment.
The proposal is for a 25 kbps data rate. If this makes it off the launchpad
then it will be a very interesting thing to listen for and I should have the
software working long before then.

I hope to make my S2 decoder scalable so that it can be used on everything
from a TK1 single board computer up to a high end graphics card. Having a
portable TK1 based solution would be ideal but if that fails then there will be
one of my many GPU based PCs to fall back on. The more GPU power
available the closer to the theoretical performance I can achieve so there
is room for a trade off.

I love challenging (for me) projects!

    

2 comments:

  1. Very informative Charles What are you using for the tuner?

    ReplyDelete
  2. I am planning to use a LimeSDR as I will need to off load some of the processing onto the FPGA. At the moment it will probably do the root raised cosine filtering and fractional sample rate conversion needed to track the transmitter symbol rate. I also plan to do further investigation of Digital Pre-Distortion on the transmit side eventually. The host will receive a sample stream at 2x the symbol rate. The adaptive equaliser I plan to use requires 2x the symbol rate to work. I have used it on HF modems in the past. For this I can cut the number of taps in the equaliser down to about 3 symbols which should be enough.

    ReplyDelete