Reception on 434MHz band with HopeRF RFM98W not working reliably

[mikaelnousiainen]

I'm trying to receive LoRa packets sent by my Raspberry Pi LoRa shield with RFM98W chip, but I've only managed to receive a couple of packets randomly from almost a constant stream of packets. Also, the packet data does not seem to be starting from the very beginning of the packet payload. The small amount of data I managed to receive looks correct anyway.

I'm using the following settings: explicit LoRa header, SF7, BW 125k, CR 4:5, CRC on. I've tried other settings too (CR 4:8, smaller bandwidth and higher SF) but these are the only settings I've received any packets with.

I'm using 2M sample rate on 434.250 MHz frequency with NESDR SMArt (RTL-SDR) USB dongle and I've verified using Gqrx that when tuning to 434.250, it's receiving at the center of the signal bandwidth. 1M sample rate does not seem to produce any results.

The packets I'm sending are mostly very long, up to the maximum of 255 bytes.

Questions:

1. Does gr-lora detect bandwidth and coding rate automatically and support them all?

2. Does gr-lora add something to the beginning of the packet or will it output incomplete packets if it can't decode the whole packet?

3. Does the current implementation have restrictions on the length of the packet?

4. How does the preamble length affect the reception for gr-lora? I've noticed that having a longer preamble certainly helps reception with a LoRa chip, so I've been using preamble length of 0xC0.

5. What is the offset parameter on LoRa receiver module used for?

[rpp0]

Hi, thanks for reporting the issue.

1. The bandwidth is hardcoded to 125k, so only 125k is supported. However, support for other bandwidths should be trivial to implement. I will take a look at this when I have the time. As for the coding rate: it's detected automatically.
2. gr-lora will first decode the LoRa PHY header, which is kept secret and thus had to be reverse engineered. It is possible that the length field is decoded incorrectly due to noise, and that could result in an incomplete packet, though I find it strange that you observed missing data in the beginning of the packet. That shouldn't happen. Could you send me a capture file of the signal together with your grc flowgraph, if possible? I will take a look at the problem.
3. The maximum length is 255 bytes, and there is no restriction. However, since there is no clock drift correction, later bytes have a higher probability of being corrupt.
4. Using a long preamble will negatively affect the reception for gr-lora. The preamble detection algorithm needs some work to fix this issue. I would recommend using 0x08 as the preamble length for now.

[rpp0]

I forgot to comment on the fact that you are missing a lot of packets: do you have the same issue when decoding on a more powerful machine? Perhaps the Pi is not powerful enough to do the processing in real time. That said, a 100% packet reception rate is unlikely at this point, due to the preamble issue I mentioned above. So even on a decent machine you will still miss some packets.

[mikaelnousiainen]

Oh, and I forgot to mention that I'm using Raspberry Pi for the transmitter only. The reception happens on a Lenovo P50 (Intel Xeon Quad-core @ 2.80 GHz) so processing power should not be a problem.

Can you briefly describe how to perform the capture and which settings to use to get a file you are looking for?

I'll also try with a short 0x08 preamble.

[mikaelnousiainen]

Ok, using a 0x08 preamble does help with reception a lot, but the longer 255-byte packets are always corrupted in the beginning (the length is always correct) and some of the 255-byte packets are completely missing. I'll have to check this with some proper test data to see what really happens with those packets. Shorter (~30 byte) packets seem to be OK most of the time.

[rpp0]

Okay, cool! The ideal capture settings for me would be:

• SF 7
• CR 4/8
• BW 125 KHz
• Sampling rate 2 Msps
• Preamble 0x08

And then the expected output values of the capture. I'll see what I can do to fix the issues, thanks a lot for reporting! It's hard to test compatibility with all devices as I'm using the RF2483 for all of my tests.

[mikaelnousiainen]

I've made a cfile (converted to complex from rtl_sdr bin capture) of using the above settings and tested that reception works from the file in GNU Radio. I verified that packets are missed and the longer packets are not received correctly.

I've attached the GNU radio graphs here:
rtlsdr-lora-gnu-radio.zip

The cfile is available here for 48 hours:
http://expirebox.com/download/544198b78f10471d67fd822f2276e5d9.html

For capturing I used the following command:

rtl_sdr -f 434250000 -s 2000000 capture-lora-rfm98w-434250000-sf7-bw125k-cr48-crcon-2msps.bin

And for conversion I used this GNU Radio graph: http://ham.stackexchange.com/a/2117

The transmission contains the following messages (without the quotes):

2016-12-20 08:55:04.512213 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0001: SHORT MESSAGE END"
2016-12-20 08:55:04.598480 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0002: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:05.012920 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0003: SHORT MESSAGE END"
2016-12-20 08:55:05.092218 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0004: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:05.505725 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0005: SHORT MESSAGE END"
2016-12-20 08:55:05.585291 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0006: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:05.995854 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0007: SHORT MESSAGE END"
2016-12-20 08:55:06.074197 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0008: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:06.486301 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0009: SHORT MESSAGE END"
2016-12-20 08:55:06.564632 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0010: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:06.976913 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0011: SHORT MESSAGE END"
2016-12-20 08:55:07.055899 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0012: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:07.468894 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0013: SHORT MESSAGE END"
2016-12-20 08:55:07.547670 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0014: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:07.959763 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0015: SHORT MESSAGE END"
2016-12-20 08:55:08.037965 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0016: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:08.447643 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0017: SHORT MESSAGE END"
2016-12-20 08:55:08.526002 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0018: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"
2016-12-20 08:55:08.938190 INFO   24911 ert main.c:main:320 -- Transmitting message: "MESSAGE 0019: SHORT MESSAGE END"
2016-12-20 08:55:09.017061 INFO   24911 ert main.c:main:329 -- Transmitting message: "MESSAGE 0020: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LONG MESSAGE 5 LONG MESSAGE 6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MESSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END"

[rpp0]

Thanks! I can reproduce your issue and I will try to fix it, but it will take some time.

[mikaelnousiainen]

Thanks! Is there any hope to get the preamble/packet detection more reliable as well -- or is it the reason for the data corruption also?

[rpp0]

I believe the cause is different. The packet detection algorithm is the first thing I will investigate ;-)

[ThenTech]

@mikaelnousiainen Since my current work on gr-lora, the detection and packet error rate should be significantly improved. Could you try your samples again? It would be interesting to see how others experience gr-lora in its current state.

[mikaelnousiainen]

@Wosser1sProductions I tested the latest code with the same IQ recording and while the longer packets are present, all of them have increasingly corrupted data towards the end of the packet.

Here's the recording (available for the next 48h) if you wish to do some debugging:
https://expirebox.com/download/1f7650a18762e690a7291f6040670161.html

The settings are as mentioned above: bandwidth 125k, spreading factor 7, coding rate 4:8, sampling rate 2Msps, CRC on, preamble 8 bytes, implicit header. Center frequency is 434.250 MHz

I also have two newer recordings, which (as far as I can remember) should contain the same data, but I only receive garbage in the packets recognized by gr-lora.

I can provide you the IQ data for those recordings also.

[ThenTech]

@mikaelnousiainen I received the files you sent before from @rpp0. gr-lora appears to be able to sync 19 packets in the file, but the decoding is way off. (Errors in the HDR cause garbage in the rest of the packet.)

I will look into it in more detail tomorrow.

[mikaelnousiainen]

👍 Ok. Btw is there already support for other spreading factors and bandwidth settings? What about explicit header support?

If more test data is useful (with different settings), I can generate files for you.

[ThenTech]

@mikaelnousiainen I have have generated packets with the same data and captured those on multiple platforms already. Check the wiki for these results.

gr-lora supports all SFs (7-12) and the header must always be explicit, since the coding rate is determined by looking in the header.

We currently do not support signals that have packets with multiple SFs modulated into them (as should be possible by the patent).

A bandwidth is of 125k is hardcoded in the constructor, and I haven't tested other settings. You could try and change it if you want.

[mikaelnousiainen]

@Wosser1sProductions Any success debugging this issue?

[rpp0]

As can be seen from the screenshot below, the source signal is of pretty low quality:

Despite that, the decoder is able to decode the following now in the latest patch:

MESSAGE 0001: SHORT MESSAGE END
MESSAGE 0003: SHORT MESSAGE END
MESSAGE 0005: SHORT MESSAGE END
MESSAGE 00 6:0LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LO^G$MESSAGE 5 LONG MESSAGE!6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MASSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END
MESSAGE 0007: SHORT MESSAGE END
MESSAGE 0011: SHORT MESSAGE END
MESSAGE 00!4:0LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LO^G$MESSAGE 5 LONG MESSAGE!6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MASSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END
MESSAGE 0015: SHORT MESSAGE END
MESSAGE 0017: SHORT MESSAGE END
MESSAGE 00!8:0LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LO^G$MESSAGE 5 LONG MESSAGE!6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B �ONG MESSAGE C LONG MASSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END
MESSAGE 0019: SHORT MESSAGE END
MESSAGE 0020: LONG MESSAGE 1 LONG MESSAGE 2 LONG MESSAGE 3 LONG MESSAGE 4 LO^G$MESSAGE 5 LONG MESSAGE!6 LONG MESSAGE 7 LONG MESSAGE 8 LONG MESSAGE 9 LONG MESSAGE A LONG MESSAGE B LONG MESSAGE C LONG MASSAGE D LONG MESSAGE E LONG MESSAGE F LONG MESSAGE END

I would expect better performance if you could provide the decoder with a cleaner signal, or perhaps if you filter the signal in advance :).

[mikaelnousiainen]

@rpp0 Great to hear this. I wonder what went wrong capturing the signal, maybe it was too strong (too much gain?). Anyway, have to try the new version now!

[rpp0]

That's possible! Let me know whether the new version works for you now :).