PREAMBLE, SYNC WORD and LDRO

[jds0987]

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]

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]

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]

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]

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]

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

[jds0987]

@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.