I have provisioned my LoRaWAN class A device using OTAA on the ThingPark Community platform. Now, it doesn't seem to receive a Join Accept message from the network as answer to the Join Request that is sent. What could be the issue here?
There are several reasons that may cause a failed join procedure. The typical problems are the following:
- The network server does not receive the Join Request because there are no LoRaWAN Gateways in the nighbourhood, or the gateway that is supposed to forward the message has no backhaul connection.
- The network server receives the Join Request but silently ignores it because the device is provisioned with incorrect DevEUI, AppEUI/JoinEUI and AppKey.
- The network server receives the Join Request and answers it by a Join Accept message, but the device does not receive it because the downlink message is sent with wrong TX parameters (Channel number, RX1/RX2 delay, Spreading Factor, etc.)
In the first two cases, you won't see any messages in the Wireless Logger application however, in the 3rd case you will see both the Join Request and the Join Accept.
If you can see the Join Accept message in Wireless Logger and your device keeps sending new Join Requests, it is most probably because the Join Accept is not sent with the TX parameters that are expected by your device. All TX parameters can be verified in Wireless Logger.
The expected initial TX parameters may change device by device and that is why ThingPark introduced the concept of device profiles. When you provision your device it is important to select the right device profile that tells ThingPark what channel, datarate, RX delay, DL data rate offset should be used for sending the first downlink message which is obviously the Join Accept message. If your device does not have a pre-configured device profile on ThingPark yet, you can chose one of the Generic device profiles, that is compatible with your device.