I am trying to experiment with the {de}interleaver from your repository, and have simply copied the relevant functions into a single file. When I try to hamming encode, interleave, deinterleave, and hamming decode a payload, the order of the deinterleaved codewords is incorrect. (Using SF8, any coding rate)
For example, {0xA, 0xB, 0xC, 0xD, 0xE, 0xF, 0x1, 0x5} becomes {0x1, 0xB, 0xE, 0x5, 0xC, 0xF, 0xA, 0xD}. The correct bytes are all there, but they are in the wrong order.
If I change the deinterleave function for the SF8 case so that the order elements are inserted into codewords matches the SF8 case in interleave (0,7,2,1,4,3,6,5) I get the output I expect.
Hi,
Thank you for your 2016 paper and presentation.
I am trying to experiment with the {de}interleaver from your repository, and have simply copied the relevant functions into a single file. When I try to hamming encode, interleave, deinterleave, and hamming decode a payload, the order of the deinterleaved codewords is incorrect. (Using SF8, any coding rate)
For example,
{0xA, 0xB, 0xC, 0xD, 0xE, 0xF, 0x1, 0x5}
becomes{0x1, 0xB, 0xE, 0x5, 0xC, 0xF, 0xA, 0xD}
. The correct bytes are all there, but they are in the wrong order.If I change the deinterleave function for the SF8 case so that the order elements are inserted into codewords matches the SF8 case in interleave (0,7,2,1,4,3,6,5) I get the output I expect.
I think this is a bug, but I'm not sure whether interleave is incorrect, deinterleave is incorrect, or maybe even both.
The code: gr-lora.cc.txt