Failing for (127, 113, t=2) polynomial

[robbie01]

I'm trying to use this library to provide the BCH coding used in the TPS data of DVB-T, as per the ETSI spec at https://www.etsi.org/deliver/etsi_en/300700_300799/300744/01.06.02_60/en_300744v010602p.pdf. I'm trying to use the t=2 polynomial x^14 + x^9 + x^8 + x^6 + x^5 + x^4 + x^2 + x + 1 (rendered in binary as 0b100001101110111) with the library, but I keep getting the error RuntimeError: unable to inititalize BCH, bad parameters?. How can I resolve this?

[jkent]

I'm not exactly sure how to solve this. The error comes from init_bch in bch.c, which is magic to me.. I've tried different values of m and that didn't work either. I also tried against PR #20 to no avail. Sorry :(

[Asrar-b]

same error come with me ! can anyone help me to find the correct way to initialize the polynomial parameters to be suitable with different values of m and t ?!

[TheCrazyT]

So BCH_POLYNOMIAL would be 0x4377 (and BCH_BITS=2?). I wonder if "bitswapping" is needed.(I once had nand-chip where nand-dump had bhc-encoding with 0x4377, but needed bitswapping) In that case forget about using this library, the bch library seems to be too old for that.

Of course you can always get a newer version(bch.c,bch.h) from the linux kernel and modify it to work with this library. (just compare with the bch.c in this repository ... there are some macros you need to define in order to avoid including kernel headers)

Edit: Oh well i just tested and got "unable to inititalize BCH, bad parameters?" ... looks like python_bchlib calculates m to be 15 (no matter the datasize) at: https://github.com/jkent/python-bchlib/blob/master/src/bchlib.c#L85

Given eccsize being the amount of data to protect, the Gallois Field order is the smallest integer m so that: 2^m > eccsize

(according to https://bootlin.com/blog/supporting-a-misbehaving-nand-ecc-engine/)

Sadly you can't change the python code to set that value directly.

[jkent]

I'm open for discussion on changing the API. Using kwargs would probably be best with sane defaults if they aren't specified. I'll update the bch library to the latest kernel version as well. @TheCrazyT do you wish to open a new issue for discussion?

[TheCrazyT]

@jkent no I'm fine with this issue for discussion.

[jkent]

I got around to working on this and the API is much better in the testing branch. The original issue cannot be solved without changes in bch.c because the BCH encoder/decoder expects octets. Documentation is now provided in the module's docstrings. @TheCrazyT do you have any feedback before a make a 1.0 release?

[TheCrazyT]

@jkent

Traceback (most recent call last):
  File "test2.py", line 22, in <module>
    bch = bchlib.BCH(ECC_BITS, poly=ECC_POLY)
TypeError: 'poly' is an invalid keyword argument for this function

I guess its because you use "prim_poly" on another location of the code? Would also be cool if the setup.py could actually execute those tests.

python setup.py test

running test
running egg_info
writing bchlib.egg-info/PKG-INFO
writing dependency_links to bchlib.egg-info/dependency_links.txt
writing top-level names to bchlib.egg-info/top_level.txt
reading manifest file 'bchlib.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'bchlib.egg-info/SOURCES.txt'
running build_ext
copying build/lib.linux-x86_64-3.7/bchlib.cpython-37m-x86_64-linux-gnu.so ->

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

Somehow I still get the following: "unable to inititalize bch, invalid parameters?" but could have something to do with the error above.

Parameters I'm using are: bch = bchlib.BCH(m=14,t=12,prim_poly=17475,swap_bits=True)

And I'm pretty shure that it should work with those parameters, because I once wrote a c-program with:

bc = bch_init(14,12,17475,true);
if(bc!=NULL){
//...
}

And it was working without a problem.

---

Btw., looks like I must correct one thing I mentioned above:

looks like python_bchlib calculates m to be 15

I was wrong with this one. Looks like I made a coding mistake (script part rewritten in python and executed). Your calculation on that part is correct.

[jkent]

First off, thank you very much for the feedback! Its very much appreciated. I've resolved all these outstanding issues. You were correct, I forgot to update test2.py (now test_exynos.py) and didn't have unit test running working correctly. The reason your init didn't work was because of handling of the swap_bits variable in the C code. I was using a bool when it should have been an integer.