search

rpp0 / gr-lora

GNU Radio blocks for receiving LoRa modulated radio messages using SDR
GNU General Public License v3.0
525 stars 113 forks source link

Decode package generated from encoder #101

Open mustard123 opened 4 years ago

mustard123 commented 4 years ago

Hello, yes there's an experimental block in the "encoder" branch of this repository that can transmit a (currently hardcoded) LoRa frame that can be received by real LoRa hardware. However, there are some artifacts at the symbol boundaries. The real hardware can compensate for those apparently, but the software decoder cannot.

Originally posted by @rpp0 in https://github.com/rpp0/gr-lora/issues/48#issuecomment-402489647

What would need to be done to resolve the aforementioned artifact issues at the symbol boundaries? Also my gateway says "CRC BAD" on receiving packages from the encoder branch. How do you calcuate the CRC on the hardcoded frame?

rpp0 commented 4 years ago

I don't know. You could use an existing packet sent from a LoRa node or disable CRC checking on the gateway.

Backup-Toaster commented 4 years ago

A test packet that I have used previously, that was copied from a SX1262 dev board, with valid CRC is:

char test_pkt[] = "\x00\x00\x12\x00\x00\xa1\xbc\x33\x01\x07\x00\x00\x00\x00\x00\x12\x91\x60\x00\x00\x00\x00\x01\x50\x45\x52\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\xd4\xcc";

(Note that this packet is coded to send SF7 - there is an obvious \x07 that you can modify for other SFs - \x08, \x09, \x0a ...).

Per the artefacts at the symbol boundaries, these are related to the way the code is packaging codewords into interleaved blocks. See my discussion here.