why the input data of the function "dvbrcs2Turbodecode" has to be "-data"?Does it always to be this way?It's wrong sometimes.

for frmIdx = 1:10

msg = randi([0 1],frameLen,1);

code = dvbrcs2TurboEncode(msg,r,permParams);

modCode = qammod(code,4,[0 2 3 1], ...

'InputType','bit', ...

'UnitAveragePower',true); % QPSK Modulation

receivedOut = awgn(modCode, snrdB);

demodOut = qamdemod(receivedOut,4,[0 2 3 1], ...

'OutputType','llr', ...

'UnitAveragePower',true, ...

'NoiseVariance',nVar); % QPSK Demodulation

decoded = dvbrcs2TurboDecode(-1*demodOut,r, ...

permParams);

errorStats = errorRate(int8(msg),decoded);

Answer 1

[Sudarsanan A K]

Hi Jiaxin,

The negation of the demodulated output, 'demodOut' before passing it to 'dvbrcs2TurboDecode' is crucial and directly addresses the convention used in the function or expected by it for LLR (Log-Likelihood Ratio) values:

• LLR Convention: The 'qamdemod' function, with 'OutputType','llr', produces LLR values where a positive value indicates a higher probability of the bit being '0', and a negative value indicates a higher probability of the bit being '1'. This is a common convention but does not align with the expectation of the 'dvbrcs2TurboDecode' function or the turbo decoding algorithm it implements. i.e., for 'qamdemod' function, the LLR is computed as , whereas for 'dvbrcs2TurboDecode', the LLR is .
• Negation Purpose: By negating the LLR values (-1*demodOut), you effectively invert this convention. After negation, a positive LLR value suggests a higher probability of the bit being '1', and a negative value suggests a higher probability of the bit being '0'. This inversion aligns the LLR values with the convention that the turbo decoder expects.

For further understanding of the sign conventions, run the example in the 'dvbrcs2TurboDecode' documentation page and observe the variables:

https://www.mathworks.com/help/satcom/ref/dvbrcs2turbodecode.html#mw_4a8552f5-4d56-4828-aef1-0fd01816cd55

I hope this helps!