LoRa Wio E5 ADR Not Working for Join Attempts

Products & Technology LoRa
1

I’m working with the LoRa Wio E5 module, using this repository Seeed-LoRa-E5 by danak6jq

I’ve encountered an issue where ADR works perfectly for normal data transmission after joining the network, but it seems to have no effect during the join process.

  • The join attempts always use the data rate (DR) set by the macro LORAWAN_DEFAULT_DATA_RATE in the file LoRaWAN/App/lora_app.h
  • From my understanding, if ADR is enabled (LORAWAN_ADR_STATE set to LORAMAC_HANDLER_ADR_ON), this macro shouldn’t even be used, yet the join process seems to ignore ADR and always sticks to the default DR.

Additionally, I noticed that to reflect changes made to the LORAWAN_ADR_STATE macro in lora_app.h, I had to manually modify the AdrEnable member inside the LmhpComplianceParams_t structure, which is located in:

Middlewares/Third_Party/LoRaWAN/LmHandler/LmHandler.c

static LmhpComplianceParams_t LmhpComplianceParams =
{
.AdrEnabled = LORAMAC_HANDLER_ADR_ON, // Had to change this manually
.DutyCycleEnabled = true,
.StopPeripherals = NULL,
.StartPeripherals = NULL,
};

This makes me wonder if the ADR state set in lora_app.h isn’t being propagated correctly.

Is there a way to make ADR control the data rate during the join process as well, or is the join process intentionally fixed at the default DR? Any guidance would be greatly appreciated!

Thanks in advance.

2

Hi there,

So I have seen this asked before, the answer was NO.
No, ADR (Adaptive Data Rate) is not used during the join process itself. ADR only takes effect after the join process is successful, and the device has received network settings from the server.

AI say’s why,

The LoRaWAN join process (also known as OTAA - Over-The-Air Activation) is intentionally designed to use a fixed data rate during the join process. This is for compatibility and reliability reasons.

:mag: Why is the Join Process Fixed at a Default Data Rate?

  1. Reliability: Using a lower data rate (usually DR0 - SF12 in most regions) increases the range and robustness of the join request. This is particularly important because the device has not established a connection yet and needs the best chance of reaching the network server.
  2. Compatibility: Not all devices support Adaptive Data Rate (ADR) by default. The server cannot instruct a device to change its data rate until a session is established.
  3. Standardization: The LoRaWAN specification (v1.0.3 and v1.1) states that the join request is sent with a specific spreading factor and bandwidth as defined by regional parameters.

:rocket: What Can Be Done Instead?

  1. Manually Set Data Rate:
    * If you have control over the device, you can configure the data rate used for the join process.
  • For instance, using radio.setSpreadingFactor() or radio.setDataRate() before calling begin() if using RadioLib.
  • Example:
radio.setSpreadingFactor(10);  // Example: SF10
radio.setBandwidth(125.0);
radio.setCodingRate(5);
  1. Join Request Retries:
  • Devices are usually designed to retry the join request with a different data rate if the first attempt fails.
  • This retry mechanism is built into most LoRaWAN stacks.
  1. Switching to ABP (Activation By Personalization):
  • If ADR needs to be controlled from the start, using ABP instead of OTAA allows setting the data rate manually from the beginning.

HTH
GL :slight_smile: PJ :v: