Inconsistent/Unreliable Join Issues

End Devices (Nodes)
1

I’m having issues with getting my node to join the network. Here’s the summary:

Node: https://northernmechatronics.com/products
Gateway: RG191
Stack: Semtech
Code: Class C example

Since last week I’ve learned that I can mask the channels I transmit on to use only the 8 which my gateway listens on. Now I am able to see my node request a join on maybe 5-6 out of the 8 channels that it attempts to use but usually no response to any of them. After that I get an error from the stack indicating that there are no channels left for it to try on (as expected).

Once in a blue moon the response will come back and I’ll be able to join after which messages are delivered fairly consistently so it seems like it’s not an issue with keys but I don’t understand what’s causing it to be so inconsistent.

2

TTN at this moment supports only class A… soon the V3 stack will be released that supports class C

1 Like
3

Okay I’ve now tried with the ClassA example and I’m seeing the same behavior. Sometimes the messages have a hard time even getting to the gateway. However if I select ABP activation then the messages arrive much more consistently.

Is there any way to debug why a particular join request isn’t acknowledged?

4

can you make a console screenshot of a join attempt

5

I’ve discovered an issue with regards to antenna selection in my code. With that fixed the connection to the gateway seems much more reliable. Now I just need to sort out the join. I haven’t had a successful join in a few days now so I will double check all the EUIs but here’s a capture of what I’m seeing now.

I’m not sure if the dev EUI is relevant but I believe I read that it should not be shared freely so I’ve redacted it.

Event Data:

{
  "gw_id": "jtdc-lorawan-test0001",
  "payload": "AN/uANB+1bNwB5A3ajI3OTgIAFrlBsA=",
  "dev_eui": "XXXXXXXXXXXXXXXX",
  "lora": {
    "spreading_factor": 10,
    "bandwidth": 125,
    "air_time": 370688000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-11-11T19:31:17.807Z",
  "rssi": -55,
  "snr": 12.75,
  "app_eui": "70B3D57ED000EEDF",
  "frequency": 904500000
}

capture1

6

yes, and from what I see the node and gateway are very close and that can have a negative influence to.
try SF 7

7

I was able to join successfully again so I’m fairly certain the EUIs and keys are correct. However the join response is still very unreliable. 80-90% of the time it goes through all 8 channels without successfully connecting. I tried changing the SF to 7 but the console still shows it as 10 until it joins. Then when it joins it drops down to the value I set it to. It’s strange because the example uses the same data rate definition in the join procedure as the tx.

Here’s the data for a successful join if that helps narrow things:

Join Request:
{
  "gw_id": "jtdc-lorawan-test0001",
  "payload": "AJtFAdB+1bNwEQAA/wCW2kgHAJuyjKk=",
  "dev_eui": "xxxxxxxxxxxxxxxx",
  "lora": {
    "spreading_factor": 10,
    "bandwidth": 125,
    "air_time": 370688000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-11-11T20:13:52.612Z",
  "rssi": -64,
  "snr": 12.25,
  "app_eui": "70B3D57ED001459B",
  "frequency": 904100000
}

Join Accept:
{
  "gw_id": "jtdc-lorawan-test0001",
  "payload": "IEiup9CREQ1PLBHJJ8DQW5g=",
  "lora": {
    "spreading_factor": 10,
    "bandwidth": 500,
    "air_time": 82432000
  },
  "coding_rate": "4/5",
  "timestamp": "2018-11-11T20:13:56.613Z",
  "frequency": 923900000
}

capture1

8

It seems like I’ve discovered a pattern to this which may present a clue. If I create a new device in an application I get a join accept immediately on the first request, and then up-links come through consistently. If I then reset the device the second join request accepted and then up-links are consistent. If I reset again then the 3rd join request gets accepted and so on. Finally on the 8th reset (9th boot) we run out of channels and it never accepts my join request.

I’ve reproduced this behaviour multiple times now. I must be missing something with regards to how these joins work. Does the above behaviour indicate something?

9

So, TTN Console is not showing a Join Accept if the join fails? Then I assume OTAA shows "Activation DevNonce not valid: already used"?

(Ah, your screenshot indeed confirms no Join Accept is created. Click the Join Request for more details.)

10

Hmm this seems to make sense. A quick check in the Semtech FW shows that the DevNonce is just incremented on each boot which would explain the behavior I’m seeing.

Is there anyway to clear this on TTN without having to delete the device? I’m guessing the firmware should probably handle this differently (ie random value).

Lastly, I’ve been looking at the details of the join request but I’m not sure where to find the details I’m looking for. Is it in the payload? If so how do I decode that?

11

Well, like noted in the topic I linked to:

…and:

Yes, an online decoder will give you the DevNonce.