LoRaWAN Nano-Gateway: Stuck on "Not joined yet..."

[cooper]

I am trying to get two Lopy4 devices to work as a OTAA Nano gateway/node by using this tutorial that can be found in the documentation.

My code for both the gateway and the node are verbatim what can be found in the Github repo that is linked to in the tutorial:

For the gateway, the 3 python files I used from the github repo are config.py, main.py, and nanogateway.py. I've only changed the Wifi credentials and uncommented the frequencies for US use in config.py (I removed the Europe lines as well).

Now the node: I am in the US, so I am using the US frequencies (which can be seen in config.py), and the python file from github I am using for the Node is named otaa_node_US915.py. I have renamed that file to main.py since I want it to run on my Node automatically (both the node and the gateway need a main.py). The only thing I changed is the OTA authentication params from line 19-21 (which I double checked are correct from TTN). I have a config file for the

When I turn on the Gateway, it connects to The Things Network. So that should be working as intended. I leave that running for the Node to connect to.

When I turn on the Node however, it gives me an error stating:
ValueError: invalid join data rate 3

After reading this post, I see that changing the data rate to 0 or 4 can get me around this compiling error. So I have changed the value of LORA_NODE_DR to be equal to 0. This can be seen in config.py on line 27.

By doing so I avoid the error and everything compiles as expected. But my node still doesn't work at all. It gets stuck at the loop on line 36 of otaa_node_US915.py. All I see in the console is
Not joined yet...
over and over and over.

I have also tried upgrading the firmware of both Lopy4 devices. I have tried 1.15, 1.18, and 1.19. Nothing helps with either issue. The results remain the same no matter the firmware version.

There has got to be a way to fix this, does anyone have any insight? Otherwise my devices will be useless. Maybe I also have to change the value of LORA_GW_DR because I changed LORA_NODE_DR? Anyone know anything? Thank you!

[hakan kayan]

@robert-hh They are next to each other - 1 meter I would say.

[robert-hh]

@hakan-kayan What is the distance to the closest gateway?

[hakan kayan]

@robert-hh Even though I set tthe region, I still have this problem.

[robert-hh]

@Werner From the documentation:

If no region is provided, it will default to the setting provided in the CONFIG partition, set by the Firmware Updater tool.

Anyway, setting the region does not hurt.

[Werner]

This thread is quite old, but I was able to figure out what the exact problem is and it might help some people in future. My node did not receive any downlink messages because the nano gateway example from github does not define any region when calling lora.init in nanogateway.py

Therefore, I added an region argument to two lora.init calls which failed before (in function _lora_cb and _send_down_link):

lora.init(
  mode=LoRa.LORA,
  frequency=self.frequency,
  bandwidth=self.bw,
  sf=self.sf,
  preamble=8,
  coding_rate=LoRa.CODING_4_5,
  tx_iq=True,
  region=LoRa.EU868
)

[robert-hh]

@cooper there are dedicated gateways available, and some boards attached to a raspberry pi, like the imst 880a or RAK831. You'll find more like that on the ttn forum pages. Pricing about USD 200 ++
I have both an imst880a and a Lopy1 running as gateway. For that purpose, the lopy1 is better than lopy4 or fipy.
Edit: I have a slightly modified version of nanogateway.py at https://github.com/robert-hh/pycom-libraries/tree/nanogateway/examples/lorawan-nano-gateway which tries to compensate the timing lag. It seems to work a little bit better.

[cooper]

@robert-hh thank you!

Interesting. Is there a different solution/set up for a gateway you might have experience with or recommend?

[robert-hh]

@cooper The LoPy4 does not work well as gateway, for a lot of reasons. But even as single channel gateway it is not reliable. LoRaWAN has a very tight demand on timing when it is about delivering downlink messages. And that is where PyCom device lag. You have a few options to deal with the restictions:
a) Do not use OTAA. Use ABP instead, because that does not need a downlink message for joining
b) Use a slow data rate for Downlink messages. At DR0, the receiption window is much longer.
c) In some networks you can set the server to use the RX2 window for downlinks. This window uses a slower data rate.