No downlinks when using SF>8 and ABP

[MITEL-UNIUD]

When joining with ABP and using low data rates (SF9-SF12), downlinks do not function; at SF7-SF8 they do. If joining with OTAA downlinks function at any data rate. This using TTN. The difference is that at SF7-8 downlinks are sent at the same frequency and SF as the uplink, while at SF9-SF12 TTN is using 869.525 at SF9.
The following script (derived from the LoraSendAndReceive example) can reproduce the issue, just change the first defines to switch from ABP to OTAA and to change SF:

#include <MKRWAN.h>

#define ABP
//#define OTAA 
#define DR 0  //0=SF12, 5=SF7

LoRaModem modem;
byte counter=0;

#include "arduino_secrets.h"
// Please enter your sensitive data in the Secret tab or arduino_secrets.h
String appEui = SECRET_APP_EUI;
String appKey = SECRET_APP_KEY;

String devAddr = DEVADDR;
String nwkSKey = NWSKEY;
String appSKey = APPSKEY;

void setup() {
  Serial.begin(115200);
  while (!Serial);
  // change this to your regional band (eg. US915, AS923, ...)
  if (!modem.begin(EU868)) {
    Serial.println("Failed to start module");
    while (1) {}
  };
  Serial.print("Your module version is: "); Serial.println(modem.version());
  Serial.print("Your device EUI is: "); Serial.println(modem.deviceEUI());

  #ifdef OTAA
  int connected = modem.joinOTAA(appEui, appKey);
  #else
   int connected = modem.joinABP(devAddr, nwkSKey, appSKey);
 #endif
  if (!connected) {
    Serial.println("Something went wrong; are you indoor? Move near a window and retry");
    while (1) {}
  }
  modem.minPollInterval(60);
  modem.dataRate(DR);

}

void loop() { 
  Serial.println(counter);
  int err;
  modem.beginPacket();
  modem.write(counter);
  err = modem.endPacket(false);
  counter++;
  if (err > 0) {
    Serial.println("Message sent correctly!");
  } else {
    Serial.println("Error sending message :(");
  }
  delay(1000);
  if (!modem.available()) {
    Serial.println("No downlink message received at this time.");
  }
  else {
  char rcv[64];
  int i = 0;
  while (modem.available()) {
    rcv[i++] = (char)modem.read();
  }
  Serial.print("Received: ");
  for (unsigned int j = 0; j < i; j++) {
    Serial.print(rcv[j] >> 4, HEX);
    Serial.print(rcv[j] & 0xF, HEX);
    Serial.print(" ");
  }
  Serial.println();
  }
  delay(60000);
}

[facchinm]

Hi @MITEL-UNIUD ,
I just tested your sketch with ABP and DR0 (SF 12) and messages are correctly sent (I can see them in the TTN backend).
Can you check if you are running the latest firmware version? In case it's not 1.1.9, please update it using MKRWANFWUpdate_standalone sketch.

[MITEL-UNIUD]

I have 1.1.9; and the gateway is a Lorix One, not far but not even too close. I tested many times, however always with the same device. Not sure why, at this point.

[MITEL-UNIUD]

Ok, I spent some time studying the issue. I added two methods to the MKRWAN.h library to get RX2 data rate and frequency (+RX2FQ and +RX2DR).
In OTAA SF 12, this is what I see:
RX2 DR: 3; RX2 Freq: 869525000

In ABP SF12, this is what I see:
RX2 DR: 0; RX2 Freq: 869525000
The frequency is right but the data rate is wrong.

So I also added a setRX2DR method, which solved my issue. However, I do not know why you are receiving downlinks in the same situation. I mean downlinks: by reading again your post, you see packets sent on TTN... uplinks?
By looking in the lora.c file at line 659, frequency and data rate values are correctly set, but inside a conditional directive (USE_SEMTECH_DEFAULT_CHANNEL_LINEUP == 1) that is not executed because of line 83.

This is the code I added in MKRWAN.h (so yes, I am not in the right place, but likely the base issue is in firmware and this only a workaround). A call to modem.setRX2DR(3) made downlinks being received.
And thanks :)

  int getRX2DR() {
    int dr = -1;
    sendAT(GF("+RX2DR?"));
    if (waitResponse("+OK=") == 1) {
        dr = stream.readStringUntil('\r').toInt();
    }
    return dr;
  }

  int getRX2Freq() {
    int freq = -1;
    sendAT(GF("+RX2FQ?"));
    if (waitResponse("+OK=") == 1) {
        freq = stream.readStringUntil('\r').toInt();
    }
    return freq;
  }

  bool setRX2DR(uint8_t dr) {
    sendAT(GF("+RX2DR="),dr);
    if (waitResponse() != 1) {
      return false;
    }
    return true;
  }

[facchinm]

Sorry, I totally missed the downlink part, my fault. It looks better to fix it in the firmware, would you mind filing a PR to target the issue? Thanks you very much!

[MITEL-UNIUD]

If I have to modify code in the firmware, I do not feel sufficiently confident for doing it (not sure about domino effects).
However, after looking more in detail at the firmware, likely the issue could be here:

mkrwan1300-fw/Middlewares/Third_Party/Lora/Mac/region/RegionEU868.h

Line 185 in 188a5cd

#define EU868_RX_WND_2_DR DR_0

If you need it, I could file a PR on this (but again I am not totally sure).
SF12 was an initial TTN choice, as far as I understood, then they changed mind.

[MITEL-UNIUD]

On a second thought, I checked the official regional parameters specifications, and it seems TTN does not follow the standard, which is indeed correctly implemented in firmware (SF12, 869.525). From this point of view, perhaps is better to expose methods to set DR (and for symmetry, frequency) for RX2 directly from the library. This is done also by LMIC, for example, and allows to comply with any network. On this I can help.

[facchinm]

From this point of view, perhaps is better to expose methods to set DR (and for symmetry, frequency)

Sounds good, I'd love to keep the library API slim (since running the stack on the module should automate most of the "boring" stuff) but in this case it's probably a good idea to expose these functionalities that are already there (and properly document them).

Wound you mind opening a PR on the library repo? Thanks a lot!

[MITEL-UNIUD]

Ok, actually I have created four methods just for completeness (get and set DR and freq), but the only one really needed is setRX2DR: what do you prefer in the PR?

[facchinm]

All of them, just for completeness 🙂