Note that clicking a Join Request in TTN Console will show you the details of all gateways that received the request, including their RSSI and SNR. Given their id’s you might be able to find their owner.
(The MQTT API also allows for monitoring device events such as activations, but that shows the same information as the Join Request in TTN Console, and no details about the Join Accept. It also allows for subscribing to errors, but I’d assume that TTN doesn’t think anything is wrong. ttnctl subscribe shows even fewer details. So I’d say TTN Console suffices here.)
Too bad one cannot tell which gateway is used to transmit the Join Accept if multiple have received the Join Request, unless one owns the selected gateway and can see the Join Accept in its Traffic in TTN Console. (Or unless one owns all others and sees those are not used.)
In case you can investigate:
-
Am I right to assume you do see the Join Request in the application’s Data page in TTN Console, even when they fail? And that, if the join fails, the requests are repeated?
-
Am I right to assume that the presence of a specific gateway in the list of gateways that received the Join Request is the culprit? Or does a totally different area with all different gateways yield the same problem?
-
In case you know which gateway is used for the Join Accept:
-
In a specific area, is it always the same gateway that is selected by TTN for the Join Accept downlink? (It might make sense if TTN would pick another one for repeated join attempts, if only to minimize a gateway’s duty cycle, if such applies to the region, which indeed it does for EU868.)
-
Any chance you can limit the range of the node to make that gateway be the only one that received the Join Request, to see what happens then?
-
-
What SF is being used?
-
Any difference when increasing the initial SF?