I repost a bug report by Laurent Schmalen ( loreng ) which has not been
discussed here. I will add my comments in another post.
"The Reed-Solomon decoder behaves incorrectly in the case of systematic codes
and bad SNRs. The reason is the following:
If the received code word cannot be decoded (e.g, because there are too many
errors), then decoderfailure is set to "false". In this case, always the all
zero decoded information vector is returned (as mbit.clear() on line 216 and
then decoded_bits is filled with mbit). In the case of a systematic code and a
decoderfailure, all the received information should be used). The current
implementation givdes BER of 0.5 in bad to medium channel conditions)."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
in principle, loreng is correct. But I would not say that this is a bug, since
the correct behavior in case of a decoding error is not clear. But there
definitely exists another bug in that
decoderfailure
is never set to
true
. This should be resolved first. Since I am not familiar with RS codes, can
anybody check, when
decoderfailure
should be set to
true
in order to indicate a decoding failure?
Now back to loreng's issue: The actual implementation treats systematic and
non-systematic codes the same. For systematic codes this is not the best on
can do as loreng correctly states. But the problem has a wider range than
that: One cannot distinguish between a decoding failure (output all-zero
codeword) and decoding onto a valid all-zero codeword, i.e. when an all-zero
message has been encoded at the transmitter).
Therefore, I, In contrast suggest leaving the decision what to do to the user
by adding another decoding function that returns decoderfailure as a bvec,
since we have to consider several
itterations
(typo in source) at once. Furthermore we change the documentation to state the
fact, that the actual method does not distinguish between corrected zero
codeword and decoding failure output. This maintains backward compatibility
and loreng can, in addition, add another function handling systematic decoder
failure in the way he suggested.
BTW: The problem is the same with BCH decoding and we should find a similar
solution for that.
/donludovico
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I went into the problem and here is my suggestion of a solution, applying
to both BCH and Reed-Solomon codes:
adapt the actual decoding method and mark the previous one as
outdates/deprecated/held for backward compatibility.
The new method no returns a binary vector cw_is_valid of length iterations
(see source code)., i.e. it's length is the number of processed code
words/blocks. If cw_is_valid(n) is false in a particular position n, this
indicates a decoder failure. In this case, message now contains the extracted
systematic bits as suggested by loreng.
The old/deprecated methods keep their old functionality, i.e. they return the
zero-message on a decoder failure.
I did the changes in the code. unfortunately, I cannot upload any patches on
that particular bug report.
@criteab howto commit the patch?
Regards Stephan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I repost a bug report by Laurent Schmalen ( loreng ) which has not been
discussed here. I will add my comments in another post.
"The Reed-Solomon decoder behaves incorrectly in the case of systematic codes
and bad SNRs. The reason is the following:
If the received code word cannot be decoded (e.g, because there are too many
errors), then decoderfailure is set to "false". In this case, always the all
zero decoded information vector is returned (as mbit.clear() on line 216 and
then decoded_bits is filled with mbit). In the case of a systematic code and a
decoderfailure, all the received information should be used). The current
implementation givdes BER of 0.5 in bad to medium channel conditions)."
OK, no my reply,
in principle, loreng is correct. But I would not say that this is a bug, since
the correct behavior in case of a decoding error is not clear. But there
definitely exists another bug in that
is never set to
. This should be resolved first. Since I am not familiar with RS codes, can
anybody check, when
should be set to
in order to indicate a decoding failure?
Now back to loreng's issue: The actual implementation treats systematic and
non-systematic codes the same. For systematic codes this is not the best on
can do as loreng correctly states. But the problem has a wider range than
that: One cannot distinguish between a decoding failure (output all-zero
codeword) and decoding onto a valid all-zero codeword, i.e. when an all-zero
message has been encoded at the transmitter).
Therefore, I, In contrast suggest leaving the decision what to do to the user
by adding another decoding function that returns decoderfailure as a bvec,
since we have to consider several
(typo in source) at once. Furthermore we change the documentation to state the
fact, that the actual method does not distinguish between corrected zero
codeword and decoding failure output. This maintains backward compatibility
and loreng can, in addition, add another function handling systematic decoder
failure in the way he suggested.
BTW: The problem is the same with BCH decoding and we should find a similar
solution for that.
/donludovico
PS: For the BCH i remember already having written such an extension. I'll have
to check, where the diff is hidden and will then come back.
/SL
OK, I went into the problem and here is my suggestion of a solution, applying
to both BCH and Reed-Solomon codes:
adapt the actual decoding method and mark the previous one as
outdates/deprecated/held for backward compatibility.
The new method no returns a binary vector cw_is_valid of length iterations
(see source code)., i.e. it's length is the number of processed code
words/blocks. If cw_is_valid(n) is false in a particular position n, this
indicates a decoder failure. In this case, message now contains the extracted
systematic bits as suggested by loreng.
The old/deprecated methods keep their old functionality, i.e. they return the
zero-message on a decoder failure.
I did the changes in the code. unfortunately, I cannot upload any patches on
that particular bug report.
@criteab howto commit the patch?
Regards Stephan
BTW: This bug is then a duplicate of #2993430.
fyi: bug fix is in SVN rev. 1888