I have configured RAK2245 gateway in the frequency plan - IN 865 - 867 MHz and selected the router as ttn-router-asia-se. When my node requested for JOIN, the TTN sent back JOIN ACCEPT in the frequency of 923 MHz which is rejected by my gateway as it is configured to operate in 865-867 range. So what should I configure in my gateway settings so that I get a successful join accept. I also tried the eu router but it gets a delayed response and my node gives a rx timeout.
We ask that people don’t cross post queries between forums. The thread you have going on RAK is really the very best place to get support as, well, they are the manufacturer.
This isn’t a gateway problem, it’s a TTN usage problem.
Granted, posting only in one place would be good. But the issue isn’t the gateway, but rather how TTN expects a gateway to report traffic so that it gets downlinks generated in the correct band plan.
Eg, this is strictly about how the gateway is registered with TTN or which server it is pointed at. The gateway’s own software has nothing to do with it.
We now have enough information on the RAK thread to start to suspect that it may be a TTN related issue - registered for IN which has some overlap with the AU bands which is the frequency the response is being requested on. Feel free to contribute to the thread:
or use the logs on there to respond here and we can try & keep things in sync.
You’re free to only respond there if you like, but it fundamentally makes no sense to argue that an issue with the behavior of TTN server software in a particular pattern of usage should be treated only on a vendor’s forum, and not on the TTN forum where there are people who actually understand the TTN server software.
Commanded downlink frequency is purely a behavior of the server, based on its current knowledge of gateway assignment (or maybe its cached knowledge of previous assignment) and possibly the ingress path by which reports arrive. All the gateway itself can do is refuse to transmit on a disallowed frequency; which is legally useful, but ultimately irrelevant to the functional problem of the server needing to command it to transmit on the correct frequency.
The gateway itself really has no role in this, only the registration (possibly registration history) and selected server do.
If I were to conceptually put that eui into another real (or simulated) gateway, point it at the same endpoint and uplink valid packets, I’d get the same invalid downlink responses. Whatever the pattern of usage that triggered this, it’s something that could be experienced by someone with any sort of a gateway, not just a RAK one.
(On a practical level, I strongly suspect that changing the gateway eui to a never before used value, registering it correctly, and pointing it at the correct endpoint is likely to work - at least if ttn-router-asia-se is supposed to support this bandplan?)
