I am currently trying to recover a satellite signal, encoded following CCSDS standards. This includes a convolutional code with rate 1/2 and constraint length 7.

I am receiving the signal through an SDR directly connected to the sender using coax cables and some attenuation in-between. For testing purposes, I am sending 0 and 1 alternating. For demodulation and decoding, I am currently using the graph attached to this post.

Up until the convolutional decoder, everything seems to work without problems. When deactivating the code both on the sender and receiver, I can decode the data without any problems. When the convolutional code is active, the decoder sometimes is able to decode the data properly, but most of the time, the output just contains garbage.

I therefore wonder, am I using the decoder block in a wrong way? Documentation about how to properly use this block is hard to find. I already tried different settings for the decoder definition but so far nothing helped.

Can anyone help me with this? Kind regards valkyrie

Used GnuRadio Graph


2 Answers 2


Inside CCSDS channel coding standard, there is a synchronization word called the ASM.

It is a pattern sequence of 32, 64 or 256 bits which is used for synchronization inside the stream. It is usefull to solve the two points I describe below.

Inside your GNU block diagram I see two things that might be an issue:

  • Phase ambiguity: There is no mechanism to solve the phase ambiguity of the BPSK in demodulation. I am not really sure if Viterbi decoder works fine if not solved (the ambiguity).

  • Two bits ambiguity of CC: This type of code with a rate of 1/2 produces two encoded bits for one noncoded. At the input of decoder, you must be synchronized with the first encoded bit of a couple.

This could explain that sometimes your system works after switching on/off. On chance over two or maybe four...

Other remark, using an alternating pattern of 0 and 1 could make you miss something debuging. Try a 32 bits pattern.

Tell us if you found something

  • $\begingroup$ Thanks for your reply Regarding your points: - I'm aware of the ASM, but according to the standard, it is also encoded by the convolutional code and I therefore have to first remove the convolutional code before I can sync with the marker - The phase ambiguity is solved by the differential coding after the convolutional code. Since the used convolutional code is transparent (inverted input leads to inverted output), this should not be a problem for the conv code - Two bits: I was actually not aware, that this can be a problem. I thought, the Viterbi can still sync, but I will try it $\endgroup$
    – valkyrie
    Oct 20, 2020 at 12:38
  • $\begingroup$ You are right, my mistake the ASM is also CC encoded according CCSDS. For two bits, I have no experience with GNU radio, maybe the there is a Viterbi decoder with sync option in GNU radio library $\endgroup$
    – user51024
    Oct 21, 2020 at 9:28
  • $\begingroup$ After a lot more testing, it actually turned out to be the two-bit ambiguity of CC. I already tested this a few times but always used the same CC Decoder Definition for both CC decoders which somehow seems to initialize the same Decoder for both streams. So using two separated CC Decoder Definitions and adding a Delay of one in front of the second one did the trick, thank you. $\endgroup$
    – valkyrie
    Oct 24, 2020 at 6:26

By the way, since the CC encoder is transparent, you could also correlate against a pre-CC-encoded version of the ASM. It's a bit trickier, but saves you 3dB if you use it instead of differential encoding.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.