Arduino nano and RFM95 basic test - EV_JOIN_TXCOMPLETE: no JoinAccept

I misunderstood what I should do. I will correct this late night back to ABP, but not now (I’m working). Thanks for explanation.

  • Switched back to ABP.
  • Updated all keys in the sketch.
  • Sent downlink message from TTN.

Packet queued
131964: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
4013602: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
7895244: EV_TXCOMPLETE (includes waiting for RX windows)


Firstly I did suggest testing ABP 23 days ago, I cant believe you’ve only just tested it given the length of this thread :slight_smile:

“Status - unseen” , your ABP uplinks are not being received according to the console image you just posted, downlinks will never work until uplink functionality is working.

Something else is wrong, your device logs looks clean (which is good, device hardware is prob working ok) - I’d check the device setup re it being an ABP device, even a small typo and you wont see uplinks, there are dozens of threads here on basic fault finding

Yes, it’s a little bit long this debug. I’ve tried a lot of confings, waiting for 2 new boards, but the problem is somewhere else.

I’m just using standard ttn-abp scketch example, modified only keys. I posted before my full sketch, there were no errors. I’m not lazy to post current config:

ttn-abp sketch from example
 * 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.
 * 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] = { 0x3B, 0x7A, 0xDF, 0x93, 0x80, 0x35, 0xCB, 0x9A, I removed this part here };

// 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] = { 0xF4, 0xD8, 0x88, 0xD1, 0xDC, 0x14, 0x50, 0xE1, 0xAB, I removed this part here };

// LoRaWAN end-device address (DevAddr)
static const u4_t DEVADDR = 0x26011882 ; // <-- 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[] = "Hello, world!";
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 = 10,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 5,
    .dio = {2, 3, LMIC_UNUSED_PIN},

void onEvent (ev_t ev) {
    Serial.print(": ");
    switch(ev) {
        case EV_SCAN_TIMEOUT:
        case EV_BEACON_FOUND:
        case EV_BEACON_MISSED:
        case EV_BEACON_TRACKED:
        case EV_JOINING:
        case EV_JOINED:
        case EV_RFU1:
        case EV_JOIN_FAILED:
        case EV_REJOIN_FAILED:
        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(F(" bytes of payload"));
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
        case EV_LOST_TSYNC:
        case EV_RESET:
        case EV_RXCOMPLETE:
            // data received in ping slot
        case EV_LINK_DEAD:
        case EV_LINK_ALIVE:
            Serial.println(F("Unknown event"));

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() {

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

    // LMIC init
    // Reset the MAC state. Session and pending data transfers will be discarded.

    // 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);
    // If not running an AVR with PROGMEM, just use the arrays directly
    LMIC_setSession (0x1, DEVADDR, NWKSKEY, APPSKEY);

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

    // Disable link check validation

    // 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)

    // Start job

void loop() {


#ifndef _lmic_config_h_
#define _lmic_config_h_

// In the original LMIC code, these config values were defined on the
// gcc commandline. Since Arduino does not allow easily modifying the
// compiler commandline, use this file instead.

#define CFG_eu868 1
//#define CFG_us915 1
// This is the SX1272/SX1273 radio, which is also used on the HopeRF
// RFM92 boards.
//#define CFG_sx1272_radio 1
// This is the SX1276/SX1277/SX1278/SX1279 radio, which is also used on
// the HopeRF RFM95 boards.
#define CFG_sx1276_radio 1

// 16 μs per tick
// LMIC requires ticks to be 15.5μs - 100 μs long
#define OSTICKS_PER_SEC (1000000 / US_PER_OSTICK)

// Set this to 1 to enable some basic debug output (using printf) about
// RF settings used during transmission and reception. Set to 2 to
// enable more verbose output. Make sure that printf is actually
// configured (e.g. on AVR it is not by default), otherwise using it can
// cause crashing.

// Enable this to allow using printf() to print to the given serial port
// (or any other Print object). This can be easy for debugging. The
// current implementation only works on AVR, though.
//#define LMIC_PRINTF_TO Serial

// Any runtime assertion failures are printed to this serial port (or
// any other Print object). If this is unset, any failures just silently
// halt execution.
#define LMIC_FAILURE_TO Serial

// Uncomment this to disable all code related to joining
//#define DISABLE_JOIN
// Uncomment this to disable all code related to ping
//#define DISABLE_PING
// Uncomment this to disable all code related to beacon tracking.
// Requires ping to be disabled too

// Uncomment these to disable the corresponding MAC commands.
// Class A
//#define DISABLE_MCMD_DCAP_REQ // duty cycle cap
//#define DISABLE_MCMD_DN2P_SET // 2nd DN window param
//#define DISABLE_MCMD_SNCH_REQ // set new channel
// Class B
//#define DISABLE_MCMD_PING_SET // set ping freq, automatically disabled by DISABLE_PING
//#define DISABLE_MCMD_BCNI_ANS // next beacon start, automatical disabled by DISABLE_BEACON

// In LoRaWAN, a gateway applies I/Q inversion on TX, and nodes do the
// same on RX. This ensures that gateways can talk to nodes and vice
// versa, but gateways will not hear other gateways and nodes will not
// hear other nodes. By uncommenting this macro, this inversion is
// disabled and this node can hear other nodes. If two nodes both have
// this macro set, they can talk to each other (but they can no longer
// hear gateways). This should probably only be used when debugging
// and/or when talking to the radio directly (e.g. like in the "raw"
// example).

// This allows choosing between multiple included AES implementations.
// Make sure exactly one of these is uncommented.
// This selects the original AES implementation included LMIC. This
// implementation is optimized for speed on 32-bit processors using
// fairly big lookup tables, but it takes up big amounts of flash on the
// AVR architecture.
// This selects the AES implementation written by Ideetroon for their
// own LoRaWAN library. It also uses lookup tables, but smaller
// byte-oriented ones, making it use a lot less flash space (but it is
// also about twice as slow as the original).

#endif // _lmic_config_h_

If I did a mistake in the code above, can you show me where please?

I raised the debug level as suggested here. I’ve searched for this from beginning, to see more details.

More details in console:

455: engineUpdate, opmode=0x808
1489: TXMODE, freq=867900000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
65903: RXMODE_SINGLE, freq=867900000, SF=7, BW=125, CR=4/5, IH=0
128691: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
129888: EV_TXCOMPLETE (includes waiting for RX windows)
132356: engineUpdate, opmode=0x900
3882359: engineUpdate, opmode=0x908
3883419: TXMODE, freq=868100000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
3948345: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
4011133: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
4012201: EV_TXCOMPLETE (includes waiting for RX windows)
4014799: engineUpdate, opmode=0x900
7764803: engineUpdate, opmode=0x908
7765858: TXMODE, freq=868300000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
7830784: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0
7893572: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
7894768: EV_TXCOMPLETE (includes waiting for RX windows)
7897367: engineUpdate, opmode=0x900
11647370: engineUpdate, opmode=0x908
11648426: TXMODE, freq=868500000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
11713223: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
11776011: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
11777206: EV_TXCOMPLETE (includes waiting for RX windows)
11779936: engineUpdate, opmode=0x900

I’m quite sure LMIC (certainly the old one you’re using) wants LSB for OTAA, so maybe for ABP as well?

Why maybe? How about this for ABP? We are now testing ABP example.

// LoRaWAN NwkSKey, network session key
// This should be in big-endian (aka msb).
static const PROGMEM u1_t NWKSKEY[16] = { FILLMEIN };

// LoRaWAN AppSKey, application session key
// This should also be in big-endian (aka msb).
static const u1_t PROGMEM APPSKEY[16] = { FILLMEIN };

Correct but it’s author also states:

Only when you have very tight constraints on RAM or flash should this version still be considered.

Which fits memory constrained MCU’s like ATmega328.

ATmega328 actually is not a good choice for new LMIC-based developments, because of its limited amount of memory. But the ATmega328 boards like Pro Mini are cheap, easily accessible and are well known for their Arduino support, which is probably why many hobbyists still tend to use them when starting with LoRaWAN.


For sending “Hello world” and coverage test is good enough.
Sketch uses 22748 bytes (74%) of program storage space. Maximum is 30720 bytes.
Global variables use 961 bytes (46%) of dynamic memory, leaving 1087 bytes for local variables. Maximum is 2048 bytes.

But this is not an example from the library that you’re using in the code you showed, is it?

Anyway: I simply don’t know if your LMIC library uses MSB or LSB for ABP. (It surely used LSB for OTAA.) So unless the above is actually documented for the LMIC you’re using, maybe your LMIC expects LSB? Easily checked, I’d say?

Can we see a screen shot of an uplink - expand it out please so we can see the signal strength etc.

This looks normal as far as I recall from when I was debugging libraries a year back

Easily checked, with ABP reversed bytes to LSB. Nothing changed.

451: engineUpdate, opmode=0x808
1487: TXMODE, freq=868100000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
65901: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
128688: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
129886: EV_TXCOMPLETE (includes waiting for RX windows)
132352: engineUpdate, opmode=0x900

Switched back to MSB

Sure, but any more practical applications than “Hello World” will soon make you run into its memory limitations. This is exactly why ATmega328 is a poor choice for starters because once they have managed the very basics (e.g. ‘Hello World’) these people will soon run into the memory limitations.
Quickly running into memory limitations will frustrate and demotivate starters and distract them from their learning path of applying LoRaWAN.

You won’t see changes in the device’s logs. The device calculates a MIC using the secrets it knows, and then just transmits. But if one or more gateways receive it and forward it to TTN, then TTN cannot validate the MIC if the secrets in TTN do not match the secrets that the device uses, and will drop the message.

No, no it’s not!

It uses MSB.

It does, and it’s says so in the code.

// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8]={ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}

// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]={ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}

// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
// The key shown here is the semtech default key.
static const u1_t PROGMEM APPKEY[16] = { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}

But let’s get ABP working first, we haven’t shown that it even uplinks yet.

1 Like

Where to do that? On TTN side, my device, I see only simulate uplink, nothing to expand here.

Is this not like buying an entry level gaming machine - still much can be done and when you start hitting the boundaries, you look to upgrade.

The demotivation comes when starters think an Arduino ATmega328 is the be-all and end all - which is wrong thinking and if that is there normal thinking, they are lost before they start.

Most of the issues on this forum are people running before they can walk, no scientific process and not reading around the subject. This is very hard to fix.

Simulate an uplink? Can’t be done.

An uplink is your device sending a message out in to the ether, a gateway or more picks it up, relays the data to TTN, if the keys are OK, it sends it to your application console.

If uplinks aren’t working, downlinks (devices receiving) will never ever happen.

Easily checked indeed:

Format of Keys and ID’s for Arduino LMIC libraries [HowTo]

Above holds for both for Classic LMIC and MCCI LMIC.

I simply don’t know if your LMIC library uses MSB or LSB for ABP.

If the LMIC library used is different than Classic LMIC and MCCI LMIC then I would suggest to use and test with either of these libraries in the first place.

For information about naming see: Arduino LMIC library naming: Classic LMIC and MCCI LMIC [HowTo]