Lorawan gateway and endpoint not getting connected

I am working with three devices:

SX1302 LoRaWAN Gateway: Waveshare SX1302 868M LoRaWAN Gateway.
Raspberry Pi 5: The SX1302 HAT is connected to this device.
Heltech Wi-Fi LoRa 32 (V3): Heltec Wi-Fi LoRa 32 V3 serves as the endpoint device.
I successfully created a LoRaWAN gateway on The Things Network (TTN) website (TTN Console - EU Server). The gateway setup was completed without any issues.

To align with the Indian ISM band (865-867 MHz), I configured the SX1302 packet forwarder with the appropriate frequency settings. However, the Heltec Wi-Fi LoRa 32 endpoint device is not connecting to the network created by the gateway.

How to connect all these device so that Heltec Wi-Fi Lora 32 can access the network created by the gateway ?

I am attaching the config file for the gateway on TTN and for the packet forwarder on the Raspberry pi

Config_files.zip (1.4 KB)

Have a read over this thread

Peter did a write up as well (link in that thread)

Note: In Australia lora freq. should be 915-930 Mhz.

I already tried it but didn’t work.

Hi @Bhavya288206

Welcome to the forum!

There is a guide on the product page for the Heltec device you’ve purchased that should give you some guidance for connecting the device to a gateway. Failing this, ensuring that your gateway is set to public would also be advisable.

No on Snapemu I am not getting the gateway connected.
But on The things network(TTN) the gateway is connected but the node/endpoint device is not getting connected.

A few things to keep in mind.

The node sends a packet the the gateway, the gateway then forwards that on.
Depending on your setup, there may or may not be a response back to the node.

While this could just be the working, I dont really see the node to gateway as a connection as such.

When the node connects to the gateway then all settings on the radio side need to line up. i.e. Frequency for the node to gateway (and the gateway to node if a response is expected). Also check all other settings for the radio (e.g. SF, error detection/correction. If any settings are wrong, the coms wont happen.

The gateway tries to scan all frequencies looking for a signal from a node. As such if you have too many, it could miss it; then maybe get it on a retry.

To go start with I would lock it into one channel and all the same loraWAN settings on both node and gateway.

That’s what the problem is node is sending the data but it is not received at the gateway.
I also confirmed the frequency and all.
I am in India and their is no default file for India in the packet forwarder in sx1302 .
I tried to configured but its not getting connected.

This can be complex to debug.
Have you confirmed the gateway packet forwarder is talking the the hat ok ? i.e. run the packet forwarder direct (not as a service) and check the debug messages coming out of it.

I made this AU915 config for the gateway (see file)
lorawan.zip (1.4 KB)

I have not seen the json files you posted, which makes me think you are using different gateway software then me. Can you post what guide you followed to setup your gateway and a link the to gateway software.

Can you provide me with the config file for India.
I tried editing yours but it doesn’t work.

Hi @Bhavya288206

The config will be reasonably similar but you will need to change the frequency from 915MHz to 868MHz.

When checking what is and is not working, it can be tricky.
The gateway really is just a receiver and forwarder. So as long as the node is transmitting with the correct “lora radio” settings, that gateway should hear it. (if you run the packet forwarder software at the command line, you should see all the events (cant remember if you need to tweak the debug levels, but you have my config file above).

This is what I assume people mean when they say the gateway and endpoint are not working.

the 2nd point that can fail will be from the gateway device to the upstream server. Again if there is an error I would expect this to show up in the logs at one end or the other.

If the node is expecting a response from the server and is not getting one, but the uplink is working, then this is normally related to the return window setup AND very accurate clock/time on the gateway. (depending on what mode your nodes are working in for you setup/system.

So run the packet forwarded at the command line, trigger the node to send a message and check the logs (and post if you can)

Ok let me do that

An example of a packet from the node to the gateway

INFO: Received pkt from mote: 5020026A (fcnt=5)

JSON up: {"rxpk":[{"jver":1,"tmst":3780070746,"time":"2025-02-08T00:23:02.177296Z","tmms":1423009400177,"chan":1,"rfch":0,"freq":918.000000,"mid": 0,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","rssis":-37,"lsnr":9.5,"foff":-844,"rssi":-36,"size":45,"data":"gGoCIFCABQAI1Tz/iN7xaY6FA0eltm0/Sh0P2BrCb8TtXnK/besROKYjt3/3"}]}

You can see the “info” message saying it received a packet.
then the json is the meta data about the packet and the payload itself.

If we break that down a little (see the packet forward documents for a full description)


INFO: Received pkt from mote: 5020026A (fcnt=5)
JSON up: {                          <-- Data from node to gateway
"rxpk":[{                               <-- Receive Packet
	"jver":1,
	"tmst":3780070746,      <-- Time stamps can be very important if you need to send a packet back
	"time":"2025-02-08T00:23:02.177296Z",
	"tmms":1423009400177,
	"chan":1,                               
	"rfch":0,
	"freq":918.000000,             <-- The frequence the gateway received the packet on.        
	"mid": 0,
	"stat":1,
	"modu":"LORA",                    <- LORA Modulation
	"datr":"SF12BW125",           <- Spread Factor and Bandwidth
	"codr":"4/5",                          <- Coding/Error Rate.
	"rssis":-37,
	"lsnr":9.5,
	"foff":-844,
	"rssi":-36,
	"size":45,
	"data":"gGoCIFCABQAI1Tz/iN7xaY6FA0eltm0/Sh0P2BrCb8TtXnK/besROKYjt3/3"    <-- Payload itself base 64 Encoded
}]}

The payload/data may or may not be encrypted, but should be as per your system.

example of packet from gateway to node

JSON down: {"txpk":{"tmms":1423009401177,"freq":926.900000,"rfch":0,"powe":14,"modu":"LORA","datr":"SF12BW500","codr":"4/6","ipol":true,"prea":12,"size":45,"data":"YGoCIFAgHwAIDho40e9uTaSpAkRsrZ6TUhsd+RYmXAGoxN/7QoFrxox1WD26"}}
INFO: [down] a packet will be sent on timestamp value 3781070448 (calculated from GPS time)

Note all settings between node and gateway need to match the gateway then forwards the JSON payload to the network; so end to end becomes important.

LoraWAN has 3 Classes, A, B and C
A is most common and uses the least amount of power. But it has receive windows where the node radio will wake up and listen for a response. there are actually 2 receive windows. If the time is not exact enough or too short then the gateway may not be sending the message when the node expects it.

Key Point : The receive windows only come into play for a packet from the upstream servers responding to the packet. They may or may not do this (check your service provider guides).

LoraWAN is meant to be short and as little time on air as possible, as such downstream packets are costly (cant RX and TX at the same time) so very often are not used.

As per previous posts, the first step will be to ensure you get the packet from the node to the gateway.