RX2_DELAY - please clarify

ChirpStack Network Server
1

Hello,
I am using OTAA join for EU433 band and everything is working correctly.
Next, I am trying to change RX1 delay from 1 second (default) to 2 seconds.
This is what I found

  1. RX parameter (re)configuration - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server

  2. [network_server.network_settings]

    Class A RX1 delay

    0=1sec, 1=1sec, … 15=15sec. A higher value means ChirpStack Network Server has more

    time to respond to the device as the delay between the uplink and the

    first receive-window will be increased.

    rx1_delay=1

What i did
I set
[network_server.network_settings]
rx1_delay=2
and restarted the LoRa server
I expect that RxTimingSetupReq would be sent to nodes during OTAA Join but it is not.
This is my Join request log from device
7c6dd531557ebe200a1af26c99b8c91

Any help would be greatly appreciated.

2

This is a mac-command. Mac-commands are not sent as part of the OTAA join-accept. Please note that the join-accept message does contain the RX1 delay value.

3

Thank you for your reply.
when RxTimingSetupReq will be sent to device?

image
image1920×969 126 KB

What could be the “first opportunity”?

5

Bringing up this question again after long time. It seems that my device never receives RxTimingSetupReq packet, even after multiple uplinks and downlinks. Is it possible to see the sending of RxTimingSetupReq in the Chirpstack network server logs?

6

It seems that my device never receives RxTimingSetupReq packet, even after multiple uplinks and downlinks.

Why do you think one should be sent?

LoRaWAN doesn’t support a unique setting for the RX2 delay as mistakenly mentioned in your title, it’s simply 1 second after the RX1, whatever that is.

The RX1 delay in effect when a node does an OTAA join is communicated in the join accept, so there’d be no need to send it again.

It seems like the only reason why it would need to be communicated in isolation would be if you change the configuration on the server after a node has done its join.

Perhaps the key question would be, is your desired timing perhaps already in effect? If you look at the timing of any downlinks which are being sent, what is their microsecond timestamp or GPS time difference from the uplink to which they correspond?

7

It seems clock issue on the device. calibrate the clock

8

Hello,
sorry, it is not about RX2 delay. It is about the RX1 delay, which I need to send from server to device. My device default RX1 delay is 1 sec. On server I configured 2 sec. As per documentation and the above answer to my post, RX1_dealy is sent using RxTimingSetupReq packet. So my question is, when is it sent and how to check (in logs?) if it has been sent.
Thanks

9

Not usually it isn’t.

The RX1 timing is sent in one of the fields encoded in the join accept, and usually that’s all that’s ever needed.

After that there would be no need to send it again - actually, it wouldn’t even be possible to send it again, since if the delay specified in the join accept wasn’t being used by the node, it wouldn’t be possible to get a message to the node at all.

The only time it would make sense to use the MAC command would be if the setting of an already joined or ABP node were being subsequently changed. Then, at least in theory, the old downlink timing setting could be used to downlink a packet specifying the new one.

10

OK, so it is sent during join accept. Now clear. This is my successful join request.
image
I am not sure, if RX1_DELAY is encoded in it or not. But after the join, RX1_DELAY remains as it was before, 1 sec. So I want to make sure that the server sends it correctly before starting to dig on the device side.

11

It always is, this is part of the LoRaWAN spec. If you want to know what the value sent in the particular join accept is, you’ll have to decrypt it.

How are you determining that?

12

After the join, I am using terminal commands of my module to get RX1_delay value and it is always 1 second.

13

Perhaps that doesn’t reflect configuration commanded by the network.

What is the difference in microsecond timestamps between subsequent uplink and downlink as seen at the gateway?

Are you absolutely sure you changed the setting in Chirpstack for this node?

14

I changed config option of Chirpstack network server like this
image

15

Seems like the next steps are to check the timing actually being used to send downlinks.

16

Thank you @cstratton for your support. I did look at the gateway (which is RACK7249) logs to get the timings as you suggested.

This is the join request packet

{
    "freq": 507300000,
    "mode": "timerstamped",
    "utmms": 1648604658810,
    "tmst": 627361436,
    "rfch": 0,
    "powe": 14,
    "prea": 8,
    "ncrc": false,
    "modu": "LORA",
    "datr": "SF12BW125",
    "codr": "4/5",
    "ipol": true,
    "size": 33,
    "data": "IPh6HSELA9xbqgKLiIKFb6UnJC1cMyH5JFaGeDsVGgmD"
}{
    "MHDR": {
        "MType": "Join Accept",
        "RFU": 0,
        "Major": 0
    },
    "JoinAccept": "F87A1D210B03DC5BAA028B8882856FA527242D5C3321F9245686783B",
    "MIC": "151A0983"
}

This is the join accept packet

{
    "freq": 507300000,
    "mode": "timerstamped",
    "utmms": 1648604658810,
    "tmst": 627361436,
    "rfch": 0,
    "powe": 14,
    "prea": 8,
    "ncrc": false,
    "modu": "LORA",
    "datr": "SF12BW125",
    "codr": "4/5",
    "ipol": true,
    "size": 33,
    "data": "IPh6HSELA9xbqgKLiIKFb6UnJC1cMyH5JFaGeDsVGgmD"
}
{
    "MHDR": {
        "MType": "Join Accept",
        "RFU": 0,
        "Major": 0
    },
    "JoinAccept": "F87A1D210B03DC5BAA028B8882856FA527242D5C3321F9245686783B",
    "MIC": "151A0983"
}

timestamps: join request 1648604658601, join accept 1648604658810. Difference 209 ms.

This is the uplink packet

{
    "freq": 486900000,
    "chan": 7,
    "tmst": 1635184628,
    "utmms": 1648605671392,
    "rfch": 0,
    "stat": 1,
    "rssi": -94,
    "size": 18,
    "modu": "LORA",
    "datr": "SF7BW125",
    "codr": "4/5",
    "lsnr": 7,
    "data": "gDYtpgWACwAIJFJ43zt+rPCn"
}
{
    "MHDR": {
        "MType": "Confirmed Data Up",
        "RFU": 0,
        "Major": 0
    },
    "MACPayload": {
        "FHDR": {
            "DevAddr": "05A62D36",
            "FCtrl": {
                "ADR": true,
                "ADRACKReq": false,
                "ClassB": false,
                "ACK": false,
                "FOptsLen": 0
            },
            "FCnt": 11
        },
        "FPort": 8,
        "FRMPayload": "08 24 52 78 DF "
    },
    "MIC": "7EACF0A7"
}

This is the downlink packet

{
    "freq": 507300000,
    "mode": "timerstamped",
    "utmms": 1648605671676,
    "tmst": 1637184628,
    "rfch": 0,
    "powe": 14,
    "prea": 8,
    "ncrc": false,
    "modu": "LORA",
    "datr": "SF7BW125",
    "codr": "4/5",
    "ipol": true,
    "size": 12,
    "data": "YDYtpgWgCQBNaDcr"
}
{
    "MHDR": {
        "MType": "Unconfirmed Data Down",
        "RFU": 0,
        "Major": 0
    },
    "MACPayload": {
        "FHDR": {
            "DevAddr": "05A62D36",
            "FCtrl": {
                "ADR": true,
                "RFU": 0,
                "FPending": false,
                "ACK": true,
                "FOptsLen": 0
            },
            "FCnt": 9
        }
    },
    "MIC": "4D68372B"
}

Timestamps: uplink 1648605671392, downlink 1648605671676, difference is 284 ms

So, the round trip between gateway and server is < 300ms
Datarate was SF7BW125, which gives 5470 b/s. Total data length of uplink and downlink 40 bytes.
Time on air would be < 10ms
The total round trim between this particular device and server is < 310 ms
It seems that default RX1_delay of 1 second is enough.

But I have 500 devices in the field in different conditions sending frequently and sometimes DR is 0 or 1. Some downlink packets are get enqueued in device TX queue but never sent. Application just keeps adding downlinks to queue. To solve this problem, i was going to try increase RX_delay. I don’t know, if it will help but anyway, I am not able to do it.

17

Your downlink tmst of 1637184628 follows your uplink tmst of 1635184628 by exactly 2000000 microseconds.

And the SF7 makes it clear that this is RX1 not RX2, so Chirpstack is commanding the gateway to transmit with your requested 2 second RX1 delay.

If the node is receiving downlinks then it looks like everything is working the way you wanted - using the 2 second setting you requested, as communicated in the join accept packet the way things are designed to work under the LoRaWAN spec.

18

Ahh, now it’s clear :sleeping:. I was confused by the fact, that node reported 1 second as RX1_delay. Thank you @cstratton