# Problem receiving confirmation from gateway

**URL:** <https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155>\
**Category:** LMIC\
**Tags:** end-devices\
**Created:** [July 31, 2023, 10:19am UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155 "2023-07-31T10:19:41Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![juanezete](https://www.thethingsnetwork.org/forum/letter_avatar_proxy/v4/letter/j/5fc32e/32.png) [@juanezete](https://www.thethingsnetwork.org/forum/u/juanezete)\
**Post date:** [July 31, 2023, 10:19am UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155/1 "2023-07-31T10:19:41Z")

</div>

Hi everyone, I’m having some trouble receiving donwlink to my node after processing the gateway, I don’t know if something is wrong in my code:

```auto
/ *******************************************************************************
 * Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
 *
 * Permission is hereby granted, free of charge, to anyone
 * obtaining a copy of this document and accompanying files,
 * to do whatever they want with them without any restriction,
 * including, but not limited to, copying, modification and redistribution.
 * NO WARRANTY OF ANY KIND IS PROVIDED.
 *
 * This example sends a valid LoRaWAN packet with payload "Hello,
 * world!", using frequency and encryption settings matching those of
 * the The Things Network.
 *
 * This uses ABP (Activation-by-personalisation), where a DevAddr and
 * Session keys are preconfigured (unlike OTAA, where a DevEUI and
 * application key is configured, while the DevAddr and session keys are
 * assigned/generated in the over-the-air-activation procedure).
 *
 * Note: LoRaWAN per sub-band duty-cycle limitation is enforced (1% in
 * g1, 0.1% in g2), but not the TTN fair usage policy (which is probably
 * violated by this sketch when left running for longer)!
 *
 * To use this sketch, first register your application and device with
 * the things network, to set or generate a DevAddr, NwkSKey and
 * AppSKey. Each device should have their own unique values for these
 * fields.
 *
 * Do not forget to define the radio type correctly in config.h.
 *
 ******************************************************************************* /

#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>

// LoRaWAN NwkSKey, network session key
// This is the default Semtech key, which is used by the early prototype TTN
// network.
static const PROGMEM u1_t NWKSKEY[16] = { 0x **, 0x** , 0x **, 0x** , 0x **, 0x** , 0x90, 0xFF, 0x3F, 0x03, 0xB4, 0x4E, 0x **, 0x** , 0x **, 0x** };

// LoRaWAN AppSKey, application session key
// This is the default Semtech key, which is used by the early prototype TTN
// network.
static const u1_t PROGMEM APPSKEY[16] ={ 0x **, 0x** , 0x **, 0x** , 0x **, 0x** , 0x90, 0xFF, 0x3F, 0x03, 0xB4, 0x4E, 0x **, 0x** , 0x **, 0x** };;

// LoRaWAN end-device address (DevAddr)
static const u4_t DEVADDR = 0x ******* ; // <-- Change this address for every node!

// These callbacks are only used in over-the-air activation, so they are
// left empty here (we cannot leave them out completely unless
// DISABLE_JOIN is set in config.h, otherwise the linker will complain).
void os_getArtEui(u1_t* buf) {}
void os_getDevEui(u1_t* buf) {}
void os_getDevKey(u1_t* buf) {}

static uint8_t mydata[] = "Hola Alcala, esto parece q funciona!";
static osjob_t sendjob;

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 60;

// Pin mapping
const lmic_pinmap lmic_pins = {
  .nss = 15,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 16,
  .dio = {2,4,LMIC_UNUSED_PIN},
};

void onEvent(ev_t ev) {
  Serial.print(os_getTime());
  Serial.print(": ");
  switch (ev) {
    case EV_SCAN_TIMEOUT:
      Serial.println(F("EV_SCAN_TIMEOUT"));
      break;
    case EV_BEACON_FOUND:
      Serial.println(F("EV_BEACON_FOUND"));
      break;
    case EV_BEACON_MISSED:
      Serial.println(F("EV_BEACON_MISSED"));
      break;
    case EV_BEACON_TRACKED:
      Serial.println(F("EV_BEACON_TRACKED"));
      break;
    case EV_JOINING:
      Serial.println(F("EV_JOINING"));
      break;
    case EV_JOINED:
      Serial.println(F("EV_JOINED"));
      break;
    case EV_RFU1:
      Serial.println(F("EV_RFU1"));
      break;
    case EV_JOIN_FAILED:
      Serial.println(F("EV_JOIN_FAILED"));
      break;
    case EV_REJOIN_FAILED:
      Serial.println(F("EV_REJOIN_FAILED"));
      break;
    case EV_TXCOMPLETE:
      Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
      if (LMIC.txrxFlags & TXRX_ACK)
        Serial.println(F("Received ack"));
      if (LMIC.dataLen) {
        Serial.println(F("Received "));
        Serial.println(LMIC.dataLen);
        Serial.println(F(" bytes of payload"));
      }
      // Schedule next transmission
      os_setTimedCallback(&sendjob, os_getTime() + sec2osticks(TX_INTERVAL), do_send);
      break;
    case EV_LOST_TSYNC:
      Serial.println(F("EV_LOST_TSYNC"));
      break;
    case EV_RESET:
      Serial.println(F("EV_RESET"));
      break;
    case EV_RXCOMPLETE:
      // data received in ping slot
      Serial.println(F("EV_RXCOMPLETE"));
      break;
    case EV_LINK_DEAD:
      Serial.println(F("EV_LINK_DEAD"));
      break;
    case EV_LINK_ALIVE:
      Serial.println(F("EV_LINK_ALIVE"));
      break;
    default:
      Serial.println(F("Unknown event"));
      break;
  }
}

void do_send(osjob_t* j) {
  // Check if there is not a current TX/RX job running
  if (LMIC.opmode & OP_TXRXPEND) {
    Serial.println(F("OP_TXRXPEND, not sending"));
  } else {
    // Prepare upstream data transmission at the next possible time.
    LMIC_setTxData2(1, mydata, sizeof(mydata) - 1, 0);
    Serial.println(F("Packet queued"));
  }
  // Next TX is scheduled after TX_COMPLETE event.
}

void setup() {
  Serial.begin(115200);
  Serial.println(F("Starting"));

#ifdef VCC_ENABLE
  // For Pinoccio Scout boards
  pinMode(VCC_ENABLE, OUTPUT);
  digitalWrite(VCC_ENABLE, HIGH);
  delay(1000);
#endif

  // LMIC init
  os_init();
  // Reset the MAC state. Session and pending data transfers will be discarded.
  LMIC_reset();

// Set static session parameters. Instead of dynamically establishing a session
// by joining the network, precomputed session parameters are be provided.
#ifdef PROGMEM
  // On AVR, these values are stored in flash and only copied to RAM
  // once. Copy them to a temporary buffer here, LMIC_setSession will
  // copy them into a buffer of its own again.
  uint8_t appskey[sizeof(APPSKEY)];
  uint8_t nwkskey[sizeof(NWKSKEY)];
  memcpy_P(appskey, APPSKEY, sizeof(APPSKEY));
  memcpy_P(nwkskey, NWKSKEY, sizeof(NWKSKEY));
  LMIC_setSession(0x1, DEVADDR, nwkskey, appskey);
#else
  // If not running an AVR with PROGMEM, just use the arrays directly
  LMIC_setSession(0x1, DEVADDR, NWKSKEY, APPSKEY);
#endif

#if defined(CFG_eu868)
  // Set up the channels used by the Things Network, which corresponds
  // to the defaults of most gateways. Without this, only three base
  // channels from the LoRaWAN specification are used, which certainly
  // works, so it is good for debugging, but can overload those
  // frequencies, so be sure to configure the full frequency range of
  // your network here (unless your network autoconfigures them).
  // Setting up channels should happen after LMIC_setSession, as that
  // configures the minimal channel set.
  // NA-US channels 0-71 are configured automatically
  LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI); // g-band
  LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
  LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI); // g2-band
// TTN defines an additional channel at 869.525Mhz using SF9 for class B
// devices' ping slots. LMIC does not have an easy way to define set this
// frequency and support for class B is spotty and untested, so this
// frequency is not configured here.
#elif defined(CFG_us915)
  // NA-US channels 0-71 are configured automatically
  // but only one group of 8 should (a subband) should be active
  // TTN recommends the second sub band, 1 in a zero based count.
  // https://github.com/TheThingsNetwork/gateway-conf/blob/master/US-global_conf.json
  LMIC_selectSubBand(1);
#endif

  // Disable link check validation
  LMIC_setLinkCheckMode(0);

  // TTN uses SF9 for its RX2 window.
  LMIC.dn2Dr = DR_SF9;

  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF7, 14);

  // Start job
  do_send(&sendjob);
}

void loop() {
  os_runloop_once();
}

```

The thing is that, the message sent is correctly received by the gateway and a message confirmation is sent, but it is not received by the node. Moreover, I’ve tried to set DIO2 but always gives me compilation error, no matter where I place the physical connection.

---

<div class="post-metadata">

**Author:** ![Piet\_Pillay](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/piet_pillay/32/35697_2.png) [@Piet\_Pillay](https://www.thethingsnetwork.org/forum/u/Piet_Pillay)\
**Post date:** [July 31, 2023, 2:13pm UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155/2 "2023-07-31T14:13:40Z")

</div>

do you have your own gateway?

what do you see in the console?

what is the rssi?

---

<div class="post-metadata">

**Author:** ![juanezete](https://www.thethingsnetwork.org/forum/letter_avatar_proxy/v4/letter/j/5fc32e/32.png) [@juanezete](https://www.thethingsnetwork.org/forum/u/juanezete)\
**Post date:** [August 1, 2023, 8:26am UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155/3 "2023-08-01T08:26:55Z")

</div>

> [@Piet\_Pillay](#):
>
> do you have your own gateway?
> 
> what do you see in the console?
> 
> what is the rssi?

Yes, I have my own one.

 ![image](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/2/9/29cfff5a9d15e217a169dec3d22d64e3a4243e54.png)

It is continuously receiving data but not sending a downlink to the Node

Pd: I’ve followed this tutorial to set up the gateway [Tutorial](https://www.thethingsindustries.com/docs/gateways/models/raspberry-pi/)

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [August 1, 2023, 10:13am UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155/4 "2023-08-01T10:13:00Z")

</div>

You are in breach of the TTN Fair Use Policy with the send rate you have - please correct this.

Why are you expecting a confirmation from the gateway?

Why do you want a confirmation?

The FUP allows up to ten downlinks / confirmations per day. The community encourages one a fortnight due to the impact on the network.

Sending text, even for test purposes, is inefficient and even for test purposes, clutters the airwaves. If need a test payload, then three bytes or less are best.

---

<div class="post-metadata">

**Author:** ![juanezete](https://www.thethingsnetwork.org/forum/letter_avatar_proxy/v4/letter/j/5fc32e/32.png) [@juanezete](https://www.thethingsnetwork.org/forum/u/juanezete)\
**Post date:** [August 1, 2023, 10:17am UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155/5 "2023-08-01T10:17:25Z")

</div>

> [@descartes](#):
>
> You are in breach of the TTN Fair Use Policy with the send rate you have - please correct this.
> 
> Why are you expecting a confirmation from the gateway?
> 
> Why do you want a confirmation?
> 
> The FUP allows up to ten downlinks / confirmations per day. The community encourages one a fortnight due to the impact on the network.
> 
> Sending text, even for test purposes, is inefficient and even for test purposes, clutters the airwaves. If need a test payload, then three bytes or less are best.

Understood, I haven’t taken it into account when conducting tests. I’ll fix it and migrate my system to OTA (Over-The-Air) to avoid confirmations and I will set a longer send rate in order to obey the Fair Use Policy. Thank you and sorry for any inconvenience caused to the network, I’m new at this.

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [August 1, 2023, 12:00pm UTC](https://www.thethingsnetwork.org/forum/t/problem-receiving-confirmation-from-gateway/64155/6 "2023-08-01T12:00:14Z")

</div>

> [@juanezete](#):
>
> OTA (Over-The-Air) to avoid confirmations

OTAA has nothing to do with confirmations - nor does ABP - but OTAA has many benefits.

LoRaWAN doesn’t routinely acknowledge an uplink - you will have seen the uplink in the gateway console - that would have just been a record of an incoming uplink.

You may benefit considerably from spending an evening reading this: [https://www.thethingsnetwork.org/docs/lorawan/](https://www.thethingsnetwork.org/docs/lorawan/) - most importantly the fundamentals section.