RX2 Data Rate Selection on Join Accept

End Devices (Nodes)
1

Hi Guys, I have an end device configured to use SF9 for RX2 (Europe 863-870 MHz (SF9 for RX2 - recommended)). The join process is successful up until transmission of the JOIN_ACCEPT, it would appear that the JOIN_ACCEPT is not getting received/processed by the end node. Examining the
“ns.down.join.schedule.attempt” message reveals the following:

      "join_accept_payload": {
        "net_id": "xxxxxx",
        "dev_addr": "xxxxxxxx",
        "dl_settings": {
          "rx2_dr": 3
        },
        "rx_delay": 5,
        "cf_list": {
          "freq": [
            8671000,
            8673000,
            8675000,
            8677000,
            8679000
          ]
        }
      }
    },
    "request": {
      "downlink_paths": [
        {
          "uplink_token": "xxxxxxxx"
        }
      ],
      "rx1_delay": 5,
      "rx1_data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 12,
          "coding_rate": "4/5"
        }
      },
      "rx1_frequency": "868300000",
      "rx2_data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 12,
          "coding_rate": "4/5"
        }
      },
      "rx2_frequency": "869525000",

The rx2 DR is 0 and not 3 as specified in the JOIN_REQUEST - I suspect this is my problem. Any assistance/recommendations/clarifications would be greatly appreciated.

Thanks

2

The default Rx2 datarate per spec is DR0. So a LoRaWAN stack that is exactly to spec will by default listen to Rx2 @ DR0.
If a gateway cannot send the Join-accept in Rx1, it will be scheduled in Rx2 - now at which DR would that be? Exactly, at DR0 since the node isn’t informed about listening Rx2 @ DR3 yet as that is part of the Join-accept!
Now if you look at subsequent downlinks, you should see that it switches over to Rx2 @ DR3.

2 Likes
3

The join request does not contain a field to tell the LNS the node expects RX2 to use DR3. The join accept does contain information on RX2 settings, the LNS is in the lead and pushes those settings to the end device.
If you (accidentally) forced RX2 to use DR3 in your software, please undo that as the standard mandates RX2 uses DR0 for RX2 during the join cycle.

What hardware and software (LoRaWAN stack) are you using?

1 Like
4

How is your gateway connected to the internet?

The most common causes of your node not joining in RX1 is that the packet arrived to late from the LNS (latency between LNS and gateway), and then when the latency is to great, RX2 are missed as well.

I am not ruling out prevailing RF conditions or the stack been used.

5

You’ve created a meta-physical problem along the lines of Schrödinger’s Cat, so as required by my user name, I have to reply.

I too will be interested to know what stack allows you to change the Rx2 via API - I know where to change it in the code in LMIC & LoRaMAC-node but the absence of any API call implies a lot.

6

Thanks for the clarification, I was under the impression that the join process would use SF9 as the RX2 data rate. I will check with the node supplier as to what they have implemented, it could also be a case of incorrect rx1 delay settings.

7

Thanks for the clarification, using Eastron single phase electricity meters as the end node and have an SLA with The Things Stack.

8

Check you gateway latency.

1 Like
9

Not quite what Jac meant - the backend is assumed to be TTS on here - it was the code in the device - the firmware - the device side stack that was being referred to.

The SLA is about up time of the servers, it can’t cover the backhaul as it could be going over anything.

The join process settings are set in stone in the specification …

10

I think there’s a minor misunderstanding, so here’s the complete flow:

  • the device should have implemented the default regional parameters, which for EU868 mandates Rx2 @ DR0.
  • at the time of sending a JoinRequest (JR), the device is completely unaware of what you configured at the console, so it will transmit a JoinRequest and subsequently listen at Rx1 @ JR-datarate, and if it fails to receive in Rx1, it will switch to Rx2 @ DR0, as that is what the spec says.
  • when TTS network server receives a JoinRequest and all is good, it will schedule a JoinAccept. Hopefully in Rx1 @ JR-datarate, but in case it needs to fallback to Rx2, it will do so at DR0, as that is what the device expects.
  • the JoinAccept contains Rx2 settings, to be used for all subsequent downlinks. As you configured the network server to use SF9 for Rx2, the JoinAccept will contain this setting, and therefore the device will listen for Rx2 @ DR3 for all subsequent downlinks.

The devil in the detail is that the JoinAccept might be transmitted in Rx2 @ DR0, since the device is unaware of your configuration before it has joined… so the JoinAccept will use SF12/DR0 for the Rx2 window, which is what you saw.

1 Like
11

If you haven’t got too far in to the weeds with this device yet, then NOW is the time to do a forum search (again, as surely you will have already done so) for Eastron - this device has come up before …

1 Like
12

That I have done, I think I’m taking the arrows for a new implementation here, have used Eastron in the past without issues - this is the first time we are using SF9 for rx2. I hope that they have implemented the join process correctly within their firmware and that the device is listening on DR0 at rx2. Thanks

13

Additional information, end device using MAC_1_0_2.

14

That is part of the certification checks solid the device is certified I wouldn’t worry about that.

If the stack is certified it should join, however gateway to LNS (and vice versa) delays and RF issues might cause things to fail. What are the SNR and RSSI of the join requests?

Are you using the right version of the regional parameters?

15

The SNR and RSSI values are not that great, -18 and -117 respectively on average. I do have some that are good (e.g.: 8.3, -101) that are behaving the same. Regional parameters set to: RP001 Regional Parameters 1.0.2 revision B, but I’m confirming this with the manufacturer.

I am also considering installing a second gateway.

16

I’d be very tempted to get a unit and test it in controlled conditions with the appropriate separation between gateway & device - then you aren’t subject to a vast range of factors outside your control.

It’s still not clear how you ended up being able to specify the Rx2 setting - is that in the device config? Last I checked Eastron’s links to manuals were broken so it’s hard to know what facilities they provide.

1 Like
17

Yip, busy doing this right now…

18

Setup duplicate system and works perfectly in the lab. Settings:
MAC 1.0.2 - Rev B Regional Settings
Support Class C
RX1 delay 5 secs
RX1 DR offset 0
RX2 DR 3
RX2 Freq 869.525
ADR Dynamic

Conclusion: Signal weak, antenna performance on gateway better than that of the end node, gateway is receiving node transmissions but the node is not receiving the gateway transmissions.

1 Like