search

rpp0 / gr-lora

GNU Radio blocks for receiving LoRa modulated radio messages using SDR
GNU General Public License v3.0
525 stars 113 forks source link

Decoding the (explicit) header #110

Open pjalocha opened 4 years ago

pjalocha commented 4 years ago

Does this software correctly decode the header thus the 8 symbols after the 2+1/4 reverse chirp ? I am not able to make sense out of the header, I have the symbols but can't match the deinterleave to make valid hamming codewords. Is there any clear description on how to process this part or could somebosy knowledgable help ?

rpp0 commented 4 years ago

Yes, the header should be correctly decoded. Are you building your own decoder or did you encounter a problem using this one? In any case, there is a description on how to process this part here: https://robyns.me/docs/robyns2018lora.pdf

pjalocha commented 4 years ago

Thank you for a quick reply. I build a decoder for a specific system which uses LoRa at 250kHz, SF7 and explicit header. I can detect and synchronize, obtain symbols and so I am stuck at making sense out of those symbols.

I demodulate assuming the preamble is the reference for "zero" symbol and higher frequency progressively means higher values. I perform "to-gray" operation: S ^ (S>>1) and for the header I strip the two lowest bits, which I see always being "01" so I have 8 symbols each 5 bits worth.

And here the problem starts: I try to apply interleaver, I see no whitening is done for the header and I expect to get 5 bytes which would be the hamming codewords, but this I am not able to obtain.

I see some decoder swap the two most significant bits of a symbol, some don't and simply apply diagonal interleaver. I tried various combinations but no positive effect. Ideally an example would be very helpful: some samples numbers, decoded through various stages, etc. to track what happens in the code.

pjalocha commented 4 years ago

Thank you for a quick reply. I build a decoder for a specific system which uses LoRa at 250kHz, SF7 and explicit header. I can detect and synchronize, obtain symbols and so I am stuck at making sense out of those symbols.

I demodulate assuming the preamble is the reference for "zero" symbol and higher frequency progressively means higher values. I perform "to-gray" operation: S ^ (S>>1) and for the header I strip the two lowest bits, which I see always being "01" so I have 8 symbols each 5 bits worth.

And here the problem starts: I try to apply interleaver, I see no whitening is done for the header and I expect to get 5 bytes which would be the hamming codewords, but this I am not able to obtain.

I see some decoder swap the two most significant bits of a symbol, some don't and simply apply diagonal interleaver. I tried various combinations but no positive effect. Ideally an example would be very helpful: some samples numbers, decoded through various stages, etc. to track what happens in the code.

I am as well puzzled by my data: I would expect number of "1" bits in the header to be a multiple of 4 as these bits after deinterleave and without any whitening are supposed to form 8-bit Hamming codewords, when number of "1" bit is 0, 4 or 8. And then I have two data sets from same system in principle but one set satisfies this criteria and the other not. So something can be incorrect at the demodulation level. However, the symbols I can literally see on the spectrograms, thus I am puzzled here.

pjalocha commented 4 years ago

Well, I found it: the demodulated symbol were offset, I forgot about the 1/4 extra symbol in the reversed chirp part, and as I was using the same dechirped data but symbol timing shifted by 1/4 thus the MFSK symbols as well shifted, I can get good codewords now for the header decoding.

davidcastells commented 4 years ago

@pjalocha can you comment the details of the phy header that you have found? By the way, the header is transmitted in low data rate mode, so this means that the value of SF used in the FFT is -2 from the one used in the the demodulation (chirp creation). So, if SF7 is used, you end up using 5 bits per symbol. I'm not sure about the whitening. I see contradictory messages about wether the explicit header uses whitening or not.

pjalocha commented 4 years ago

I can confirm: the LoRa header is transmitted using only 5 bits per symbol in SF7 mode. There is no whitening thus you only need to demodulate the 8 header symbols, each yielding 5 bits, apply linear de-interleaver and you have the header data ready.

My problem was the reference for the "zero" of the demodulated symbols. I took the reference from the preamble but I forgot about the 1/4 extra symbol inserted in the reverse-chirp part, which was effectively shifting the de-chirping sequency by same amount and shifting all following MFSK symbols in frequency.