Microchip's Mote OTAA Join Req. Denied!

1

I am using Microchips LoRa Development kit.

Currently I have set up the Gateway and its status is connected. I have also registered the application as per the start-up guide provided - see below link for the guide.

https://www.thethingsnetwork.org/labs/story/setting-up-your-own-gateway-and-endpoint-with-microchips-lora-technology-evaluation-kit

However, when I go to connect using Microchips LoRa Development Utility I get the following…

mac join otaa
ok
denied

If I keep joining - as I heard this sometimes resolved the issue, I get…

mac join otaa
no_free_ch

When viewing the ‘Data’ tab on my set-up application device I receive the activation that is being denied, so why is this not being accepted?

Thanks in advance

2

What does your gateway tell you?

What does the TTN web console tell you about the join request?

How far apart are these modules?

3

I believe this may have something to do with the downlink as when I tried communicating over ABP and the uplink worked fine when using Microchips Dev Utilities Server, but could’t get a confirmed message to be confirmed.

What specific information would you need from the Gateway? But it does show the correct EUI ID and IP addresses. Also, the traffic on the TTN console - Gateway shows the traffic in the 868 freq band; mod 4/5; SF 12; BW 125; airtime 1482ms

Here is the Metadata from the join request.

{
“time”: “2020-09-01T10:52:10.193915252Z”,
“frequency”: 868.3,
“modulation”: “LORA”,
“data_rate”: “SF12BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-****************”,
“timestamp”: 1156095852,
“time”: “”,
“channel”: 1,
“rssi”: -49,
“snr”: 8.8
}
]
}

The distance is not an issues as the Node and Gateway are within 5 meters. Also tried this within 1 meter.

4

Far too close - your gateway may well giving your device a real headache aka overloading it.

So, you have got the request showing in the TTN console but at present you haven’t got the join response arriving on the device? Does your gateway get the join response?

5

Please try another SF, RN2483 modules are known to have issues when using SF12 regarding downlinks.

6

Yes, that is correct, the Application receives the activation and the gateway receives the Join, but it does not do so every time the activation received on the TTN Console. This is the only information that shows up in the Traffic and Date for both Gateway and Applications, respectively.

7

UPDATE:

I realised my Mote RN2483 was running on the old firmware (1.0.1). I have now updated to 1.0.5. After doing this and a bit of fiddling my Mote board connected to the gateway and I was able to uplink a message. But that’s where the good news ends… I was not able to uplink more than one message and on attempts to reconnect to the gateway I keep getting denied.

8

Do you mean the join-request or the join-accept? Does your gateway transmit the join-accept and if it does, on which window?

9
  1. Too close to the gateway? Anything below 5 meters is too close.
  2. EUIs and key don‘t match? Have you checked messages in the console? For both gateway and application?
10

So when viewing the TTN Console Gateway Traffic it receives the Join-request. It is weird, just tried with another module and the same thing has happened with that one. After registering it on the TTN applications my first join request was busy. I then tried to connect again and was accepted, but this time unlike with the other module it didn’t transmit data. So my issue is that after registering an application I only get one or two Join-accepts from the Gateway Traffic and thereafter it does not accept my requests.

11

When I successfully connected and uplinked data I was close to the Gateway. I have now moved further away and still suffer similar issues

UPDATE: I’ve checked the EUIs and compared them and the ones that are not being accepted EUIs DO match, however, still getting Denied.

12

Have you checked in the application data tab? If you are not seeing the join requests in the application you need to check the AppKey as that might not match. For a node to join successfully the DevEUI, AppEUI and AppKey need to match. And of course the transmission must be correctly received by a gateway and the join response data must be received by the node.

RN2483 modules are known to have issues when receiving at SF12, so avoid that data rate. Given that your node and gateway are close (<100m) you should use SF7 anyway.

13

Yeah I read more into the documentation yesterday - I’m new to LoRa.

So I found out that when I was using the LoRa Development Utility it kept reseting the SF back to 12. Because of this, I then manually configured via a terminal. Long story short after reducing the spread factor from 12 to 7 I now get accepted request on the terminal.

Essentially I have solved all issues but one. After being accepted I go to transmit a message to the server. this gets confirmed, but never seems to reach the Uplink data log on the Application Console. Any ideas?

Below is the command I am sending after being confirmed. Note I have tried numerous Hex values and ports.

mac tx uncnf 1 31
ok
mac_tx_ok

14

You really should not keep re-joining. The design intent is that you join once, and stay that way for months or even the entire lifetime of the device.

Each join needs a new join nonce, which is not re-usable, and attempt to join with a nonce already used for the device will be ignored.

Note also that “denied” is not really a result - there are two things that can happen:

  • The server can see the request, but ignore it

  • Some part of the process can break down, for example the request is not seen, or backend communication breaks, or the response is not transmitted or received, or the node listens at the wrong time or frequency

But “denied” implies a sort of communicated refusal, which simply does not happen in LoRaWAN.

The closest thing to a denial which actually can occur is a log message internal to the server indicating why it is ignoring a join request.