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

PREAMBLE, SYNC WORD and LDRO #76

Open
jds0987 opened this issue Jan 27, 2024 · 6 comments
Open

PREAMBLE, SYNC WORD and LDRO #76

jds0987 opened this issue Jan 27, 2024 · 6 comments

Comments

@jds0987
Copy link

jds0987 commented Jan 27, 2024

Hi @tapparelj

While working on LoRa decoding closely, I faced an issue pertaining to preamble and sync word.

The issue is that,

Can the LoRa frame be decoded by knowing only the SF and Centre Frequency or the Length of Preamble and SyncWord should also be known to decode the transmission?

If yes, then how can the same be identified for any transmission for creating a reliable flowgragh to decode any transmission with a known SF and transmission frequency?

@tapparelj
Copy link
Owner

Hi @jds0987 ,
in the implementation of this repo, you can easily decode a frame without knowing its preamble length and/or sync words. (Note that commercial chips don't allow unknown sync words and I'm not sure how they behave if you don't specify the correct number of upchirps).

In the current code, if you send more upchirps than the number specified at the receiver it should already work.
For the sync words, you have to go in the code and remove the network identifier verification (remove any part checking for their values)

@jds0987 jds0987 changed the title PREAMBLE and SYNC WORD PREAMBLE, SYNC WORD and LDRO Jan 31, 2024
@jds0987
Copy link
Author

jds0987 commented Jan 31, 2024

Hi @tapparelj

I had modified the Frame Sync Block for the rx chain to removed the steps of checking the preamble and the verification of network identifier. It did not made much of a difference. I was able to receive the payload without any error (transmitted using SF5 from Heltec Automation LoRa 32 chip.

@jds0987
Copy link
Author

jds0987 commented Jan 31, 2024

  1. Why does the flowgraph crashes when LDRO in the Header Decoder block is enabled?
  2. Why do i get two different decoded values of the payload using your rx flowgraph for SF 5 and SF6 for the same transmission when LDRO is enabled and disabled?
    3.Why does enabling soft decoding decode the payload when the source in the flowgraph is a file source block of GRC with recorded LoRa transmission, and why does disabling soft decoding not decode it

@tapparelj

@tapparelj
Copy link
Owner

Hello @jds0987,

  1. Obviously this is a bug probably introduced by the change for sf 5 and 6.
  2. Low data rate optimization reduce the amount of information encoded in each symbol, therefore both the transmitter and receiver should use the same configuration
  3. Using soft-decision decoding is expected to perform better at the cost of an increased complexity.

@tapparelj
Copy link
Owner

@jds0987
I've just pushed a fix for the LDRO issues.

@jds0987
Copy link
Author

jds0987 commented Feb 15, 2024

@jds0987

I've just pushed a fix for the LDRO issues.

Hello @tapparelj

I have downloaded this updated branch with LDRO fixes.

I had recorded an IQ file with LDRO and transmitted it using Semtech sx1268.

The decoded output given by this updated branch is different from the correct desired output.

Probably the LDRO fix might require some more work.

I have shared the iq file along with the desired output on your email id for your testing so that the issue can be resolved.

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

2 participants