CubeSat S-band OQPSK Demodulation Flowgraph

[evanbauch]

Background

Hello all, my name is Evan and I'm currently working on setting up a GNURadio flowgraph to demodulate an OQPSK signal from a 3U CubeSat. The satellite is the Colorado Inner Radiation Belt Experiment (CIRBE), which is a LASP mission to fly a relativistic particle telescope through the radiation belts over the polar regions.

Signal Coding and Modulation

CIRBE downlinks science data in 2048-byte packets (2052 including sync word) through 2402 MHz OQPSK transmissions following CCSDS TM standards. The data passes through a convolutional encoder (k=7, r=1/2, polynomials = [171,133] as per CCSDS 131.0-B-3) as well as a NRZ-M differential encoder at the input of the convolution encoder. The 32-bit sync word is 1ACFFC1D.

GNURadio Flowgraph

I think I have a good start on the flowgraph; I am using recorded samples from our satellite's RF testing performed earlier this year, and I believe I can track the signal and extract the I-Q symbols from the OQPSK modulation.

In the attached constellation plot photo, you can see that the symbols are shifting by 90 degrees only, never 180 degrees, which is characteristic of the OQPSK modulation; this gives me some confidence in the OQPSK demod. There is a half-chip delay on the I channel before being interleaved with the Q channel to create our bitstream.

However, I am having trouble finding our sync word (1ACFFC1D) in the resulting bitstream. The bitstream passes through a convolutional decoder (FEC Decoder block) and a NRZ-M differential decoder per our radio specs, but the sync word never appears. I cannot seem to find the right combination (or perhaps configuration?) of blocks, and would like to substitute suitable gr-satellites blocks if possible. If anyone has any thoughts or guidance on how to best move forward, it would be a tremendous help to our mission! I am more than willing to upload playback samples if anyone would like to play around with the signal flowgraph, which is zipped and attached below.

LASP_S_Band_CIRBE_OQPSK.zip
.

[daniestevez]

Hi Evan,

First, regarding OQPSK modulation, I think the way you're approaching it won't give good results. In some cases you can get by by pretending that OQPSK is QPSK at twice the baudrate, and then adding pairs of adjacent symbols in the I and Q branches, with a staggering introduced in the pairs of the Q branch. However, if you do this, you need to account for the 90º phase ambiguity of the Costas loop, both when doing these groupings and when trying to find the syncword (I think this is the main problem you have). Nevertheless, this approach will fail depending on the SNR and on the pulse shape (for instance, if the OQPSK modulation is actually GMSK, I don't think it will work very well).

A good way to demodulate OQPSK is as detailed in this post and code. I haven't seen a GNU Radio OQPSK demodulator that I really like. The closest is the one in gr-dslwp. This is based on the Octave code from David Rowe, but unfortunately lacks a DTLL and is perhaps too focused on the characteristics of the Longjiang 2 mission (low baudrate and SNR, relatively short packets, bursty transmission with long ASMs used for synchronization). I have attempted to use the same demodulator for a spacecraft running GMSK at high baudrate in X-band (I think it was Solar Orbiter), with not so good results.

There isn't an OQPSK demodulator in gr-satellites. Including one would be a very good project, if you have the time and resources to do it.

Another minor comment is regarding differential encoding: why is it there? Is it possible to disable it in the transmitter? With OQPSK I don't see any advantage to it, since I don't see how it helps with the phase ambiguity, while it is hurting the BER performance. It would make some sense with a BPSK modulation, since the 180º degree ambiguity of the Costas would be handled by the differential decoder.

[evanbauch]

Thanks for the response Daniel!

Just for my understanding - you're saying that the costas loop might be locking to an ambiguous phase. So hypothetically, if the output of the costas loop was split into four streams at 0 offset, 90 offset, 180 offset, and 270 offset, would one of those streams necessarily be correct?

That post and corresponding code look very helpful. It will take me some time to read through and digest what is written.

And based on we have discussed on the oqpsk ambiguity, I agree that the differential encoding does seem unnecessary. It was probably included because of heritage from previous LASP missions that used BPSK. CIRBE is the first to use OQPSK, so we are very new to this. Unfortunately I do not believe it can be disabled at the transmitter, but I will be looking into that option as well.

[daniestevez]

you're saying that the costas loop might be locking to an ambiguous phase.

The phase that the Costas loop can be the correct one, or wrong by 90, 180 or 270 degrees. Which of these 4 options you get is basically random.

would one of those streams necessarily be correct?

Yes. That approach would work. Probably you can simplify the calculation by grouping things. For instance, the 0 degrees and 180 degrees options only differ in a sign change, so you can take the I and Q in a staggered way in the same manner for both, and since you have a differential decoder downstream and the Viterbi decoder is transparent (inverted input goes in, inverted output goes out), you only need to treat one of the two cases. The same happens with 90 degrees and 270 degrees.

[nsdecicco]

And based on we have discussed on the oqpsk ambiguity, I agree that the differential encoding does seem unnecessary. It was probably included because of heritage from previous LASP missions that used BPSK. CIRBE is the first to use OQPSK, so we are very new to this. Unfortunately I do not believe it can be disabled at the transmitter, but I will be looking into that option as well.

It is worth noting that the modulation and encoding schemes chosen for previous BCT-bus LASP missions (and CIRBE as well?) were decided entirely by the spacecraft vendor (i.e., BCT). I don't have any insight into their thought processes behind their choices.

@evanbauch Which S-band transmitter is CIRBE using? It is also worth noting that CSIM and CUTE (the two previous BCT-bus LASP missions) used S-band transmitters developed internally at BCT, which I believe is different from CIRBE?

[evanbauch]

Which S-band transmitter is CIRBE using?

CIRBE is also using an S-band transmitter developed internally at BCT. I have always heard it referenced simply as "BCT SDR-S".

[shakthivels300]

Hi @evanbauch ,
Can I get those recorded signals if it is open?
Were you able to decode the data?
I am very much interested in this.
Thanks

[evanbauch]

Hi, apologies for my delayed response. Are you still in need of OQPSK samples?