Implementing encoder and decoder with smaller SF 2-6

[timasangwan-amit]

Hello I am trying to implement lower SF, and it looks like the transmitter can generate the signal, but the decoder fails to decode the signal. Do you have any suggestions about where to begin to change the receiver code to implement a decoder for the same? Currently using the GNU radio 3.8 branch.

[tapparelj]

Hello @timasangwan-amit,

I've been able to receive and decode packets with SF<7 sent by an sx1262-based LoRa node. The code is available under the branch sf5_6_sx126x and the main modification is that the header doesn't use the low datarate optimization and that there is an additional 2 upchirps in the preamble (after the 2.25 downchirps), however this change is only sufficient to receive frame from a commercial node, but not to send frames to a ca commercial node, something is missing.

As you want to transmit with SF <5 I guess that you don't care about the compatibility with commercial nodes. The issue with smaller SF is that the explicit header has to fit in the first 8 LoRa symbols, which is not possible for smaller SFs (the header has a size of 20 bits). So for sure you should use the implicit header mode. Just thinking about it, I don't see an obvious problem except for setting the SF to 2. This might cause issue when the low datarate optimization is enabled (i.e. for the 8 first symbol). Did you tired using the implicit header mode (and specify the correct parameters: coding rate, CRC presence and payload length at the receiver)? As it worked without any change for sf 5 and 6, I would be surprised that it would break for sf 4 for example. Then there has been many improvement since the gr-3.8 branch, so if you can, I would strongly advice to use gr-3.10.

[timasangwan-amit]

Hi @tapparelj, Thanks for the reply and help; I tried the changes you recommended, Parameters:

• Impicit header = ON
• LDRO = OFF
• Coding rate = 4/4 and 4/8 tried both
• CRC = On(True) and OFF (False) with the current Bandwidth of 25KHz and Sample rate of 2.5M

Test results:

• For the sf5 and sf6 branch The library works only up to sf=5 and fails at sf=4 or lower. The transmitter appears to produce the symbols, but the decoder cannot decode anything.
• For the main Gnuradio3.10 branch, a similar case to the sf5 and sf6 branches (just prints in Ascii)
• For the Gnuradio3.8 branch, the code fails for anything below sf7.

On these results, what libraries are mostly affected if I port the code from 3.10ver to 3.8ver for the decoding SF5 part? Do you have any suggestions on what files I should focus on for these changes to the 3.8 branch code?

[tapparelj]

Hi, indeed sf<5 doesn't work out of the box, but without looking in more details I don't which part fails.

To add the support of receiving frames for sf 5 and 6 using explicit header mode you can check this commit

I added the support of sf5 and 6 in implicit header mode, I this commit, but as it was 2 years ago I don't remember exactly what was the thing that required to be changed (this commit also added support for low-datarate optimisation). The meaningful changes should be in the include/ and lib/ folders.

[timasangwan-amit]

@tapparelj Thanks, I reinstalled everything and am trying to get the sf5 and sf6 working before I modify the code to work on sf<5. So far I am failing to decode the message strings for sf 5 and sf 6. I looks something similar to (attached photo). I am using the following settings for the LoRa transmitter and LoRa receiver. Sampl_rate: 500000 BW: 125000 SF = 5, 6, 7 (only 7-12 works) CR = 4/4 and 4/5 Implicit Header = Yes CRC = ON (Tried to turn OFF, no effect on decoding) LDRO (Low Data Rate Optimization) = Off

Maybe to get the sf<7 working for tx and rx chain would be a good start for me.

[tapparelj]

Hello @timasangwan-amit,

I've pushed a new version of the transmitter for sf 5 and 6, explicit header. Can you try now? Currently I could verify that sf 5/6 are working in the following link: SX1262 --> USRP USRP <--> USRP

For now I don't get why the link USRP --> SX1276 is not working and I need to further investigate that. Let me know if the newly pushed version works for you.

[timasangwan-amit]

@tapparelj Thank you for the update to the repo; the new code can decode from SDR tx to SDR Rx with SF 5 and SF6. I will keep you posted on how things go with extending the support to lower SF for SDR implementations.

[cnlohr]

@tapparelj

but not to send frames to a ca commercial node, something is missing.

I am sending raw frames with microcontrollers and I am also struggling with SF<=6 and SF>=11. Do you know if this codebase is now able to be received by commercial receivers? Or is it still unknown how these deviate?

Total side-note: Is there a discord server where this stuff is discussed much?

[tapparelj]

Hello @cnlohr, reguarding SF <= 6, the version of the LoRa chip you use matters, if your microcontroller uses an SX127X only the implicit header mode is supported and this should work with this repo. If instead it uses an SX126X then it's this repo should be able to receive in explicit and implicit header mode. Let me know in which case you are. For SF>=11 i've introduced a bug in the branch sf5_6_sx126x that broke low-datarate optimization (I'm trying to fix this currently). And this option is enabled by default for SF11 and 12 if you use a bandwidth of 125kHz .

Still I didn't had the time to further investigate why commercial chips refuse to receive frames with sf5/6 when in explicit header mode. I'm not aware of such a discord server but if you find one, let me know I'd happy to join it as well!

[cnlohr]

Oof. I guess just SF7-10 for me for now then. I have been trying to coalesce as simple-as-possible of a LoRa library (like REALLY simple, header only) and I've gotten it working with SF7-10. But 5-6 and 11-12 illude me. I'm hoping to once I get those working to clearly document everything about the protocol end-to-end, since so many websites online gloss over some crucial aspect.

I'm using a Mikrotik to receive all my packets, I don't know which chip specifically they are using, but it is a commercial chip.