Can't register gateway on TTNv3

[XFreedy23]

Hi, I am trying to send data with a nucleo-wl55 to an ESP 1ch gateway. I see some packages arriving to the gateway, but can't make the gateway to show up on things network. (Yesterday the nucleo connected to some nearby gateway and the packages showed up on ttn) Can someone confirm if this project is still working with ttn? It is very possible that I messed up something, but I even tried a fork claiming that fixes ttnv3 connection.

If this project is not compatible with ttn anymore, could you recommend me some cheap ttnv3 compatible device/project?

[IoTThinks]

Can try with ChirpStack instead?

[SimonKre]

Hi, unfortunately I also failed to register the gateway with TTNv3. Has anyone managed to register the gateway with TTNv3? Apart from connecting to TTNv3 thanks for great project!

Simon

[kenmcc]

Same issue; my device sends data to singlechan gateway which is reg'd with ttn3 and it shows there but never gets to ttn3 app console. This was all working fine with ttnv2, and the 3 nodes i have not started trying to migrate to ttnv3 are still receiving data via this gateway and into the v2 console - for another 2 weeks anyway. I brought up a multitech gateway and the node sends through to ttnv3 fine.

just today i've started playing with chirpstack and I see this notification in the gateway bridge related to this gateway:

Nov 10 21:30:08 Hennessy chirpstack-gateway-bridge[20358]: time="2021-11-10T21:30:08.819160443Z" level=debug msg="backend/semtechudp: sending udp packet to gateway" addr="192.168.2.208:1700" protocol_version=2 type=PullACK
Nov 10 21:30:08 Hennessy chirpstack-gateway-bridge[20358]: time="2021-11-10T21:30:08.819187591Z" level=debug msg="integration/mqtt: set gateway subscription" gateway_id=600194ffff499b2c subscribe=true
Nov 10 21:30:08 Hennessy chirpstack-gateway-bridge[20358]: time="2021-11-10T21:30:08.824857796Z" level=error msg="backend/semtechudp: could not handle packet" addr="192.168.2.208:1700" data_base64= error="gateway: at least 4 bytes of data are expected"

which is where i'm currently trying to investigate

[nicolasimeoni]

What can we do when V2 will be closed?

[FlavorFx]

As long as there is no fix for this, I went back to the original version. This works with TTN V3: https://github.com/itsygithub/ESP-1ch-Gateway

[argeorun]

Hi i just made it work with V3. I use ESP32+RFM95 and it works well. Nothing changed regarding UDP packet forwarder message format.just pay attention to few things i think.

1. It seems only 3 cloud server address available. If you don't find your country specific pls choose the nearest. I live in singapore so i choose Australia. (au1.cloud.thingsnetwork.)

2. Use the serial monitor to watch the message. if you get keep scrolling probably due to mistake of mismatching configuration like PIN out & server address etc and you can fix any mismatch configuration by look at the serial monitor i guess.

good luck.

[cstratton]

You are mistaken; there can be no software solution to the actual problem, because the hardware is simply not capable of doing the job of a gateway. LoRaWAN requires that a gateway simultaneously monitor 42 frequency and spreading factor combinations, but this device can only monitor one. When you try to use this, you create a misleading situation where a gateway exists for only one combination, but does not exist for any of the other combinations that a proper LoRaWAN node is not just allowed, but actually required to make use of.

This completely screws up the ADR algorithm for settings spreading factor, and the fair channel selection algorithm required not only by the LoRaWAN spec, but actually by law.

Worse, when you do this on a public network, your mess things up for other people's nodes, even if you're not noticing the problem on you own nodes that you may have rigged to violate the LoRaWAN spec and radio laws, but only using a single frequency and spreading factor.

TTN absolutely prohibits connection of these non-compliant devices pretending to be gateways, because there is no possible software fix which can ever make them behave correctly as gateways.

[utya]

You are mistaken; there can be no software solution to the actual problem, because the hardware is simply not capable of doing the job of a gateway. LoRaWAN requires that a gateway simultaneously monitor 42 frequency and spreading factor combinations, but this device can only monitor one. When you try to use this, you create a misleading situation where a gateway exists for only one combination, but does not exist for any of the other combinations that a proper LoRaWAN node is not just allowed, but actually required to make use of.

This completely screws up the ADR algorithm for settings spreading factor, and the fair channel selection algorithm required not only by the LoRaWAN spec, but actually by law.

Worse, when you do this on a public network, your mess things up for other people's nodes, even if you're not noticing the problem on you own nodes that you may have rigged to violate the LoRaWAN spec and radio laws, but only using a single frequency and spreading factor.

TTN absolutely prohibits connection of these non-compliant devices pretending to be gateways, because there is no possible software fix which can ever make them behave correctly as gateways.

ok by the way, can i use this solution in my private network base on https://github.com/TheThingsNetwork/lorawan-stack or chirp, installed localy?

[MihaMarkic]

I'm wondering the same. Since it's not supposed to be used with public TTN, then what are the private options?