Closed mikaelnousiainen closed 7 years ago
Hi, thanks for reporting the issue.
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.
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.
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.
Okay, cool! The ideal capture settings for me would be:
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.
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"
Thanks! I can reproduce your issue and I will try to fix it, but it will take some time.
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?
I believe the cause is different. The packet detection algorithm is the first thing I will investigate ;-)
@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.
@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.
@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.
:+1: 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.
@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.
@Wosser1sProductions Any success debugging this issue?
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 :).
@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!
That's possible! Let me know whether the new version works for you now :).
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?