I’m trying out the Lorix One gateway, and while everything seems to be configured correctly, I do not seem to be able to receive any JoinAccept with my RN2483. A tester that I have laying around (not sure what the underlying module is) does successfully receive the JoinAccept, but the RN2483 never does.
The weird thing is that with the Kerlink iFemtocell I usually use, everything works flawlessly.
This makes me assume that there’s some timing-related issue, but does anyone know how this can be verified/resolved? The two gateways are connected to exactly the same network, and both are shown as being connected in the TTN Console.
As the other node does work it’s probably okay, so just to be sure: does TTN Console show the RN2483’s Join Accept? And does it show it for the expected gateway? What if you power down the first gateway?
If shown: does it use the same SF as with the other gateway? If it’s using SF12, then:
TTN Console shows both JoinRequests, but the RN2483 never replies with ‘Accepted’.
If we power up both gateways, we see both gateways receiving the JoinRequests. If we power down the iFemtocell, the RN2483 no longer replies with ‘accepted’ (although we still see the JoinRequest in the Console).
I’ll check the SF in a bit, but we use the 1.0.3 firmware on the RN2483 (and they’re actually RN2483A, rather than RN2483), so that should’ve fixed the SF12 problems.
EDIT: The RN2483 only replies with ‘accepted’ when the iFemtocell is powered off. Don’t think the first sentence was clear enough.
EDIT2: Apparently I’m not awake yet. Obviously, the RN2483 only replies with accepted when the iFemtocell is powered on…
My guess is that the Lorix One is a single channel gateway, and that TTN does not think it supports downlinks? Then I’d guess that TTN would select the other gateway for the Join Accept, but maybe there’s a bug there.
I’ve seen that happen before, but then the TTN Console also mentioned something like ‘no downlink gateway available’ or similar, which I haven’t seen this time.
Now that I think of it more, if it would actually be a single-channel gateway, the field tester also shouldn’t work. But, the field tester does work. Which is what led me to the assumption that it’s a timing problem in the first place (assuming the RN2483 is more strict than the field tester)
…for which TTN may be using the other gateway for the Join Accept, if that gateway has a better reception of its Join Request…
If the Lorix One gateway is NOT single channel, then maybe somehow TTN still thinks it cannot do downlinks? Like maybe it’s not pulling for commands at all? (Again, I’d guess TTN would select the other gateway then as that also received the RN2483’s Join Request, but maybe there’s a bug there?)
Sorry if I wasn’t clear, but I actually mean that the field tester works with just the Lorix One plugged in.
So:
iFemtocell + Lorix one: RN2483 works, field tester works
Just iFemtocell: RN2483 works, field tester works
Just Lorix One: RN2483 doesn’t work, field tester works
Weird. But for the multiple gateways I’d still check which of the gateways (if any) is sending the Join Accept then; it might still reveal some pattern.
Here’s some Markdown for you to copy and enhance
Join Accepts according to the gateways' Traffic pages in TTN Console:
| Active gateway(s) | Join Accept RN2483 | Join Accept Field tester
| ---------------------- | :----------------: | :----------------------:
| iFemtocell + Lorix one | ??? | ???
| Just iFemtocell | iFemtocell | iFemtocell
| Just Lorix One | none | Lorix One
Hi, I’m trying in this days the same configuration. LORIXOne + RN2483 without problems. Double check that app eui and app key on RN2483 are the same configured under lororix one gateway instance in TTN. This is a common join reject, if not.
Where would one configure devices with specific gateways in TTN Console?
Gateways and applications/devices are unrelated. And as the Join Request is accepted when using another gateway, I’m quite sure the RN2483’s configuration must be okay.
Did this issue ever get resolved.
I am seeing a similar issue with a RAK831 gateway and a Things gateway.
I have a a RAK811 that will join on both gateways but my LoPy4 will only join on the RAK gateway.
Both gateways are multi-channel.
I believe the issue might be related to the frequencies used during the OTAA process.
My RAK811 node prefers to register using the primary channels at BW=125. The LoPy attempts to OTAA using the secondary channel at BW=500. My guess is that the RAK831 does not seem to care which channel is used where as the Things gateway may not like the secondary channel registration request.
Has anyone else seen this issue?
