LoRa Transmission Functionality

[jcohen98]

Hello! I first want to say thank you for all the hard work you've done on this. Every update seems to improve the module so much! The decoding works well with the boards I use currently (Custom Arduino Leonardo with a RN2093A @ 915MHz). I'm starting to get more involved in research with the scalability of LoRa and LoRaWAN, specifically with multi-gateway and city-wide applications. With that said, is there any hope for a TX block in the future? I would love to be able to take this PHY layer implementation and put an open-source LoRaWAN MAC on top of it and turn the USRP's I have into gateways without the need to interface them with any external hardware. Thanks!

[rpp0]

Hi! No problem, glad to hear it's working well for you :). Making a TX block would be relatively easy compared to the receiver, because there is no need to sync and to correct for transmission errors. Furthermore, the TX side is just the reverse of the RX side. The problem however, is that I am not certain whether developing a transmitter would be legal considering LoRa is a patented technology. To be sure, I have to check with the legal department of my university.

[rpp0]

Hi, I've finally obtained permission to implement this functionality! If you would like to help out, feel free to let me know. Otherwise, I can implement the encoder myself if needed.

[nkaramolegos]

I attended your talk on Fosdem. Congratulations. I am interested of the transmitter implementation

[jcohen98]

I would definitely like to help out any way I can. Let me know how I can get involved

[rpp0]

Great! I could definitely use some help.

As a first step, we need to implement a way for the user to pass messages to gr-lora. To achieve this, I suggest implementing a message_socket_source block. This block would create a UDP server at port 40868 and pass received UDP datagrams as a GNU Radio pmt::pmt_t blob message (see https://gnuradio.org/doc/doxygen/page_pmt.html) to the next block. For now, it would be okay to assume that the datagrams sent to the UDP server always contain:

• A valid LoRaTAP header
• A LoRaPHY header
• A payload message

I imagine this would look something like:

pmt::pmt_t loratap_blob = pmt::make_blob(udp_payload, sizeof(uint8_t)*len);
message_port_pub(pmt::mp("loratap"), loratap_blob);

The advantage of this approach is that we can specify a transmit configuration per packet. The LoRaTAP blob will be handled by some future LoRa Encoder block, which will apply the transmit configuration and send the frame. @jcohen98 If you're up for it, you may implement this message_socket_source block in a separate branch and submit a pull request. Feel free to add yourself to the list of authors if you do!

[nkaramolegos]

I can implement this block if @jcohen98 has problem

[nkaramolegos]

Any news on that?

[rpp0]

I haven't heard from @jcohen98 unfortunately. Perhaps you'd like to take over @nkaramolegos ?

[nkaramolegos]

Ok, One question before I start. I assume that the LoRaTAP header, LoRaPHY header and payload message are all unit8_t? Also, what is the length of each one? I have to know how many bytes I am waiting to receive from the udp socket.

[rpp0]

Great, thanks :)! You can do sizeof() the structs defined in https://github.com/rpp0/gr-lora/blob/master/include/lora/loraphy.h and https://github.com/rpp0/gr-lora/blob/master/include/lora/loratap.h (respectively loraphy_header and loratap_header). They also contain a length field to determine to length of their payloads.

[nkaramolegos]

I am not sure that I understand. Do you need a parameter to the block for specifying the LoRaTAP header, LoRaPHY header, payload (as in message socket sink). Could you please explain it in some more details?

[rpp0]

Since the LoRa encoder would always need information on which frequency / sf / bw to use, I'd say that the LoRaTAP header should always be required. This header would be similar to the RadioTap header used by Wi-Fi dongles.

[ThGeoffrey]

Hey ! Any news about that ? :)

[rpp0]

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.

[ThGeoffrey]

Hi rpp0 ! Ah yeah, I just saw the other branch ! That is quite interesting ! I'll try to look at it and see if my SX1272 is able to properly receive & decode the signal sent by ma HackRF One ! I saw the code, you guys made a fantastic job ! ;D

[joary]

Hi guys, I'm trying to understand the hardcoded packet here, more specifically the PHY header (marked with H1).

From the loraphy.h I understood the phy header is something like:

| payload length (8b) | coding rate (3b) | payload crc flag (1b) | header crc (8b)  | reserved (4b) |

Though i did not understand how the header's CRC is calculated. Do you have any reference on which polynomial is used to generate the header's CRC?

PS: Great work you have been doing.

[nkaramolegos]

Hello @joary, this https://www.semtech.com/uploads/documents/AN1200.18_STD.pdf may help. @rpp0 What is the status of TX functionality, I am pretty busy this period and I didn't have a "good" look?

[probonopd]

Would it be possible to use cheap Fresco Logic FL2000 hardware to transmit LoRA? These have been used to transmit wideband FM radio and GSM.

https://osmocom.org/projects/osmo-fl2k/wiki