Hi all, I’m using some arduino+RFM95 based nodes, which work fine. But since this week, the activation via OTAA fails. This first happened after an update of an existing node, and now also affects an other node, which is unchanged, only just resetted to see the reaction.
The effect in the TTN console: I see the “yellow” activation messages, they look normal, and I see the node is increasing slowly the SF, because it does not get a confirmation. I was assuming that maybe the node cannot hear the GW because of local noise, but also moving the node to a “silent” environment did not improve the situation. Now my impression is, that it is not a radio issue. Because: normally the network should send a “green” activation response in the TTN console, right? I see only the “yellow” requests, again and again, without any response of the network. What can be the reason for this? Is there a “too often activation” suppression implemented? Can this be “reset”? The frame counters are zero anyway, explicitly resetting did not improve. Any idea?
Thanks and best regards, Uwe
[Edit] The link to the gateway(s) is perfect. I have one node which is “shouting” the activation messages with SF12 and up to 5 gateways hear it. Best SNR is plus 8.
The green response only shows in the gateway traffic, not in the application data.
Yes and no, every activation needs a unique seed value, there are 64k of them available as the data structure is 2 bytes. However the yellow activation icon in the application data shows the backend recognizes and accepts the activation and schedules a response.
If your node is received by multiple gateways the backend will choose one of them to transmit the answer. If you are unlucky that gateway is having transmission issues or is one of the dreaded non compliant gateways causing these issues for you.
You could check the SNR and RSI to check which gateway has the best numbers, that one is most likely to be used to send the response. If that is the same gateway each time you could attempt to block the signal in the direction of that gateway or move a node closer (but not to close) to another gateway.
BTW, using a better SF wouldn’t hurt and reduce airtime considerably.
Good hint, thanks. Then I assume the network is fine and the GW transmits the JoinAccept.
In the meanwhile I got with one node a JoinAccept from the “best” gateway. The remaining potential root causes now could be either a random effect of the GW transmitter, or even a problem with the receive path of the not-working node. Seems it is time to build-up a “sniffer” to show the gateway transmit data…
Yes, this is clear. The SF12 is just the result of the automatic adaption of the library. Normally, the joining works with SF8 or 9, and afterwards the ADR works perfect.
Issue is solved. Root cause was a wrong xtal clock setting in the node, which resulted in a wrong timing of the receive windows. So the node never heared the gateway, and continued sending join requests.