decoded payload ok with SF8, but nibbles get shuffled with SF7 or SF9

[dc2mw]

I was testing to decode some messages sent from my Inair9 LoRa transceiver.
Communication between two of my hardware LoRa modules is working well, but using constant payload on TX side gives different decoded messages with gr-lora when changing the SF settings.

Settings used for TX module and gr-lora:
Implicit Header
BW 125kHz
Hamming 8,4 aka 4 Parity Bits
low datarate opt
payload CRC OFF
Preamble length 8
869.3 MHz

On RX side I used the provided example flowgraph "rx_usrp.grc" but USRP Source was replaced with RTL-SDR Source using 1e6 sample rate. Distance TX to RX was about 2 metres.

Using SF7, SF8 and SF9 the same payload of 7 bytes was sent out several times with the Inair9 module:
TX (hex): "12, 34, 56, 78, 9a, bc, de"

gr-lora gives reliably these outputs:
RX SF7: "24, 16, 35, 78, 9a, ce, bc, d0,"
RX SF8: "12, 34, 56, 78, 9a, bc, de"
RX SF9: "24, 16, 38, 57, 9a, bc, de"

Decoding works like a charm with SF8.
The bold marked data is correct and sitting at the right place inside the sequence.

When using SF7 or SF9 something strange is happening with the arrangement of the original half-bytes.
It looks like the decoding process places the correct half-bytes into wrong order.
(with one exeption: the leading 7 bytes are missing a "d" nibble at SF7 ... but there is a suspect "d" nearby inside the 8th decoded byte )

I uploaded the GRC flowgraph (used for playback/capture and live reception) to my gdrive together with recorded samples at SF7, SF8, SF9.
https://drive.google.com/drive/folders/0B_V_Uy5rS1foY21qRWtNY2FhZHM

Are there similar observations of other users?
Might something be wrong with my setup?

[matt-knight]

Hi @dc2mw, thanks for the detailed report.

I'm pretty sure the problem is in the last stage of the deinterleaver, where the de-interleaved codewords from each block are rearranged into the appropriate order (https://github.com/BastilleResearch/gr-lora/blob/master/lib/decode_impl.cc#L247). I should be able to iron it out within the next few days.

[dc2mw]

Hi @matt-knight, many thanks for work done to get this gr-lora working.
Your 33c3 talk was a great help to understand what these Semtech blackboxes are doing.

Please feel free to contact me for additional recorded RF samples if needed.

Some experience and hardware are available as my B.E. thesis was about designing a 3-band LoRa system for long range communications and RF propagation tests. No LoRaWAN stuff, mainly hacking registers of SX127x chips with python scripts.
If you have one of several parameters set wrong, you won't receive and decode anything with hardware.

The idea to capture and decode LoRa with SDR is great! You can step through all unknown parameters until something useful will be decoded :-)

[yarreg]

@dc2mw @matt-knight
As I understand you have such problems because of issue #1 exists.
Now only SF8 is properly supported.

[dc2mw]

@yarreg
I would see it slightly different ... you can use SF7/SF9 using the mentioned parameters.
But you will have to find out the missordering of the half-bytes for the payload length in use.
Then you could re-arrange the decoded payload and be happy.

There might be some other settings that work nicely, but one can't figure it out if reading #1 will result in no experiments and feedback.