There is no join request on the gateway or device console.
Double & treble check the various keys as programmed into the device and as set in the device/applications console… look for obvious errored characters (B’s & 8’s, e & c, etc.)
I’ve entered in these keys about 30 times now. There is no join request on the application. From the serial console this is what I get:
Starting
Packet queued
1681: EV_JOINING
1960: EV_TXSTART
403714: EV_JOIN_TXCOMPLETE: no JoinAccept
411281: EV_TXSTART
791668: EV_JOIN_TXCOMPLETE: no JoinAccept
1636512: EV_TXSTART
2038274: EV_JOIN_TXCOMPLETE: no JoinAccept
It just cycles through this.
If there’s nothing on the gateway, node probably didn’t actually transmit but only though it had. Or if it did, it did so on the wrong frequency plan for your area, or at least for your gateway (if turns out that the gateway setup is what’s wrong).
UPDATE:
Turns out the spreading frequency was the issue. When I change it from the recommended spreading factor of SF9 to SF12 on the TTN, it once again works. Not too sure why this is, but if anyone has any insight I’d appreciate it.
Where? On the console? In the sketch? By being specific others finding this thread will be helped.
In the application setup process on the TTN. When setting up the device, changing the frequency plan to SF9 to SF12 worked.
No. As previously explained RX2 customization does not apply to join accepts, but only after.
Whatever your issue was, it was something else and this change was only coincidence.
1 Like
If I change it back it no longer works. Changing it again to SF12 works. There is clear correlation.
That being the case, there is something distinctly odd going on and as some point you will end up running out of airtime or, as the LoRaWAN Alliance require operators to limit the use of SF11 & 12, probably everything. Or nothing. Who knows. It’s just hacking until it works which isn’t great for a community network.
Where is your gateway situated in all of this - indeed, what sort of gateway is it?
The gateway is connected to the Things Network. Similar to the nodes, the brand is Dragino LPS8.
No, this is confusion. The LoRaWAN spec is very clear. This is just NOT how LoRaWAN works. RX2 for join accepts is always SF12, regardless of any customization that might apply after the node has joined, hence that setting is entirely irrelevant to the success or failure of a join attempt.
We investigate problems logically here, we do not make unfounded claims that purport to contradict thoroughly established facts.
OK, a known good gateway.
Did you see the notes in the TTN-OTAA.ino that say which way round the EUI’s go?
Have you changed lmic_project_config.h to your region? What is your region?
How far apart is the gateway & the device - too close and they can overload each others input stages.
The config file is set to “CFG_eu868”. In terms of endianness, I have put it the right way round. EU is the region I have selected.
I don’t think I’ve had issues before with the gateway and device being too close.
I have now tested it again using SF9 and it works. Apologies for leading you on a wild goose chase. Maybe some sort of bug or error occurred?
Lucky you. Search the forum, you’ll see others do. And it’s so easy to try out.
With kindness, we have no idea, as mentioned above, we have no real handle on exactly what you have been changing.