This only tells you that it did not receive an OTAA Join Accept:
- If TTN did not receive it, then of course nothing happened.
- If TTN rejected it, it will not send any response at all. You will only see the orange Join Request in the gateway’s Traffic page (without a DevAddr).
- If TTN accepted it and made one gateway transmit the Join Accept, then somehow the device has not received it. In TTN Console you will see both an orange
Join RequestActivation in the device’s Data page (now including a DevAddr), and a green Join Accept in the gateway’s Traffic page. Sometimes you’ll also see the orange Join Request in the gateway’s Traffic page. So, in TTN Console all will look fine then.
No, a Join Request does not hold any application data, hence shows no payload in the application’s or device’s Data page. However, this does tell you that TTN accepted it. Also, it uses SF12, so it’s very likely that TTN uses RX2 for the Join Accept (which you should also see in the gateway’s Traffic page, if you have access to the gateway that is transmitting it).
So, I think the RN2483 remembered the non-default setting from the earlier join: I am quite sure it does that when not powering down between the tests, but I don’t understand why it would also do that when powering down, assuming you did not run mac save
after the join. And I assume that Loriot is always using the default RX2.
So, what if you execute the following before the second mac join otaa
?
mac set rx2 0 869525000