I have a new TTN node that will not be acknowledged by the gateway (Mikrotik Lora8).
The TTN gateway on the console can see the incoming packets, the interface for the mikrotik gateway can also see the packets, but it doesn’t seem to want to allow the node to connect.
The following error message is output in the serial monitor.
Nodes do not connect to gateways. Nodes connect to the network, so you could check the TTN console to see if that shows any information on the node. Does the application show join requests?
The really weird thing is… I’ve just put up anther gateway a few miles from the one with the problems, when the new gateway is on, the gateway that was having the problems then works…
I guess the real problem is. Your #1 gateway transmitted on that day too many packets. Due to fair use policy it will stop. To wait a couple of hours will help as well.
My solution for problematic joins: have a spare gateway. (either in your pocket or permanently installed)
While that is possible, it is unlikely to be a problem for a prolonged period of time. If there are no new downlinks for that gateway it should ‘recover’ in about 5 minutes.
I had exactly the same issue. I saw the “Join” Answer of the gateway but my Node did not get it. It was still sending “activations”. Always with a mix of Errors of No_Free_CH or Keys does not match.
Suddently at a random waiting time the “Join” was received by the Node and was then sending Data to the LoRa Network which i saw in my Application.
To extend on @kersing’s response a bit: indeed, gateways must adhere to a country’s legal maximum duty cycle. (And such maximum duty cycle is not some daily maximum, but applies at all times, 24/7, and is only related to the last transmission time.) But gateways are not affected by the 24 hours TTN’s Fair Access Policy. The latter only applies to devices, not to gateways.
True, as (current) gateways are half-duplex and cannot receive while transmitting, a network could also limit the number of downlinks that a gateway can transmit even though duty cycle regulations would still allow for it. But as far as I know, TTN has not implemented that. Also, a better solution would be to deploy more gateways, and to enforce the Fair Access Policy for devices (which is currently not enforced).
You’ll never get an error boldly saying “Keys does not match”. Instead, an RN2xx3 might suggest to make sure the keys (and coverage) are okay, but it will never know what’s the actual problem. To understand no_free_ch see Duty Cycle in the documentation.
Yes, you are right. From my RN i get the responses “Check your coverage, keys and backend status”
And after some time i get the “no_free_ch” message.
The reason why i get no Free ch is now clear. Its caused by the Duty Cicle regulation.
But how can it be that my node connects to the Network after i get “Check your coverage, keys and backend status”? It cant be the coverage because my Node sends the “Activation” to the Network. I can see this on the Data Tab and i see the GW that receive the Activation.
But all of a suddent after some cicles of no free ch and check your coverage it connects. What causes the Response: "“Check your coverage, keys and backend status”?
Is there noone with The same Problem? I Cant send data. Im Always Stuck in The activation circle. I See Join accepts in The gw but The node is Not getting it