Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing encoder and decoder with smaller SF 2-6 #74

Open
timasangwan-amit opened this issue Jan 12, 2024 · 9 comments
Open

Implementing encoder and decoder with smaller SF 2-6 #74

timasangwan-amit opened this issue Jan 12, 2024 · 9 comments

Comments

@timasangwan-amit
Copy link

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

@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

image

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

@tapparelj
Copy link
Owner

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
Copy link
Author

@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
Copy link

cnlohr commented Feb 12, 2024

@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
Copy link
Owner

tapparelj commented Feb 13, 2024

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
Copy link

cnlohr commented Feb 13, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants