Explicit HDR

[ThenTech]

I am currently improving rpp0/gr-lora as part of my bachelor thesis.

Like in #12, I am trying to run captured files with this repository to be able to compare the accuracy and run time. However all these files have packets containing an explicit header and data, which this repo apparently cannot handle.

e.g. Data sent with RN2483 with coding rate = 4/5, bandwidth = 125k, spreading factor = 8, CRC = on: 0x01 0x23, 0x45 0x67 0x89 0xAB 0xCD 0xEF

And received:

• rpp0/gr-lora: (which is expected) 80 0b 00 01 23 45 67 89 ab cd ed
• BastilleResearch/gr-lora with BW = 125k, SF = 8, offset = -100k, frequency = 868M, CR = 4, ldr = False and header = True: 7f fd 1c 86 ec 32 19 7d ce 3a 46

What should I change to be able to decode the data? (Decoding the header is currently not necessary.)

[gydm]

Hi, I have the same issue with the RN2483 LoRa module and BastilleResearch/gr-lora.

Here is the RN2483 configuration : bandwith = 125 kHz spreading factor = 8 coding rate = 4/8 CRC = off

Then I use an USRP and this grc file : https://mega.nz/#!t4hx1Zzb!pzFhIYu6313zd2MezRY3IBT3qcHGnMziHtiR1zp6Ifo I have chosen these parameters for gr-lora : bandwith = 125 kHz spreading factor = 8 code rate = 4 header = false low data rate = true

However, when I send 00 00 00 00 00, I get AF F6 05 77 3B EE 2D 1B A4.

I am a beginner with LoRa modulation, thus do you have some advices to improve my use of gr-lora with the RN2483 module ?

Thanks !

[dc2mw]

@Wosser1sProductions Explicit Header is broken, as Matt already mentioned in his talk at 33c3 https://www.youtube.com/watch?v=NoquBA7IMNc. If think he mentioned that the reverse-enginieered whitening sequence of implicit header mode might not work for explicit header mode. I think it did not get fixed until now.

BTW I finished my B.E. thesis 3 months ago, LoRa was also a big part of it.

@gydm your parameters do match my own tests (see issue 10). You could try my file using SF8 that will be decoded correctly. But this was implicit header mode. You also mentioned "header = false" which is implicit header.

Topic is about explicit header "header = true", that is not working at all, so it is slightly "off-topic" ;-)

[RyabchikSib]

@Wosser1sProductions This implemetation is header-free: preamble, 2 sync chirps and the data.

I tried to use the sequences from the rpp0/gr-lora here, but there are some troubles. First of all, dewhitening here is applied before the interleaving, not after as in rpp0 case. Then, integers corresponding to symbol's shifts/frequency maximums for some reason appear to be different in these implementations, so the sequence should be derived again.

You've added some code for the derivation of the sequences to the rpp0/gr-lora. Can it be used in this case?

[ThenTech]

@RyabchikSib I guess you could use it, but you'll have to manually check if the acquired sequence results in a good decoding before adding it to the averaging list, something I'll have to try again too.

[matt-knight]

All, thanks for your patience. I've been tied up with other projects as of late. I started working on an update that will add explicit header support, in addition to fixing the nibble shuffling issue referenced in #10. Hope to wrap it up soon. Don't let that discourage potential collaborators though; contributions are always welcome.

[jcohen98]

Hi, I'm currently using the RN2903A (basically the updated US band version of the RN2483) and I'm having the same issues. CR= 4 (4/8) BW = 125 kHz SF = 8-12 CRC = off

Decoding works fine on rpp0/gr-lora, but I can't seem to get it to work on this repository. I also can't use the tx chain to send data back to the chip, I'm guessing for the same reason? It doesn't recognize the signal at all. I'm assuming, as you all mentioned, this is because of the lack of explicit header support. I was just wondering if there is any update on this?