how to use grc block

[cloatre]

Hello,

How to use these grc block with a hackRf for input (in order to decode traffic from my LoRa device)

Thanks,

[rpp0]

Hi, in the latest version there is an example app that allows you to capture in realtime, namely apps/lora_receive_realtime.grc. It should work with the HackRF, but you need to correct for the carrier frequency offset manually by adjusting the "Finetune" parameter. You don't need to use the "LoRa Decoder" block, only the "LoRa Receiver" block. Let me know if you run into any problems.

[cloatre]

Hi,

Ok thanks for help: this is the default value of -95 that I have to change in "Finetune" block? because without changes it seems to decode something (just activate osmocom source with id of my HackRF):

Executing: /usr/bin/python2 -u /root/lora/tmp-gr-lora/gr-lora/apps/lora_receive_realtime.py

WARNING: No route found for IPv6 destination :: (no default route?) linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.010.000.git-0-ef57ffcb

gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio v3.7.10-1-ge55666b7 built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya Number of USB devices: 11 USB device 1d50:6089: 000000000000000014d463dc2f4375e1 skip USB device 1d50:6089: 000000000000000014d463dc2f3b23e1 match Using HackRF One with firmware 2015.07.2 Bits per symbol: 7 Bins per symbol: 128 Header bins per symbol: 32 Samples per symbol: 1024

(lora_receive_realtime.py:19177): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 21 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

f4 4e 7c 83 10 d6 f2 85 0b 37 6f 6d ab ca ff a3 62 64 fa d3 14 90 b0 f0 60 3f a6 7c 42 81 a3 3e ab ab 68 42 41 74 a0 36 36 db 95 7b 0c ed 30 0c be 8d c3 04 b0 (392 errors)

OOOOOOOOOOOOOOOOOOOOOO

f8 be 26 54 bf 3c df 87 02 37 cd cd fb 08 6a ea 96 cc 0f 21 7c a7 f2 70 c1 75 07 d5 01 d1 73 4a 1e 1c 21 47 c0 b2 b8 37 24 98 11 ab 02 05 93 b9 78 d5 1a 56 79 60 15 11 f9 d6 60 1e 5d 93 b2 e2 90 1e dc 20 72 e4 cb 0d d3 65 11 b4 00 76 ba c7 29 75 08 71 d8 b7 0d f1 4a 9f 54 6e c7 9f 0b 3b 71 12 4b 7f 87 9f fb 59 3b 71 45 b6 87 01 f8 d1 61 83 a3 51 ad 9f 9a 9d e8 55 03 9d 0c 40 02 cb 52 00 3b 0f 8d e1 d5 e0 38 cc 5e fa 26 c2 e5 63 93 a9 a7 d8 52 b4 83 5f 16 d2 a6 89 ca 0a 84 e2 b7 4d 91 28 20 6f 1d 79 74 35 13 22 fd 60 29 56 61 4c 76 c9 d1 ee 92 bf 18 30 (1285 errors)

Thanks,

[rpp0]

It looks like you're using the block with the "Realtime" parameter set to False. That will be too slow to decode any meaningful data. You need to set the parameter to True in order to use the realtime decoder. To check whether your message is correct, you can calculate the CRC of the frame.

Edit: alternatively, you can use the HackRF to capture to a file (use the File Sink block) and then run the non-realtime decoder.

[cloatre]

Hi, You are right, I set on RealTIme parameter of "Option" block. I only have got one time decoded values, I always have sequence of OOOOOO . In waterfall I see first emission is about at 868.4Mhz and second one at 867.8Mhz, how do you choose values in WX Slider finetune? Thanks

[rpp0]

If you're having problems with decoding in real time (i.e. when you see OOOOOO), you can try to store your samples to a file first and then run the decoder again with a file source.

The finetune value depends on the carrier frequency offset of your device. You need to determine it only once, and you can do this by looking at the CRC of the packet. If it's correct, then you have found the right finetune value.

[cloatre]

Ok thanks, I have recorded my sample with File sink. I have set off the real time parameter.

And I have change the target_freq with a step of 0.1Mhz (from 867.1 to 868.7Mhz) so sometimes I got decoded values, always with errors like: f8 eb 3c a9 73 e0 c2 (48 errors) -->Is it right that last 4 bytes are the CRC? (here e0c2)

If yes, when I check online the CRC value of f8eb3ca973 it is not good:

CRC-16 0x896B CRC-16 (Modbus) 0x894F CRC-16 (Sick) 0x1234 CRC-CCITT (XModem) 0xFE58 CRC-CCITT (0xFFFF) 0xEF54 CRC-CCITT (0x1D0F) 0x0F96 CRC-CCITT (Kermit) 0xEFAB CRC-DNP 0xAA9C

I will try to change default_value of "finetune" block now.

[rpp0]

Can you send me your sample file? Maybe the decoder doesn't sync to your signal correctly; it might be a bug. I will try myself to see if I can decode your packet

[cloatre]

Ok thanks, I have upload my sample (131Mo) here: https://filesender.renater.fr/?s=download&token=22f0d7cf-f7bd-3165-e77a-c432274b3647 (available until 9 september)

[rpp0]

I took a look at your sample and there are a number of issues:

• It seems that your LoRa device doesn't transmit the two downchirps before the payload. The decoder needs these to synchronize to the frame. I will have to devise a different synchronization approach for the decoder to work with your device.
• It looks like the packets were transmitted using a spreading factor higher than 7. Currently, the decoder only supports SF 7.

There are also some small errors in the symbols (they are not continuous). However, this shouldn't be a problem when decoding but it's worth mentioning.

So unfortunately, the decoder will not work for your LoRa device. Could you give me the model number of the radio chip? I could purchase it and do more tests, but it will take some time.

[cloatre]

Hello,

This is a kit for test that I have got with Bouygues in France. Tuto - Objenious Kit.pdf

ATIM 05/2015 ACW-XD V1.1

[cloatre]

Hello,

Do you know inspectrum tool? I have heard today about it and I have opened my sample with it: interresting!

[rpp0]

Hi, yes I looked at your samples using inspectrum as well :). In your screenshot you can see that the two downchirps are missing, and that there are tiny frequency shift errors for some symbols. Here you can see an example screenshot of a LoRa packet generated by my device: https://github.com/rpp0/gr-lora-samples

[cloatre]

Hi, here is a sample from a CTF in france: https://www.nuitduhack.com/LoRa-865Mhz-1Msps.cfile it looks better than my sample

[rpp0]

Hi, yes that looks like a signal I would expect, very nice! It uses a different spreading factor though, so you can't decode with gr-lora yet.

[rpp0]

Hi Cloatre. In the meantime gr-lora can decode your message. I'm getting:

46 0b 00 02 01 00 05 62 46 7a 61 76 5e 6b 20 21 20 5d 46 69 5c 6b 29 30 67 6c 2f e5 6e 76 1f a1 fd 6d 52 a0 bc a0 73 00 66 6c 11 b5 6a 22 30 27 04 61 46 79 b1 37 56 c8 72 b6 33 73 62 dc 2e 33 64 73 12 b2 9a 35 e2 28 34 71 3e 30 63 37 5b ac 52 b7 63 35 47 aa a1 68 63 78 52 ce ac 24 65 7e 27 82 c1 c1 64 69 14

Any idea what the message should contain?

[dienhoa]

Hello,

I've just recorded my LoRa signal with an BladeRF and using an antenna not specific for LoRa. I see my signal have correct LoRa format (many upchirps and 2 downshirps for initialization) but the center frequency is around 865.2 MHz. I've tried to decode my signal with lora_receiver but not success. Anyone can help me on this problem ?

Please find the recorded signal here: https://drive.google.com/open?id=0B2AvvFXtDzCGM1dPZS1qRUtCM0U

And also the screenshot with inspectrum and gnu_radio

The Spreading Factor is 12.

I'm new on this domain so I'm not very familiar with these parameters that you mentioned above. Is "RealTime" is "RealTime Scheduling" in Options Block ? What exactly is "FineTune" for ?

Thank you so much.

[rpp0]

The Realtime and Finetune parameters are not used anymore in the latest version, and decoding of SF12 is still experimental. You could try first with SF 7 and see if it works for you.