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

[Sylvain Munaut]

Hi,


> For the encoder/decoder, you're totally right. I didn't free any of the 
> temporary matrices. I just updated those classes with gsl_matrix_free calls.

Ok good.

Whenever we move to a more efficient implementation that doesn't use
GSL for GF2 operation, it would probably make sense to have those
pre-allocated to avoid alloc/free cycles.


> If this class had a more unique name, it would probably be more clear that 
> this parity check matrix class is specifically for use with the R_U encoder. 
> So, I've renamed it from ldpc_par_chk_mtrx to ldpc_R_U_mtrx.
>
> I think it makes sense to have a separate FECAPI encoder variable for using a 
> generator matrix in the standard form [ I | P ] (or given a parity check 
> matrix in the form [P' | I ]. That has been on my to-do list to write.

Yes, OK, it probably make sense to have another matrix class for the
R_U encoder and then have another encoder and matrix class for the [ I
| P ] case. For that latter case, it can just copy the systematic bit,
then use a sparse multiply by P to get the parity bits.

However for the decoder that really shouldn't matter and the same code
should handle both. You should just be able to give it the matrix and
it should only use it to compute the syndrome and that's it. The only
change to the decoder is that it should be able to handle both case
where the systematic bits are at the front or at the back. So I guess
both those matrix classes should inherit a common base that can just
return the H() matrix itself for the decoder.

The matrix H() doesn't fully define the code tough. You need to
separately specify which ones are the systematic bits.



> For a given parity check matrix that is full rank, or can be brought to full 
> rank, it can be ran through the algorithm to bring it into TAB/ECD, or 
> ABT/CDE form. I could add that functionality to the python script intended to 
> be executed as preprocessing step.

Yes, you can but that takes _forever_ to precompute and shouldn't
really be necessary.

In the DVB and GMR code, P is sparse so I don't really see the point
of using the R_U method in that case at all and the decoder should be
able to cope with it no problem.


Cheers,

   Sylvain