Connecting LoRaWan RAK831 with LoRa node

Hi there,
Its my very first topic in this forum so if I made any mistakes kindly accept my apologies in advance.
I have LoRaWAN HAT (with raspberry pi 3b+) consist of RAK831 and A LoRa Node (SX1278 with nodemcu).
What I want is just p2p communication with my gateway and node, whiteout TTN comes into play. Obviously it’ll come into picture but its second stage of my task.
I can’t find any raspberry pi resources for this HAT to receive packets from my node.
Am I doing anything wrong anything out of sight in my approach?
Your help will be appreciated.

Welcome Faizi to the forum.

Can you give me more information about your configuration?
I am struggling with

I have LoRaWAN HAT (with raspberry pi 3b+) consist of RAK811

What LoRaWAN HAT do you have and what is the RAK811 doing?

In general, a LoRaWAN Gateway is not able to do P2P communication. Its HW and firmware is designed to support the LoRaWAN protocol and send/receive encrypted packets on 8 different frequencies and forward them to a LoRaWAN server (builtin or external like Chirpstack, TTN, LorIoT or similar).

A LoRa P2P communication is working on one fixed frequency between several LoRa nodes that are communicating on the same frequency. LoRa P2P does not implement any protocol, it is just sending and receiving unencrypted data packets

First of all Thanks for replaying so quickly.
I have RAK board for gateway capabilities.
I just want its LoRa capabilities just for now to receive packets (unencrypted from my LoRa node) and see on my pi’s screen no server at all.

I just want to implement top 2 blocks first.

This is the board that I have

hei @Faizi ,

Seems this is a RAK831, which is not a node, but a concentrator module.
As you will be moving to LoRaWAN anyway, you can do the following.
Run the RAK831 LoRaWAN Gateway with its stock firmware Even if you don’t want to observe the decrypted payload you can still run the packet forwarder in the console and look at the raw data. You can even run the build in chirpstack and do the same in a visual interface kind of way in your browser. Again no need to register the node, just look at the RAW LoRa frames in the Gateway panel.
If you want P2P than you can do this with 2xRAK811, which you seem to have none of actually, right?


@Hobo Yup its RAK831 it was typo in my topic sorry about it.
So on node side I have SX1278 module with nodemcu.
On gateway I have RAK831.
Can I still be able to see RAW data on its console sending from my node?

Ah, here we go :wink:

RAK831, not RAK811!

Ok, I can only repeat. RAK831 is a LoRaWAN Gateway, it will not handle P2P LoRa packets, but it will receive them if they are on a matching frequency. RAK831 is designed to receive encrypted LoRaWAN packets and forward them to a LoRaWAN server. You cannot do P2P communication with it.

Just for testing, you can setup your gateway to a LoRaWAN region that matches your location (not sure where you are), but let’s say for example AS923.
AS923 listens on the following frequencies: 923.2 MHz and 923.4 MHz

Then you setup your LoRa node (The nodeMCU with SX1278) to send a package on one of the two frequencies every 10 seconds.

I am not familiar with the RAK831. But on my RAK7258 I can see the LoRa P2P packets in the log:

@beegee Sorry for a little typo in my topic yup its RAK831.
What about the solution that @Hobo purposes.
Will it work?
Can I see raw messages on same frequency on console with packet forwarder?
I am in Pkistan and I have 433 Mhz modules for LoRa communication. Unfortunately this isn’t available on TTN. I don’t need TTN though.

@Hobo is proposing the same solution, just with other words. Setup the gateway and check for the raw data.

1 Like

@beegee can you tell me more about how to do it. So I have the following picture in my mind.
So first I need to install firmware using Github after wiring the RAK831 with pi.
I tried it before but don’t know what I was doing before this discussion.
Now things are getting clear step by step.
So after installing it it always ask for TTN configuration which I can skip i guess.
Then run packet forwarder command mp_pkt_fwd to see raw data from my node which is on same frequency 433 MHz or every LoRa message that’s on same frequency.
Am I right or missing something?
Can you tell me the name of Packet logger that you are using to see the raw data?
I followed this tutorial before

HI @Faizi ,

I believe your RAK831 is 433Mhz. If not, it will not match your devices.

Use our official guide :wink:
So you can instantly use the built-in Chirpstack Network Server.

Download the FW here, unzip it and write to a good SD card using balena etcher.

After that, put the sd card on your raspberry pi. Your Raspberry pi will be an access point at start so you can do configurations. The complete guide is here.

@carlrowan yes its 433 Mhz, Actually I don’t want any server probably any python script that will output packets that RAK831 received. I just want to see data on my rasbian OS.

Let’s wait for @Hobo .

I am not really the gateway expert. Probably there’s a way that you can get the data within the RPI that you use as gateway. What I’ve only done in the past is get the data via MQTT within the local network where it is connected using Python script. But my script is running on a separate PC within the same network of the RPi.

@carlrowan @Hobo @beegee Just for clarification guys by p2p communication I mean point to point. Like two LoRa nodes communicate each other.

This post came up on the TTN forum. After two of us told the OP that it wouldn’t work, I elected to lock the thread as @Faizi didn’t want to hear the answer he was given and we repeated ourselves. I would suggest you do the same here. I can, but won’t, conflict of interest.

As I said, despite people trying, no one has successfully created software to turn a concentrator in to a single channel radio.

So you’ll have to run it as a gateway with Chirpstack. And then hack on it all to get the data out.

Concentrator to a single channel radio? :astonished:

I’ll probably buy one RAK4270 then exchange it to what ever concentrator that is :sweat_smile:

@Faizi , I believe there is no direct way to do P2P in which 1 is device and 1 is gateway. It doesn’t mean it is impossible or you shouldn’t try but personally, I think it will consume much of your time. The best way is to use RAK831 as a gateway and have a work around it. Besides, RAK831 is a LoRaWAN gateway and not some kind of multipurpose RF module where you can easily set up your own protocol.

A concentrator card like the RAK 831 knows nothing about LoRaWan, is fully capable of being used for non-LoRaWan purpose, and people actually do that with such hardware.

If you look in the upstream Semtech repos on GitHub for the Lora Hal and packet forwarder, you’ll find some low level command line test programs.

In many cases, if you want to do something else you may chose to go ahead and run the packet forwarder software, which while commonly used for lorawan doesn’t force that.

The packet forwarder exchanges packets with some other software using UDP with a protocol documented in its GitHub repository. Normally you would configure that packet forwarder with the address of a remote server, but you can also point it at the loopback virtual interface to talk to something local.

You then write python code to speak the semtech UDP protocol - I’ve done it for a client as a very straightforward evolution from a python UDP example, but there are probably no published examples of the whole thing.

Or you can get the Chirpstack gateway bridge component which translates the UDP to MQTT in its older version, or possibly(?) protocol buffers in the new. These may be easier to work with in custom python, and while it’s intended to get data to a chirpstack LoRaWan server, it can be used for any other purpose that meets its expectations. This is also open source go code you could theoretically read or modify.

What you want to do is unusual, but fully possible and not very complex beyond the need to first really understand what components do. And yes, you can transmit as well as receive - the only real technical limitation is that packet forwarder software intended for LoRaWan doesn’t know how to dynamically change the set of receive frequencies if your custom scheme doesn’t fit in 8-10 or less fixed channels like LoRaWan would.

If your ultimate goal is LoRaWan it may be an easier learning process to do that, and then learn about what components do by watching them in operation. And if you want a standalone version of LoRaWan where the data stays on the pi, that’s what something like a local installation of Chirpstack is for.

1 Like

More things to learn, yay!

I think that is the main point here. There’s no off the shelf, turn it in to a P2P node piece of software for download, install & run.

But maybe a use for something that doesn’t do LoRaWAN but acts as 8 x radio chips for a private network.

Not off the shelf, but in terms of detail implementation the Semtech packet forwarder UDP protocol is a lot simpler than looking up the registers of one of the node chips.

It’s basically “I heard this” and “please send” as a combination of binary header and then a json string with a base64 payload.

You communicate in terms of intention rather than implementation details.