MKR WAN 1310 "No downlink message received at this time"

Hi, I have an MKR WAN 1310 Board with GSM Antenna (850 Mhhz-1900Mhz) running on v1 MKRWAN firmware and Module Version is ARD-078 1.2.3. I have set up my Gateway TTIG that supports AS923Mhhz for Asia. LoRaWAN Specification 1.0.3 is used. Regional Parameters version is RP001 Regional Parameters 1.0.3 revision A.

I use LoraSendAndReceive, and I have no problems with Uplink.

However, I can never get Downlink messages to work as I always receive “No downlink message received at this time” after an Uplink message is sent.

I have gone through the WiKi and a number of posts in the forum but even after tinkering with my Rx1 Delay or such, I am still unable to receive it.

End Device Config


Simulating a Downlink
I use TTN Messaging console to send a Downlink message.

**Gateway General Settings > Basic Settings

Gateway General Settings > LoRaWAN Options


#include <MKRWAN.h>

LoRaModem modem;

// Uncomment if using the Murata chip as a module
// LoRaModem modem(Serial1);

#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;

void setup() {
  while (!Serial);
  if (!modem.begin(AS923)) {
    Serial.println("Failed to start module");
    while (1) {}
  Serial.print("Your module version is: ");
  Serial.print("Your device EUI is: ");

  int connected = modem.joinOTAA(appEui, appKey);
  if (!connected) {
    Serial.println("Something went wrong; are you indoor? Move near a window and retry");
    while (1) {}

  // Set poll interval to 60 secs.
  // modem.minPollInterval(60);
  // NOTE: independent of this setting, the modem will
  // not allow sending more than one message every 2 minutes,
  // this is enforced by firmware and can not be changed.

void loop() {
  Serial.println("Enter a message to send to network");
  Serial.println("(make sure that end-of-line 'NL' is enabled)");

  while (!Serial.available());
  String msg = Serial.readStringUntil('\n');

  Serial.print("Sending: " + msg + " - ");
  for (unsigned int i = 0; i < msg.length(); i++) {
    Serial.print(msg[i] >> 4, HEX);
    Serial.print(msg[i] & 0xF, HEX);
    Serial.print(" ");

  int err;
  err = modem.endPacket(true);
  if (err > 0) {
    Serial.println("Message sent correctly!");
  } else {
    Serial.println("Error sending message :(");
    Serial.println("(you may send a limited amount of messages per minute, depending on the signal strength");
    Serial.println("it may vary from 1 message every couple of seconds to 1 message every minute)");
  if (!modem.available()) {
    Serial.println("No downlink message received at this time.");
  char rcv[64];
  int i = 0;
  while (modem.available()) {
    Serial.print("try to receive this... ");
    rcv[i++] = (char);
  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(" ");

After scheduling a downlink, I see this in my End Device Live Data Console.

Then I send an Uplink message from the Board and I see this.

This is what is shown in the Gateway Live Data Console.

Can anyone help point out what I should focus on to get it to work?

Are you using the same fport for the downlink as what your node is expecting to see a message on?

Massive breach of Fair Use Policy - duty cycle & use of confirmed up & downlinks - unlisting thread until the OP has read it and adjusted the code accordingly.

Also try to avoid using confirmed downlinks (I see you have this ticked) - in some situations this can cause a spaghetti mess of unanswred/unanswerable messages that stuff queues on device, GW’s and the LNS…in fact wrt confirmed ‘anything’ rather than avoid, make default position ‘dont do it’ (for reasons - forum search).

Also your uplink rate (and associated downlink rate!) is frankly taking the p1$$ of the TTN FUP.…please go away and research the applicable limits and use cases then come back and let us know you understand and have adapted your code/use accordingly then perhaps the forum volunteers can step in and assit with debug of a reasonable configuration…until then I would ask they stay quite on this matter :wink:

1 Like