BastilleResearch / gr-lora

GNU Radio OOT module implementing the LoRa PHY, based on https://github.com/matt-knight/research/tree/master/2016_05_20_jailbreak
GNU General Public License v3.0
470 stars 92 forks source link

Deinterleaved codewords incorrect order #42

Open tweej opened 3 years ago

tweej commented 3 years ago

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.

if (ppm == 8)
{
    codewords.push_back(block[0]);
    codewords.push_back(block[7]);
    codewords.push_back(block[2]);
    codewords.push_back(block[1]);
    codewords.push_back(block[4]);
    codewords.push_back(block[3]);
    codewords.push_back(block[6]);
    codewords.push_back(block[5]);
}

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