TO-DOs

[ThenTech]

A list of small TO-DOs and future improvements for gr-lora.

• In some test files, in the last packet only the decoded HDR gets printed, without the payload. This might be caused by the failsafe if it reaches noise and the payload length was not satisfied.
• Add parity checks for all Hamming codes?
• Test with higher sample rate?
• Correct clock drift?
• Further FFT improvements
• Test decoding of packets with multiple SFs in same signal.
  • Use for example multiplication with ideal downchirp etc....?
  • Rework FFT to detect other frequencies?

[nickes]

Hey @rpp0 and @Wosser1sProductions, is there any chance, that you also develop a lora-transmitter for gnuradio? I really like the receiver with the explicit hdr mode from this repo, but unfortunaly I also need a transmitter (e.g. manipulate a received signal). I know this was not planned at the beginning, but I hope that it is not excluded. Another thing: Is it possible to use the receiver from this repo and the transmitter from BastilleResearch/gr-lora together? Thank you all for your work and support!

[ThenTech]

@nickes How would you manipulate a received signal? gr-lora outputs the decoded data to the message port which can be connected to the message_socket_sink block also provided in this repo. This way you can actually receive the data from a socket. We use this to verify test data. (examine the Python script gr-lora/python/qa_BasicTest_XML.py for example usage)

Transmitting data was done with the previously written python-loranode. This requires the RN2483 hardware or equivalent.

For testing/comparison purposes, I tried receiving data from the BastilleResearch/gr-lora transmitter, but some 'strange' phase shifting prevented me from correctly capturing data. (Also because the explicit HDR was not supported).

[nickes]

@Wosser1sProductions thank you for your quick answer.

How would you manipulate a received signal?

I trying to build a demo with software defined radio, in which I want to present the received lora messages (with gr-lora) and send custom messages (also with gnuradio) to the lora gateway/server. The communication between the node and the server should be encrypted. The demo would perform an attack similar to a man-in-the-middle attack to receive the keys and decrypt the received messages.
Manipulate is maybe the wrong word... I think intercept is better.

This requires the RN2483 hardware or equivalent.

I don't have a RN2483 controller, just a dragino lora shield (this one), which is, from what I have seen, not compatible with python-loranode (right?). And I'm also want to use my HackRF with gnuradio to trasmit the signal, if this is somehow possible... I also tried to receive data from BastilleResearch/gr-lora transmitter, but I'm getting nothing with my lora_shield. At the moment I'm not quite sure if this demo is possible, but I'm glad to have the chance to talk with professionals like you guys.

[rpp0]

Hi @nickes,

(Writing from mobile, so apologies for any typos.)

Sounds like a really cool idea for a demo! I developed gr-lora with the intent of being able to do security research on the LoRa PHY layer, so I would be interested in seeing the demo when it is finished :).

As for developing a transmitter: I believe this would be possible with only some minor refactoring and changes to the code: the transmit chain can be implemented by simply reversing the receive chain. For me, the only reason I did not do this from the start is because I didn't need a transmitter for my research. If you don't need to manipulate PHY layer symbols (i.e. only MAC data), you can use real hardware as mentioned by @Wosser1sProductions. python-loranode indeed does not support the dragino hat, but I have written a C program that can transmit arbitrary messages, which I can share if you want.

Within the coming weeks, I will release an update that irons out minor mistakes in the reverse engineering process, supports higher SFs better and introduces clock drift correction. After that, I might start with either developing a multi channel receiver or the transmitter ;).

[nickes]

hey @rpp0, thanks for your reply. I ordered a RN2483 controller yesterday. For the first version of the demo I would use gr-lora with a HackRF for receiving the signal and python-loranode with a dm164138 as a transmitter.

I have written a C program that can transmit arbitrary messages, which I can share if you want.

Wow thanks, I'm really interested in your program and would be grateful to see it.
Thanks again for everything, I will start preparing the demo and keep you updated.

[rpp0]

Sorry for the late reply, I temporarily have only sporadic internet access. The program is on my Raspberry which I currently don't have access to, but it's based on the examples in the following library: https://github.com/ernstdevreede/lmic_pi. There's a bug in the library regarding a double initialization (see Issues section of that repository), but it can be easily fixed. Anyway, I will be able to send you the code on Monday :).

[rpp0]

Turns out I can't find the C code anymore, but here is a Python version of the same program. You will need to install the following dependency: https://github.com/mayeranalytics/pySX127x. If the wiring with the Pi is correct, the Dragino HAT should send random LoRa messages of length 4 at 868.1 MHz.

[nickes]

Thanks, this sounds good. I will test the program with my Pi.

[rpp0]

I'm happy to close this issue because most of the tasks in this TODO have been resolved :tada: !

In some test files, in the last packet only the decoded HDR gets printed, without the payload. This might be caused by the failsafe if it reaches noise and the payload length was not satisfied.

This was caused by a GNU Radio issue where the flowgraph gets an 'exit' signal after all samples are consumed, but before the message_socket_sink has had the chance to forward the decoded payload. The solution is to make the test suite signals a bit longer (increasing post delay).

Add parity checks for all Hamming codes?

Getting the number of parity errors was useful for debugging, but as I believe the decoding fully works as it is supposed to now, we could use the Hamming decoding functions of liquid-dsp instead (which don't return the number of parity errors to the user). So this is still partly a TODO. I will make a separate issue for it.

Test with higher sample rate?

Higher sampling rates increase the time resolution (and bandwidth) at the cost of increased computational overhead. This would benefit the clock drift correction algorithm, but as it stands the default sampling rate of 1 Msps (8x oversampling) is more than enough to correct for most drift errors. 4x oversampling seems to work fine as well, so perhaps the default can be lowered. At 2x the clock drift algorithm doesn't work reliably anymore.

Correct clock drift?

This has been implemented as of version 0.6.

Further FFT improvements

This has been implemented as of version 0.6.

Test decoding of packets with multiple SFs in same signal. Use for example multiplication with ideal downchirp etc....?

This is the only TODO from the list that has yet to be completed, but it's the same as issue #31. So I suggest we follow up on this over there.

Rework FFT to detect other frequencies?

Other frequencies can now be handled with the channelizer.