Dec 062016
 

As you can read in my previous post, I’ve been having trouble establishing P2P communication between a Semtech SX1272 and Microchip RN2483 LoRa transceiver. I though this would be a good idea to use my HackRF One and see if it’s possible to see the LoRa packets “on the air”.

I checked out this article which has some very useful details. I later found this gnuradio plugin which allowed me to decode the basic P2P messages I was sending between my LoPy and Dragino LoRa hat.

I used pybombs to install gnuradio on my Ubuntu 16.04.1 desktop so I created a recipe to install this version of gr-lora (which is different from the gr-lora package normally installed by pybombs) as gr-lora-rpp0. You can add this recipe via pybombs recipes add gr-xykon git+https://github.com/Xykon/gr-xykon.git I did not include dependencies for any specific hardware sdr so make sure you have this installed before running pybombs install gr-lora-rpp0

If you’re not using pybombs you can also follow the instructions from https://github.com/rpp0/gr-lora to download and install the gr-lora plugin for your gnuradio installation.

This version of gr-lora requires liquid-dsp which does not build properly on Ubuntu 16. See this issue on github to fix.

I tried with various sample rates (currently using 10e6) but even 1e6 (1M) seems to show the same results so this should probably work with cheaper sdr hardware than the Hackrf One.

With gnuradion and gr-lora-rpp0 installed I used this simple flowgraph to capture the LoRa packets (I have uploaded the lora_recv.grc file on github):

lora_gnuradio

I seem to be getting fairly consistent results from the LoPy but I’m still struggling with the RN2483 from Microchip. Here is a screenshot of a few received packets:

lora_recv.png

More to follow…

 Posted by at 00:05

  4 Responses to “Decoding LoRa with hackrf & gnuradio”

  1. Glad to see you got it working :)! Though you should probably set offset to 0.1M in this case for better results. Which problem did you encounter with the RN2483?

    • Thanks for the suggestion about the offset. I was experimenting with it because my hackrf isn’t catching all the lora packets I’m sending but it doesn’t seem to make much difference.
      The problem I’m having is that the RN2483 can’t communicate with the Semtech SX1272. From what I can observe in the out put, the RN2483 is sending ‘ff 00 00 02′ as ’40 0b 07 ff 00 00 02′ while the SX1272 is sending ’70 0b 08 ff 00 00 02’.

      • The HackRF isn’t catching all packets because the gr-lora sync algorithm is not ideal. I’m trying to improve it and find the right balance between detection rate and performance. As for the problem with the RN2483 and SX1272: it seems that your LoPy is sending some kind of header, whereas the RN2483 doesn’t do that. You could try prepending 4 bytes “FF FF 00 00” to your payload when sending with the 2483. My guess is that it will work then :).

        • If I change the spreading factor on both modules from 7 to 12 I can see some of the packets I send from the RN2483 on the SX1272 but it doesn’t work in the other direction. When I set the gr-lora plugin to SF12 I only get buffer overflows back from the hackrf… it seems anything above SF8 is pushing my PC past the point where it can run the plugin and still manage to get the data from the hackrf via USB even with the sample_rate lowered to 1M.

          I guess I have to start thinking about upgrading my PC soon.

          There is also a topic on the pycom forum https://forum.pycom.io/topic/210/communication-between-lopy-and-rn2483 about the communication issue.

Leave a Reply