1

I'm trying to implement a DVBS2 (48408, 48600) BCH decoder and I'm having troubles with finding the roots of the locator polynomial. For the Chien search here the author initialises the registers taking into account the fact that it is shortened subtracting 48600 from (2^16 - 1). Why so? This is the code I have so far:

function [error_locations, errors] = compute_chien_search(n, locator_polynomial, field, alpha_powers, n_max)
       
    t = length(locator_polynomial);
    error_locations = zeros(t, 1);
    errors = 0;
    % Init the registers with the locator polynomial coefficients.
    coefficient_buffer = locator_polynomial;
    alpha_degrees = uint32(1:t)';
    alpha_polynoms = field(alpha_degrees);
    alpha_polynoms = [1; alpha_polynoms];
    for i = 1:n % 
        for j = 2:t
            coefficient_buffer(j) = gf_mul_elements(coefficient_buffer(j), ...
                                                    alpha_polynoms(j), ...
                                                    field, alpha_powers, n_max);
        end
        % Compute locator polynomial at position i
        tmp = 0;
        for j = 2:t
            tmp = bitxor(tmp, coefficient_buffer(j));
        end
        % Signal the error
        if tmp == 1       
            errors = errors + 1;
            error_locations(errors) = n_max - i + 1;
        end
    end
end

It almost gives me the correct result except for some error locations. For example: for errors made in positions

   418       14150       24575       25775       37403

The code above gives me

  48183      47718       34451       24026       22826

which after subtracting from 48600 gives:

  417        882         14149       24574       25774

which is the position minus 1, except for the 37403, which it did not find. What am I missing?

Edit:

The code in question is a DVBS2 12 error correcting 48408, 48600 BCH code. The generator polynomial has degree 192 and is given by multiplying the 12 minimal polynomials given on the standard’s documentation.

1 Answers1

0

Update - I created an example C program using Windows | Visual Studio for BCH(48600,48408). On my desktop (Intel 3770K 3.5 ghz, Win 7, VS 2015), encode takes about 30 us, a 12 bit error correction takes about 4.5 ms. On my laptop, (Intel Core i7-10510U up to 4.9 ghz, Win 10, VS 2019), 12 bit error correction takes about 3.0 ms. I used a carryless multiply intrinsic to simplify generating the 192 bit polynomial, but this is a one time generated constant. Encode uses a [256][3] 64 bit unsigned integer polynomial (192 bits) table and decode uses a [256][12] 16 bit unsigned integer syndrome table, to process a byte at a time.

The code includes both Berlekamp Massey and Sugiyama extended Euclid decoders that I copied from existing RS code I have. For BCH (not RS) code, the Berlekamp Massey discrepancy will be zero on odd steps, so for odd steps, the discrepancy is not calculated (the iteration count since last update is incremented, the same as when a calculated discrepancy is zero). I didn't see a significant change in running time, but I left the check in there.

The run times are about the same for BM or Euclid.

https://github.com/jeffareid/misc/blob/master/bch48600.c


I suspect an overflow problem in the case of a failure at bit error index 37403, since it is the only bit index > 2^15-1 (32767). There is this comment on that web site:

This code is great. However, it does not work for the large block sizes in the DVB-S2 
specification. For example, it doesn't work with:

n = 16200;
n_max = 65535;
k_max = 65343;
t = 12;
prim_poly = 65581;

The good news is that the problem is easy to fix. Replace all the uint16() functions 
in the code with uint32(). You will also have to run the following Matlab function 
once. It took several hours for gftable() to complete on my computer.

gftable(16, 65581);  (hex 1002D => x^16 + x^5 + x^3 + x^2 + 1)

The Chien search should be looking for values (1/(2^(0))) to (1/(2^(48599))), then zero - log of those values to get offsets relative to the right most bit of the message, and 48599-offset to get indexes relative to the left most bit of the message.

If the coefficients of the error locator polynomial are reversed, then the Chien search would be looking for values 2^(0) to 2^(48599).

https://en.wikipedia.org/wiki/Reciprocal_polynomial

rcgldr
  • 27,407
  • 3
  • 36
  • 61
  • I don't think is an overflow issue anymore. I checked every operation and added a modulo( ) function to each. The code is not fast enough, its a prototype that I want to make functional. But it has to work in the first place. I'm really pulling my hair with this, if you can take a look at the code I'll be forever in debt [link](https://github.com/Wardo82/DVBS2/tree/master/src/3-FEC/BCH/Decoding) – Eduardo Flores Barreto Dec 25 '20 at 20:01
  • A follow up question (related to the post) is if you look into verify_error_locator.m you'll find a function that I made to test that the polynomial is correct if I know the error vector. in the first two lines I get the error positions (from 1 to 48600) and assume the inverses of these are 2^16-1 - error_position. So for example, an error in location 1, will have inverse 65534. In this sense, I test alpha^65534 to see if it is a root of the error locator. Is this correct? – Eduardo Flores Barreto Dec 25 '20 at 21:11
  • The code is the same besides the right shifting of vBx or vC. What's the rationale behind it? – Eduardo Flores Barreto Dec 26 '20 at 04:42
  • No. It's frustrating. I i have the code exact code you got right there. I just don't see the mistake. – Eduardo Flores Barreto Dec 29 '20 at 22:17
  • No luck. I'll look into Euclid's algorithm or try something else later into the summer semester. Got caught in other things of the same project. – Eduardo Flores Barreto Jan 06 '21 at 20:12
  • @EduardoFloresBarreto - you may want to delete prior comments, as they are no longer needed.Have you tried testing for errors where all positions are less than 32767? – rcgldr Jan 07 '21 at 00:21
  • hey, I'm back at it. I'll try your code and run them side by side to spot the error. – Eduardo Flores Barreto Feb 25 '21 at 13:42
  • @EduardoFloresBarreto - any progress on this? – rcgldr Aug 26 '21 at 19:06