OTAA activation fails - is this caused by distance?

1

Hi all,

I’m looking into a problem we’re seeing with activation/join of a device. All I’m seeing on the data tab for the device are lots of Activations:

image

After digging through the gateway logs I can see:

JSON up: {"rxpk":[{"tmst":813635164,"time":"2020-04-16T11:12:56.665149Z","tmms":1271070776665,"chan":7,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":-4.8,"lsnr_min":-9.2,"lsnr_max":-1.8,"rssi":-120,"size":23,"data
":"AAABAAAAAACgR8iBAQBBQKj0ks8Kav4="}]}

Decoded:

Assuming base64-encoded packet
AAABAAAAAACgR8iBAQBBQKj0ks8Kav4=
Message Type = Join Request
  PHYPayload = 0000010000000000A047C88101004140A8F492CF0A6AFE
( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
    MHDR = 00
  MACPayload = 00010000000000A047C88101004140A8F492
     MIC = CF0A6AFE
( MACPayload = AppEUI[8] | DevEUI[8] | DevNonce[2] )
  AppEUI = A000000000000100
  DevEUI = A84041000181C847
DevNonce = 92F4

and then

JSON down: {"txpk":{"imme":false,"tmst":818635164,"freq":868.5,"rfch":0,"powe":14,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":33,"ncrc":true,"data":"IMP/IJD4aY6yt2zDy/upJk8CxNHv6JGe0OqwKD5XG3ie"}}

Decode:

Assuming base64-encoded packet
IMP/IJD4aY6yt2zDy/upJk8CxNHv6JGe0OqwKD5XG3ie
          Message Type = Join Accept -- WARNING: The values below have not been decrypted
            PHYPayload = 20C3FF2090F8698EB2B76CC3CBFBA9264F02C4D1EFE8919ED0EAB0283E571B789E
          ( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
                  MHDR = 20
            MACPayload = C3FF2090F8698EB2B76CC3CBFBA9264F02C4D1EFE8919ED0EAB0283E
                   MIC = 571B789E
          ( MACPayload = AppNonce[3] | NetID[3] | DevAddr[4] | DLSettings[1] | RxDelay[1] | CFList[0|15] )
              AppNonce = 20FFC3
                 NetID = 69F890
               DevAddr = 6CB7B28E
            DLSettings = C3
               RxDelay = CB
                CFList = FBA9264F02C4D1EFE8919ED0EAB0283E
DLSettings.RX1DRoffset = 4
DLSettings.RX2DataRate = 3
           RxDelay.Del = 11

So the Join Request is reaching the gateway. The gateway is sending a Join Accept but for some reason the device is not receiving this and, I assume, is sending another Join Request.

Additional Details
The distance between the device and gateway is about 250m.
The gateway is TTOG.
The device is a Dragino LHT65
We are using OTAA activation.
We normally activated before deploying but in this case forgot and so were trying to activate at distance.

My Theory

Because of the relatively long range between the gateway and device and the relatively poor antenna on the device compared to the gateway, uplink (the initial join request) is received fine but the device is unable to receive the downlink Join Accept with it’s new keys.

I’ve done some googling but haven’t been able to find much information on the difference in range between an up and downlink given the different properties of a gateway and device, although logically it makes sense that the gateway has a better ability receive than a a device does.

I’ve also been unable to find any advice that an activation should be done in closer proximity to a gateway than standard operation where only uplinks are generally important (until you want to change something via a downlink, that is).

Would this lack of ability to activate also signify a likely issue with getting downlink messages to the device?

Would anyone be able to confirm or deny my theory based on the information I’ve provided? Would be much obliged.

Many thanks

2

The antenna would have to be very bad not to be able to receive downlinks at 250m but the rssi of the uplink is not great so the antenna combined with the position of the node could well be an issue.
That same issue will apply to all downlink packets as well.

The device is currently using SF7 which results in the least coverage. If you can force it to use SF8 or SF9 it might well join the network.

3

Quick update.

I moved the sensor approximately 10m closer to the gateway, re initiated a join and it worked straight away, so this must have been a range issue. Thanks for your input @kersing.

I can now see that the node is using SP10 or SP12.

4

Also note that if there is a range or downlink issue it may take more than 3 minutes (in the log shown above) before a join accept is successfully received because (depending on the client/library/settings used) the join request will usually start at the lowest SF, do a retry on the same SF if it does not receive a join response, and if then still no join response is received it will increase SF and retry again, and repeat until the highest SF has been reached. The intervals between each retry quickly become 1+ minute so it may take a while before it tries the join at SF10, SF11 or SF12.

(I have updated the topic title because in LoRa terminology 250m is not really long range, especially when having an outdoor gateway with good antenna.)

1 Like
5

FYI: Always check the gateway traffic (if you own it in TTN) to see if the join accept is sent. This won’t be shown in the device traffic.

1 Like
6

Indeed the Join Accept (green icon) is never shown in the device’s Data page. But it might also not be shown in a gateway’s Traffic page if the Join Request was received by multiple gateways, and TTN has selected one of the other gateways to transmit the Join Accept.

However, if TTN rejects a Join Request then you will not see the Activation (orange icon†) in the application’s or device’s Data page, and not see the device’s Last seen time change. So, seeing any of those tells you that TTN accepted the Join Request and has assigned a new DevAddr, AppSKey and NwkSKey. In that case, unless one is running into Activation not valid - no gateways available, one can assume that the Join Accept will still have been delegated to a gateway.

Another aside: seeing a Join Accept in the gateway’s Traffic page will tell you when TTN has delegated the Join Accept to a gateway, not when a gateway has transmitted it. A gateway might still be unable to actually transmit it, if it receives the downlink too late (like due to network latency).

† Don’t confuse the orange icon for the Activation in the application’s or device’s Data page with the orange icon for the Join Request in the gateway Traffic page.

3 Likes
7

Perhaps a silly observation, but is your APP EUI correct?
AFAIK, TTN creates APP EUIs typically starting with 70 B3 …

Did you perhaps swap the device EUI with the App EUI?

8

No, it’s all correct. The above was from a dragino device, see: Dragino LHT65 and network coverage

9

Hello guys,

I’m facing the same problems. I bought a couple of dragino nodes and but aren’t able to join the devices. In my opinion all data (DEV EUI, APP EUI, APP KEY should be correct. I’m using an outdoor antenna and try to join the devices just below the antenna. I did the same process in the beginning of February and faced no issues. A difference to mention, that the APP EUI for my new devices are now unique (I was able to activate my previous devices with non-unique APP EUI, the famous A000000000000101)

Schermafbeelding 2020-05-28 om 16.34.09

Hopefully someone can help me out

Thanks in advance.

Best regards,

Albert Post

10

Given the rapid succession in retries the gateway might be running out of airtime to send replies. Other circumstances might also prevent the join response to reach your node.
What is the distance between gateway (antenna) and node? Is it at least 3 meters to prevent overloading the receiver circuits of the gateway? Can you show the meta data of one of the join requests?

11

Hello Jac,

Thanks for your prompt reply.

Schermafbeelding 2020-05-28 om 16.34.57

Thanks

12

Did you notice the remark regarding distance between the node and the gateway antenna?

What brand and type of gateway are you using?

13

Hello Jac,

The type of the antenna is SIRIO GP 868 C and is at a height of 6 meters and I’m standing with my 1.78m beneath it. :smiley: . The gateway is a Dragino LG308.

14

May-be you should increase the distance a bit. Try a couple of meters.

15

Hello Jac,

I now have succes with joining the devices. I bought an extra gateway for test purposes and activation was a success in a minute. As you mentioned it has something to do with the distance / transmission intensity. I will do some tests in the coming months to get more details why this is happening.

Thanks for now.

Best regards,

Albert

1 Like
16

Hi, I don’t know if it helps, but you can also have this kind of issues if you have a gateway connected in 3/4g or with a bad connection, because the join accept arrives too late.

1 Like
17

Hi, I am getting the same activation issue with my gateway connected in 4g. Is there a way to fix this issue?

18

You need a provider with lower latency so you’ll have to explore the options locally to you.