I’m using the P-NUCLEO-LRWAN2 kit. I tried connecting my gateway NUCLEO-F746ZG to TTN. I have configured the frequency to IN865-867 and the region to au1.cloud.thethings.network in TTN. I have configured the gateway to the same. But still I’m getting connected to other cluster or disconnected in TTN.
If you use Forum search for P-NUCLEO-LRWAN2 you will find many threads and discussions for this bench test kit/eval system. Similarly search on other cluster. The fact it alternates between other cluster and disconnected suggests you may have set up/configured/registered using wrong settings or choices - revisit these and double check, having (status/heart beat) data pinging around the internet between servers and clusters may increase chance of missed/dropped (UDP?*) messages. More importantly per other discussions the GW element of the kit is flawed not following the Semtech ref design, resulting in a weak transmitter causing potential DOS like behaviour to end nodes - yours and more importantly other TTN Community users - therefore recommendation would be use on a private TTS instance for bench test and eval/familiarisation only vs an actual community TTN deployment or private full deployment - that more controlled use would also help you manage the ‘cluster’ aspect of your problem I suspect.
Which cluster are you logged into as a TTN user?
(*) usually on port 1700 - havent looked if AU is using/supports port 1780 as you appear to have configured GW
okay. I’m logged into the au1.cloud.thethings.network cluster as a TTN user. I have tried using port 1700 it still shows disconnected. It doesnt shift between connected to other cluster and disconnected. If I change my server to router.as2.cloud.thethings.network, I’m getting connected to other cluster. For au1.cloud.thethings.network, I’m getting disconnected.
Server addresses of the form “router…thethings.network” were those used under the old V2 implementation of TTN. This was sunset in Dec 2020. I believe original intent was to retire these addresses some 6-12mo later, once people realised they were no longer active and once all had chance to move to new V3 cluster addresses. I think it was realised than an alternate low cost, low impact option was to divert all the old server addresses (IIRC via PacketBroker?), to allow existing non migrated GW’s to continue to function and serve the community and where original users had effectively abandoned or didnt want/wern’t able to access the old GW’s to reprograme them. As a result I am not suprised to see this result in ‘connected to other cluster’. What it suggests is when targeted directly at newest server perhaps the registration details are in error - simple typo’s etc. or config issues that result in GW appearing to be offline/not connected.
Recommend go back and double double check how you have keyed in data and how configured in the console (dont forget to edit server settings on GW to point to correct V3 server instance).
Also, appreciate you are using IN frq plan and targeting AU1, but also if above doesnt help try targeting EU1 server/registration using the IN frq plan settings?