Same type of device at remote location fails to join

End Devices (Nodes)
1

Here’s an additional question for you guys.
I have two nodes, node 1 like 20 meters from the antenna, and node 2 about 3 kilometers.
Node 1 joins perfectly fine, everything good.
Node 2 however, while being accepted by the gateway in about 3 seconds after a join request (accept join-request, forward join-accept message), does not receive any acknowledgement in return so hangs in the join process. The nodes are a LoPy4, both configured identically except for their AppEUI and AppKey.
Below the important code snippet if there’s any interest:

lora = network.LoRa(mode = network.LoRa.LORAWAN, region = network.LoRa.EU868, sf = settings.LORA_SF)
app_eui = ubinascii.unhexlify(settings.APP_EUI)
app_key = ubinascii.unhexlify(settings.APP_KEY)

print("Connecting to LoRaWAN", end = '')
lora.join(activation = network.LoRa.OTAA, auth = (app_eui, app_key), timeout = 0, dr = settings.LORA_DR)
while not lora.has_joined():
    print('.', end = '')
    sleep(0.5)

s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)              # create a LoRa socket.
s.setsockopt(socket.SOL_LORA, socket.SO_DR, settings.LORA_DR)   # set the LoRaWAN data rate
s.setblocking(True)

settings.LORA_SF is set to 12 and settings.LORA_DR to 0 in order to be sure.
The gateway is set to SF9 for RX2; maybe this will need SF12? I don’t really know the exact use for that.

Any ideas on why this could not be working?

2

One thought, have you tried switching the nodes around…near/far to see if problem goes with the node or the location?

We are also moving further away from thread title which may confuse future users… feel free to initiate a new thread with reliant subject and categories and we will follow you… :slight_smile:

3

3 seconds is a very very long time - what connection is the gateway on?

The whole setup only has 4.75 seconds to get the join-request to the network server and get the join-accept back the gateway for transmission.

I’d try Jeff’s suggestion. And whilst I’m driving/cycling/jogging back with the gateway, trigger a few joins so you can see how close it has to be to join.

And I’ve split this thread as well.

4

The fact that a node is heard by a gateway does not automatically mean that the gateway is heard by the node.
If there is noise on the frequency and the source of the noise is near the node the node will not receive the acknowledgement.

5

I hope I will have some time tomorrow to cycle around with one or both of the nodes. See how far an existing connection is able to maintain communication and the maximum join distance.

That does sound like the problem in this case then… I did not really time it with a stopwatch but if it’s about 3 seconds from node to gateway it sounds reasonable that it would take the same time in reverse.

What connection are you looking for here? WiFi / wired? It’s wired, at least 100MBit switch on 1GB connection to ISP. It is a school network which might employ a very small traffic delay but I’ve never had ANY problems with that - it would affect the node closeby as well, by the way.

I should add that there is quite a lot of rain today - I don’t know its effect on LoRa?

6

The results will be hard to interpret as the two main variables of ADR & coverage will require all sorts of domain knowledge to figure out.

That is definitely doable. Just cycle the power on the device every few minutes whilst you cycle the bike!

I’ve lost track, is the gateway on this college network? I’ve some firmware coding to do today, I’ll look at the logs to see what the transit time is from Bolton, through the checkpoint on the Northern Irish board to the EU servers (in Dublin) and back again.

Hard rain definitely attenuates the signal.

7

Thanks for the suggestions.
I haven’t tested the range yet, but I did some more testing with the node that’s ‘far’ away from the antenna.
The time difference between the serial connection telling me it’s trying to join, and the console showing “Accept join-request” is about 2.5 seconds. Then, it takes another 1 to 2 seconds before the “Forward join-accept message” appears - leaving no room for the downlink message to be received before the 4.75 seconds. This time there’s no single drop of rain, it’s partly clouded with a strong wind.

Is ADR enforced? My software manual is telling me that it’s disabled as default join setting (and the node closeby is properly sending same SF/DR all the time.

8

Rain reduces the signal strength, thankfully it has yet to slow the speed of light.

This is all down to the connection between the gateway and the servers for TTS CE.

Depends, not if you’ve turned it off on the device or it’s been turned off on the console (or both).

ADR optimises the transmission rate depending on signal strength and is best used for static devices. It takes time to adjust, so a moving node on ADR can easily lose contact with the gateways around it if it’s SF is low and the gateways are some distance away.

9

It would be good to check where the delay occurs. Certainly not in the radio waves going from node to gateway (unless someone changed the laws of physics while I wasn’t looking). The packet forwarder will also process the data almost instantly.

However if the working node uses the same gateway that and its internet connection are fine and aren’t the issue. You can check in the uplink packet which gateway(s) forwarded the data to TTN.

10

Is the far node in range of another GW? If so that may get chosen as prefered route for Join accept based on signal condition, even if backhaul connection slowr, rather than your GW or is join accept coming through your GW (see logs)

11

Our gateway log:
Screenshot 2022-02-17 152856
Node log:
image

12

Alright I stepped on my bike and conquered a storm while going to school and back home, but I’ve got more useful data.

First off: the delay between the device saying it is joining and the request showing up at the console is approximately the same whether the node is 20 meter from the antenna or 3 kilometers. I cannot time milliseconds by hand, but I don’t think there was a difference larger than 0.5 seconds if any. Physics still check out @kersing :wink:

The delay between both messages on the console (accept and forward) is also the same regardless of distance.

The total time it takes as seen from the node from sending a request to saying it has joined is about 10 seconds! I guess 5 seconds are due to the Rx1 delay, but that leaves another 5 seconds. On TTN V2 when the gateway still worked a couple of months ago, I remember that the total time took maybe 4 seconds including Rx1 delay…

See below for an image of the setup while cycling back home. One box configured as join once, keep sending every 30 seconds (sorry neighbourhood), other box configured as join every 30 seconds and send one message (again sorry neighbourhood). Interestingly, the box that would join once joined twice and did not manage to deliver all messages, but maybe that’s due to my setup. The box that joined again every time did manage to do so correctly up until almost my home at about 3 kilometers.

Back at home, I set both boxes at the top of the roof. The box that would rejoin everytime did not manage to get any acknowledgement after a few minutes, but the box that joins once managed to get the ackownledgement the second time manually rebooting, and is now happily delivering all its messages.

So… two questions:

  1. Why does the join time seem to be so slow? (or is it normal?)
  2. How could it be that every. single. join request is picked up by the antenna but so far only one ackownledgement is received at the node 3 kilometers from the antenna?

Weather is fully clear now, only thing I should mention is that at around 200 meters from my house is a building that’s about 5 stories high (still does not fully explain why one way is working but other one not, in my opinion).

The connecting node at home, as seen from the antenna:
image

The connecting node at home, as seen from the node:
image

The bike setup:
IMG_20220217_170346

1 Like
13

The signal as seen from the node (second picture 17:29:39) is very week. It is near the lowest limit the chipset is able to demodulate. The signal/noise-ratio is more than 15dB less, what is the reason for this?
I must admitt, I dont fully understand what I am seeing there.

14

That’s a very sharp eye! I checked the logs for a quite some more messages and most of them do not show an exact match. A couple do, a couple are not far off from each other, but some do show the same large difference, especially in SNR values. The node is typically reporting lower values than the gateway. RSSI is mostly quite close to each other.
Strange!!!

15

A low SNR-value can be an indicator for noise on the frequency.

16

I understand that, but why would the gateway and node report something entirely different?

17

Different algorithms to determine the values.

Also, the antenna for the node might be less sensitive when receiving.

18

Also node and GW will see different noise environments and hence show different SNR values - 3km away is huge for change in noise. Also note I regularly use usb power banks but you need to be aware they can be very noisy in themselves and best positioned away from radio vs clamped too unless you are working with known good strong signal…if at edge of reception I try to use alternate power sources.

19

Thanks for the suggestion on power banks.

Regarding the SNR values: the SNR value in gateway log is the noise level on gateway antenna but the SNR value in end point log is the noise level at the node?? How does the gateway know that noise level? It looks to me like the SNR value in end point log is just the same as the gateway.

20

Rough numbers from a Join here:

Serial log says:

2022-02-17 15:37:53 → LoRaWAN_Start
2022-02-17 15:37:53 → 6s810:TX on freq 868300000 Hz at DR 0
2022-02-17 15:37:54 → OnMacProcessNotify
2022-02-17 15:37:54 → 8s345:MAC txDone
2022-02-17 15:37:59 → 13s379:RX_1 on freq 868300000 Hz at DR 0
2022-02-17 15:38:01 → OnMacProcessNotify
2022-02-17 15:38:01 → 15s187:MAC rxDone
2022-02-17 15:38:01 → OnTxData - after transmission
2022-02-17 15:38:01 → OnJoinRequest
2022-02-17 15:38:01 →
2022-02-17 15:38:01 → ##### = JOINED = OTAA
2022-02-17 15:38:01 → First uplink in 5s
2022-02-17 15:38:01 →
2022-02-17 15:38:01 → OnRxData
2022-02-17 15:38:01 → Received: D/L FRAME:0000 | SLOT:1 | PORT:0 | DR:0 | RSSI:-99 | SNR:10
2022-02-17 15:38:01 → DOWNLINK:

This one is upside down so scroll in the box to see the details.

  {
    "name": "as.up.join.forward",
    "time": "2022-02-17T15:37:56.519017586Z",   <-- This is when it left the application server
    "identifiers": [
      {
        "device_ids": {
          "device_id": "x",
          "application_ids": {
            "application_id": "x"
          }
        }
      },
      {
        "device_ids": {
          "device_id": "x",
          "application_ids": {
            "application_id": "x"
          },
          "dev_eui": "x",
          "join_eui": "x",
          "dev_addr": "260BD10B"
        }
      }
    ],
    "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
      "end_device_ids": {
        "device_id": "x",
        "application_ids": {
          "application_id": "x"
        },
        "dev_eui": "x",
        "join_eui": "x",
        "dev_addr": "260BD10B"
      },
      "correlation_ids": [
      ],
      "received_at": "2022-02-17T15:37:56.517453194Z",
      "join_accept": {
        "session_key_id": "AX8IVS8iToAMfhNIXdFHfw==",
        "received_at": "2022-02-17T15:37:54.705234370Z"
      }
    },
    "correlation_ids": [
    ],
    "origin": "ip-10-100-15-123.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
    },
    "unique_id": "01FW45ADH7534T2RC3E1XW09YN"
  },


  {
    "name": "js.join.accept",
    "time": "2022-02-17T15:37:54.724582570Z",   <-- This is when it hit the application server
    "identifiers": [
      {
        "device_ids": {
          "device_id": "x",
          "application_ids": {
            "application_id": "x"
          }
        }
      },
      {
        "device_ids": {
          "device_id": "x",
          "application_ids": {
            "application_id": "x"
          },
          "dev_eui": "x",
          "join_eui": "x",
          "dev_addr": "260BD10B"
        }
      }
    ],
    "correlation_ids": [
    ],
    "origin": "ip-10-100-12-108.eu-west-1.compute.internal",
    "context": {
      "tenant-id": "CgN0dG4="
    },
    "visibility": {
    },
    "unique_id": "01FW45ABS41CY4HEHXNNSS6D9T"
  },
  • Device sends Join Request at 2022-02-17 15:37:53
  • Device console gets notification at 2022-02-17T15:37:54.724582570Z
  • App server sends out the Join Accept at 2022-02-17T15:37:56.519017586Z
  • Device gets the Join Accept at 2022-02-17 15:37:59

The serial log output has no decimal places and won’t be accurately aligned with the TTS time, but both on are on NTP so close enough. And there is the transmission time plus the whole serial port delays.

  • So, about 1 second to go from device to gateway to gateway server to network server to application server.
  • Join Accept leaves 1.79 seconds later - presumably takes about a second to thread through the gateway server and on to the gateway.
  • This is ~ 3.8 seconds.
  • Device reports arrival of transmission in first slot 6 seconds after it sent the join - allowing for rounding errors we can call that 5, as expected
  • There was 1.2 seconds spare.

These numbers are lacking in any rigor or precision, but it gives you some idea of timings.

Next time I do a join (in the morning), I’ll remember to leave the gateway console open and log in to the gateway log so we can see some much more accurate timings.