SF 12 Leads to incorrect bytes (SF 11 works great)

[chrisdimoff]

First off, thank you for such an incredible library!

Overview

Context:

• I have a Lime SDR Mini v2 running on a raspberry pi 4b.
• LORA packets are being sent from SX1276 transceiver. I am trying to decode and read them with the lime mini

Variables

• bw = 250khz
• cr = 4/8 (enum 4 in this library)

Problem:

• I noticed that when I set SF 12 in Lora RX block (also set in tx) I end up with some incorrect bytes. This does NOT happen when SF is set to 11 in both tx and in Lora Rx block.

Said another way, SF 11 works but SF 12 does not. See attached sent and received packets for both SF 11 and SF

Other Things of Note

• the packet I am sending has a preamble of 16, but I do not have that set anywhere in Lora RX block (as there is no option I can find)
• I notice that the first part of the packet is usually is okay (on sf 12) and then the frequency of errors increases.

Attachments

• sent and received packets at different spread factors showing errors on SF 12 but not on SF 11
• picture of my flow graph (forgive the resolution, I couldnt get the screenshot off my pi so had to take a photo...)

Sent and Received Packets at Different Spread Factors

SF 12 (Received packet HAS errors):

Transmitted Packet (SF 12)

ff ff ff ff b8 d6 ee 1c 11 7b d1 35 03 19 fc 3f 
f8 9b be 28 07 10 dc 09 05 58 32 d8 c1 aa 9c a3 

Received packet (SF 12)

ff ff ff ff b8 d6 ee 1c 11 7b f1 35 03 19 fc ff 
f8 9b be 40 87 10 0c e1 31 d0 df 45 87 62 74 c3

SF 11 (Received packet has NO errors)

Transmitted Packet (SF11)

ff ff ff ff b8 d6 ee 1c 34 db 0d 2c 03 19 fc 3f 
3a 0d d0 67 02 3b ab 28 ae 64 7d 34 ed ae 08 b6 

Received packet (SF 11)

ff ff ff ff b8 d6 ee 1c 34 db 0d 2c 03 19 fc 3f 
3a 0d d0 67 02 3b ab 28 ae 64 7d 34 ed ae 08 b6

FlowGraph

[chrisdimoff]

also @tapparelj , I am more than happy to implement the solution via PR if/when it is identified. I just need to be pointed in the right direction.

I have a suspicion it is something to do with LDRO.

Also, I have used the more detailed receiver breakdown example with the multiple blocks, defined a 16 byte preamble, and still see this same result. SF 11 works, but SF 12 does not.

[tapparelj]

Hello @chrisdimoff,
Indeed this sounds like a mismatch of LDRO configuration as automatic LDRO mode will enable LDRO for symbol duration >16ms (which is just the case for sf=12, bw=250kHz but not for sf11).
Did you try to set the LDRO option to "Disable" as the sx1276 will not enable LDRO if you (or the library you use to communicate with it) don't implement the automatic switching based on symbol duration?

[chrisdimoff]

Hi @tapparelj , thanks for the response!

I disabled LDRO at the header decoder block and still see the same issue. In fact the number of incorrect bytes greatly increased.

With LDO disabled only the first four bytes are correct.

With LDO enabled, performance is posted in my first post (about 60% of bytes are correct)

I also tried:

• disabled LDRO on tx and kept it disabled in library/rx. Result: ~60% of bytes correct.
• enabled LDRO on tx and enabled it in library/rx. Result: ~60% of bytes correct.

This indicates its not LDRO issue?

[chrisdimoff]

@tapparelj I've played around with all different manner of LDRO options and it seems that longer SF 12 packets cant be received correctly regardless of LDRO combinations.

[tapparelj]

Then it seems that the issue comes from a synchronization error that becomes worse the longer the frame.
If you connect a tag_debug after the frame_sync, you should see a value reported for the carrier frequency offset (CFO). Can you check that value (just to see if there is a large frequency mismatch)?

[chrisdimoff]

@tapparelj

Here it is. Looks like: cfo_frac . -0.374197) (cfo_int . -125

Im not sure if that is good or bad...

FYI for this test the sending payload was hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello

----------------------------------------------------------------------
Tag Debug: 
Input Stream: 00
  Offset: 0  Source: n/a     Key: rx_time   Value: {0 0}
  Offset: 0  Source: n/a     Key: rx_rate   Value: 1e+06
  Offset: 0  Source: n/a     Key: rx_freq   Value: 9.15e+08
  Offset: 0  Source: n/a     Key: frame_info   Value: ((sf . 12) (cfo_frac . -0.374197) (cfo_int . -125) (is_header . #t))
----------------------------------------------------------------------

--------Header--------
Payload length: 125
CRC presence:   1
Coding rate:    1
Header checksum valid!


----------------------------------------------------------------------
Tag Debug: 
Input Stream: 00
  Offset: 32768  Source: n/a     Key: frame_info   Value: ((ldro . #t) (symb_numb . 133) (is_header . #f) (err . 0) (crc . 1) (pay_len . 125) (cr . 1))
----------------------------------------------------------------------
rx msg: 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x25, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x65, 0x6c, 0x6c, 0xf, 0x20, 0x68, 0x65, 0x6c, 0x3c, 0x76, 0x20, 0x68, 0x65, 0xc, 0x65, 0x6e, 0x20, 0x38, 0x63, 0x20, 0x6c, 0x6f, 0x20, 0x1, 0x65, 0x6c, 0x6c, 0x6f, 0x70, 0x41, 0x65, 0x6c, 0x6c, 0x6c, 0x2c, 0x68, 0x65, 0x6c, 0x3f, 0x6f, 0xb1, 0x68, 0x65, 0xc, 0x66, 0x6d, 0x20, 0x68, 0x60, 0xc, 0x60, 0x2f, 0x10, 0x8, 0xe5, 0x6c, 0x6c, 0x6f, 0xe9, 0x48, 0x65, 0x6c, 0x5c, 0x6f, 0x26, 0x68, 0x6d, 0x6c, 0x6c, 0x35
CRC invalid


----------------------------------------------------------------------
Tag Debug: 
Input Stream: 00
  Offset: 544768  Source: n/a     Key: frame_info   Value: ((sf . 12) (cfo_frac . -0.470102) (cfo_int . -126) (is_header . #t))
----------------------------------------------------------------------

--------Header--------
Payload length: 125
CRC presence:   1
Coding rate:    1
Header checksum valid!


----------------------------------------------------------------------
Tag Debug: 
Input Stream: 00
  Offset: 577536  Source: n/a     Key: frame_info   Value: ((ldro . #t) (symb_numb . 133) (is_header . #f) (err . 0) (crc . 1) (pay_len . 125) (cr . 1))

[chrisdimoff]

@tapparelj Forgot to mention the parameters used were: SF 12, BW 250, Freq: 915E6.

Also, I sent you an email regarding hiring you as a temporary contractor to help me resolve this issue.

I really appreciate you committing your unpaid time to a project as amazing as this, but I'd like to contribute some $$ as well to support. Maybe we can setup some time to chat?

[tapparelj]

So I've been looking at SF12 and I could see that the quality of the synchronization was degrading over the duration of the frame, until it leads to constant errors. I have recently been working on an improved synchronization algorithm which will be published soon. I've started implementing it and will publish a new branch so you can test it.
However, I currently estimate all offsets during the preamble (so once per frame) but it seems that when the transmission duration is very long, some parameters drift. It might be one of the reasons LoRaWAN restricts the transmit payload length of SF12 to 51 Bytes.
So to transmit long frames, it would require to track the offsets rather than just estimating them once, but that's something that requires some thinking.