RX2 configuration mac commands

ChirpStack Network Server
1

I have a node configured to join using OTAA mode. The loraserver is configured with rx2_dr=5 and rx2_frequency=869525000. The node joins successfully however the downlink datarate is never configured as in the loraserver.toml file. Please see below:

{“applicationID”:“6”,“applicationName”:“multicast_app”,“deviceName”:“device_a”,“devEUI”:“240ac4fffe0bf994”,“txInfo”:{“frequency”:868100000,“dr”:0},“adr”:false,“fCnt”:99,“fPort”:2,“data”:“UEtUICNj”}

  1. Why the RX2 datarate is not sent in the join accept message ? The specification defines that the join accept must contain the RX2 datarate.
  2. The RX2 configuration is sent in a separate message. This is problematic as the node might not receive the message. Does the node need to send an ack ?
  3. Another issue is that although in the SRV_MAC_RX_PARAM_SETUP_REQ you send the RX2 parameters in the json object (see above) the parameters are never changed.
2

I’m not sure what the relation is between your question and:

{“applicationID”:“6”,“applicationName”:“multicast_app”,“deviceName”:“device_a”,“devEUI”:“240ac4fffe0bf994”,“txInfo”:{“frequency”:868100000,“dr”:0},“adr”:false,“fCnt”:99,“fPort”:2,“data”:“UEtUICNj”}

This is an uplink application payload and has nothing to do with the RX2 receive-window (re)configuration.

The re-configuration might be caused by other settings that can’t be communicated to the device as part of the join-accept message.

The answer to question 2 is, yes the device needs to ACK the mac-command and LoRa Server will repeat sending the command until it has received an ACK.

3

You are right, copy and paste the wrong message.

The issue is that unlike ttn, where the RX2 datarate is sent as part of the join accept message, in the loraserver the RX2 commands are sent as RXParamSetupReq.

I am seeing the MAC commands being parsed correctly on the node (the payload is correct i.e rx2 dr is 5) and the ack is sent upstream with the next data message. What i am not understanding is why the downstream json object from the loraserver still has SF12BW125 instead of SF7BW125.

Can you give me some indications here please ? With ABP everything is working as expected, the issue is with OTAA.

4

Well that depends if the downlink is using RX1 or RX2 :slight_smile:

5

Thanks brocarr :slight_smile:

6

I’ve just released LoRa Server v2.6.1, I advice you to test this version as it might relate to your issue :slight_smile: After the last refactor which cleaned up a lot of code, a regression was introduced which caused the uplink configuration function not to be triggered.