RAK7289CV2 | Cannot Change Downlink RX2 Data Rate

[cbusse1 (Chris)]

I have encountered an issue with my RAK7289CV2 gateway where the downlink data rate (RX2 DR) does not update as expected when changed from the default setting. This issue persists across different operational configurations and results in downlink messages being transmitted at the incorrect data rate.

Environment:

• Model: RAK7289CV2 (WisGate Edge Pro, 16-Channel)

• WisGateOS: v2.2.1 (WisGateOS_2.2.1_RAK)

• Region: EU868

• Frequency Plan: see screenshot default_frequency_plan_EU868.png

• Device Class: Class C (continuous listening)

• Intended Downlink DR: DR5 (attempted to set via the WisGate OS web interface), see screenshot: DR5_test_parameters.png

• Actual Downlink DR: DR0 (despite settings indicating otherwise), see screenshot from Gateway Packet Capture DR0_but_should_be_DR5.png

Configuration and Tests Performed:

• Frequency: Tested DR5 setting with different frequencies, e.g., 868.3 and 869.525.
• ADR: Tested with both enabled and disabled states.
• Message Types: Tested with both Confirmed and Unconfirmed messages.
• Downlink Message Initiation: Tested sending downlink messages via both MQTT and the WisGate OS web-interface’s downlink page.
• LoRaWAN Version: Teste different protocol versions including 1.0.2 Rev A, 1.0.2 Rev B, 1.0.3
• Frame-counter Validation: Tested with both enabled/disabled.

Observed Behavior:

• When the RX2 data rate is set to DR5 via the WisGate OS interface, the downlink messages continue to be sent at DR0. This has been confirmed by observing the gateway’s packet capture logs.
  • see screenshot from Gateway Packet Capture DR0_but_should_be_DR5.png
• The issue arises when changing the RX2 data rate from the default setting (DR0) to any other data rate (e.g., DR5). The gateway seems to ignore the updated setting and sends downlink messages at DR0 instead.
  • see DR5_test_parameters.png
• Apart from the fact that the message was sent with DR0 (instead of the intended DR5), the end device does not receive the message in this scenario.

Troubleshooting Steps Already Taken:

• Verified that changes to RX2 DR are saved correctly in the WisGate OS interface.
• Rebooted the gateway after applying changes to ensure they are in effect.

Potential Impact:

• This issue hinders the correct operation of Class C devices in the network, as they are unable to receive downlinks at the intended data rate, potentially impacting critical device functions.

I verified that my end-device in Class C configuration receives downlink messages normally when the “default settings” are used with “intended DR0”, see screenshots:

• DR0_settings.png
• test_with_default_DR0.png

I believe this might be a bug within the WisGate OS or the packet forwarder for the RAK7289CV2 gateway. I am reaching out to seek assistance in resolving this issue or to identify if a firmware update is required to address this anomaly.

Please find attached screenshots of the WisGate OS interface showing the RX2 data rate settings, along with packet capture logs demonstrating the downlink messages being sent at DR0 instead of the configured DR5.

I appreciate any guidance or insights on this issue.

DR5_test_parameters:

test_with_default_DR0:

default_frequency_plan_EU868:

DR0_but_should_be_DR5:

DR0_settings:

[cbusse1 (Chris)]

Hello everyone,

I found a solution for the issue described above.

Problem Summary: My end-device was not effectively handling the RXParamSetupReq from the gateway, which affected the RX2 Data Rate (DR) settings.

Solution:

• Key Understanding: It’s crucial for the end-device to send RXParamSetupAns in response to RXParamSetupReq from the gateway.
• Implementation:
  • I configured the end-device as a Class A device initially.
  • Ensured that it sends an uplink message right after a successful connection, which includes the RXParamSetupAns.
  • After sending the RXParamSetupAns, I switched the device to Class C mode. This enabled it to receive downlink messages at the newly configured RX2 DR setting. Note that it’s also possible to change the RX2 frequency.
• Additional Insight: Initially, I assumed that the changed RX2 settings communicated in the JoinAccept message would be sufficient. However, I discovered that the exchange of RXParamSetupReq and RXParamSetupAns is mandatory, otherwise the WisGate would fall back to send downlink using default RX2 settings (Data rate: DR0, Frequency: 869.525).

Notes from Online Resources:
The description for the MAC Command (RXParamSetupReq) in Semtech Learning notes:

For Class C devices, after the network server transmits the RXParamSetupReq MAC command, it will not send any more Class C downlinks until it receives the RXParamSetupAns response from the end device. It is therefore important that the end device responds with the RXParamSetupAns message in a Class A uplink as soon as possible .

I hope this information is helpful to others working with Device Class C configured devices and facing similar issues.

Best regards,
Chris