[Discuss-gnuradio] gr-fec LDPC comments / questions.

[Sylvain Munaut]

Hi,


I've been looking at the LDPC code and I have a few comments / questions :

1) Memory management seems to be lacking. I see only 3 calls to
gsl_matrix_free but much more matrices being allocated and create by
operations. Am I missing something here or is the code leaking tons of
memory at each encode/decode ?


2) Encoder efficiency : AFAIU, the method implemented in
ldpc_R_U_encoder_impl is meant to be efficient for real-time encoding.
But the efficiency is derived mainly because it makes a lot of the
operation work on sparse matrix and those can be efficiently
multiplied. This is not exploited here at all. The gsl matrix
multiplication is just the plain old classic algorithm for dense
matrix and so the R_U method is probably slower than just using a
multiplication by the generator matrix.


3) Format of the H matrix and support for degenerate/ideal case :

I've been trying to trace the BER curve for the codes used in the
GMR-1 satcom standard. I have the H matrix in numpy and saved it to
alist using the method in the python code in the gr-fec repo.

The H matrix is of the form : [ P' | I ] already, so it's already in
lower triangular form (actually even more than this, since it's the
identity matrix on the right side). So I'd assume I could use this
matrix with the code in the repo and use gap=0, but this doesn't work.

Digging a bit more in the code, I see that the code decomposes it as follows :

 / T | A | B \
| ---+---+--- |
 \ E | C | D /

But in the paper I'm looking at (
http://www.ldpc-codes.com/papers/encoding.pdf ) the T & E matrices are
on the right side, which would match much better of course and
honestly makes more sense to me since the reulting codeword often has
the systematic bits first and then the parity bits.

I don't really understand why it's like that in the code. Also, should
the code already work with the degenerate case where g=0 (which I
think should be pretty common if you provide a check matrix that's
already in the "nice" [ P' | I ] form.



Cheers,

    Sylvain