RAK7243C gateway not connecting with whisper node LoRa in ABP mode

Hi All I am using RAK7243C in AS-1 region which is successfully able to connect with The Things Network (TTN) cloud. However it’s not showing any live data coming from my Node. Can someone please help, below are the details:

I made an application with information as in the picture below in TTN:

db7a2f42d78a47550d35d686cd055566f9a74c46

Now, I am using whisper Node LoRa (Atmega328 + RFM95) to publish LoRa data. The library I am using is MCCI_LoRaWAN_LMIC_library-4.1.1. I had made an Arduino program as pasted below with its serial output mentioned after it:

Arduino Program:


/*******************************************************************************
 * Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
 * Copyright (c) 2018 Terry Moore, MCCI
 *
 * 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
 * arduino-lmic/project_config/lmic_project_config.h or from your BOARDS.txt.
 *
 *******************************************************************************/

 // References:
 // [feather] adafruit-feather-m0-radio-with-lora-module.pdf

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

//
// For normal use, we require that you edit the sketch to replace FILLMEIN
// with values assigned by the TTN console. However, for regression tests,
// we want to be able to compile these scripts. The regression tests define
// COMPILE_REGRESSION_TEST, and in that case we define FILLMEIN to a non-
// working but innocuous value.
//
#ifdef COMPILE_REGRESSION_TEST
# define FILLMEIN 0
#else
# warning "You must replace the values marked FILLMEIN with real values from the TTN control panel!"
# define FILLMEIN (#dont edit this, edit the lines that use FILLMEIN)
#endif

// LoRaWAN NwkSKey, network session key
// This should be in big-endian (aka msb).
static const PROGMEM u1_t NWKSKEY[16] = {0xAF,0x2C,0xA5,0x74,0x91,0x9B,0x4C,0x52,0x89,0xE0,0xF3,0x7E,0x98,0x61,0x6D,0x47};

// LoRaWAN AppSKey, application session key
// This should also be in big-endian (aka msb).
static const u1_t PROGMEM APPSKEY[16] = {0xCF,0x7E,0x36,0x31,0x97,0x16,0x8A,0x54,0x7F,0xC2,0xA9,0xF2,0xEC,0x72,0x36,0xC9};

// LoRaWAN end-device address (DevAddr)
// See http://thethingsnetwork.org/wiki/AddressSpace
// The library converts the address to network byte order as needed, so this should be in big-endian (aka msb) too.
static const u4_t DEVADDR = 0x260DAE15 ; // <-- 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 arduino-lmic/project_config/lmic_project_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[] = "a";
static osjob_t sendjob;

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

// Pin mapping
// Adapted for Feather M0 per p.10 of [feather]
const lmic_pinmap lmic_pins = {
    .nss = 10,                       // chip select on feather (rf95module) CS
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 7,                       // reset pin
    .dio = {2, A2, A3}, // assumes external jumpers [feather_lora_jumper]
                                    // DIO1 is on JP1-1: is io1 - we connect to GPO6
                                    // DIO1 is on JP5-3: is D2 - we connect to GPO5
};

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;
        /*
        || This event is defined but not used in the code. No
        || point in wasting codespace on it.
        ||
        || 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;
        /*
        || This event is defined but not used in the code. No
        || point in wasting codespace on it.
        ||
        || case EV_SCAN_FOUND:
        ||    Serial.println(F("EV_SCAN_FOUND"));
        ||    break;
        */
        case EV_TXSTART:
            Serial.println(F("EV_TXSTART"));
            break;
        case EV_TXCANCELED:
            Serial.println(F("EV_TXCANCELED"));
            break;
        case EV_RXSTART:
            /* do not print anything -- it wrecks timing */
            break;
        case EV_JOIN_TXCOMPLETE:
            Serial.println(F("EV_JOIN_TXCOMPLETE: no JoinAccept"));
            break;
        default:
            Serial.print(F("Unknown event: "));
            Serial.println((unsigned) ev);
            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() {
//    pinMode(13, OUTPUT);
    while (!Serial); // wait for Serial to be initialized
    Serial.begin(115200);
    delay(100);     // per sample code on RF_95 test
    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 (0x13, DEVADDR, nwkskey, appskey);
    #else
    // If not running an AVR with PROGMEM, just use the arrays directly
    LMIC_setSession (0x13, 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. The LMIC doesn't let you change
    // the three basic settings, but we show them here.
    LMIC_setupChannel(0, 923200000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(1, 923400000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
    LMIC_setupChannel(2, 922200000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(3, 922400000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(4, 922600000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(5, 922800000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(6, 923000000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(7, 922000000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(8, 922100000, 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) || defined(CFG_au915)
    // NA-US and AU 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);
    #elif defined(CFG_as923)
    // Set up the channels used in your country. Only two are defined by default,
    // and they cannot be changed.  Use BAND_CENTI to indicate 1% duty cycle.
    // LMIC_setupChannel(0, 923200000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);
    // LMIC_setupChannel(1, 923400000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);

    // ... extra definitions for channels 2..n here
    #elif defined(CFG_kr920)
    // Set up the channels used in your country. Three are defined by default,
    // and they cannot be changed. Duty cycle doesn't matter, but is conventionally
    // BAND_MILLI.
    // LMIC_setupChannel(0, 922100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(1, 922300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(2, 922500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);

    // ... extra definitions for channels 3..n here.
    #elif defined(CFG_in866)
    // Set up the channels used in your country. Three are defined by default,
    // and they cannot be changed. Duty cycle doesn't matter, but is conventionally
    // BAND_MILLI.
    // LMIC_setupChannel(0, 865062500, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(1, 865402500, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);
    // LMIC_setupChannel(2, 865985000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_MILLI);

    // ... extra definitions for channels 3..n here.
    #else
    # error Region not supported
    #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
    LMIC_setDrTxpow(DR_SF7,14);

    // Start job
    do_send(&sendjob);
}

void loop() {
    unsigned long now;
    now = millis();
    if ((now & 512) != 0) {
      digitalWrite(13, HIGH);
    }
    else {
      digitalWrite(13, LOW);
    }

    os_runloop_once();

}

Serial output:

Starting
8515: EV_TXSTART
Packet queued
139219: EV_TXCOMPLETE (includes waiting for RX windows)
452198: EV_TXSTART
Packet queued
582908: EV_TXCOMPLETE (includes waiting for RX windows)
895888: EV_TXSTART
Packet queued
1026597: EV_TXCOMPLETE (includes waiting for RX windows)
1339665: EV_TXSTART
Packet queued
1470378: EV_TXCOMPLETE (includes waiting for RX windows)
1783360: EV_TXSTART
Packet queued
1914073: EV_TXCOMPLETE (includes waiting for RX windows)
2227058: EV_TXSTART
Packet queued
2357773: EV_TXCOMPLETE (includes waiting for RX windows)
2670755: EV_TXSTART
Packet queued
2801468: EV_TXCOMPLETE (includes waiting for RX windows)
3114532: EV_TXSTART
Packet queued
3245245: EV_TXCOMPLETE (includes waiting for RX windows)
3558228: EV_TXSTART

In case someone know how to resolve the issue, then please advise.

Thank you.

PS: Since, RAK7243C supports * Full LoRaWAN Stack support (version 1.0.2), I have made few changes as recommended in MCCI_LoRaWAN_LMIC_library-4.1.1’ libraries readme.:

Selecting V1.0.2

In project_config/lmic_project_config.h, add:

#define LMIC_LORAWAN_SPEC_VERSION   LMIC_LORAWAN_SPEC_VERSION_1_0_2

On your compiler command line, add:

-D LMIC_LORAWAN_SPEC_VERSION=LMIC_LORAWAN_SPEC_VERSION_1_0_2

read fup

then what do you see in your application and gateway console

i want to take a bet here your node is with in 5m off the gateway

It doesn’t, it has no clue what the waggling electomagnetic waves do, it just knows they waggle correctly, the CRC checks out and passes it to the LNS.

1.0.3 is pretty much the bare minimum to use.

But as suggested above, this conversation can’t carry on until you’ve confirmed you are working to the community Fair Use Policy. Which means you must explicitly state you have fixed it please.

I refered this link where it’s written it has Full LoRaWAN Stack support (version 1.0.2) support, that’s why i made changes in library, am sorry if I am interpreting something wrong. I still need help I am unable to get data no matter how long interval I keep the loRa interval, Please advise.

image

The node and gateway both are on my table and I am doing testing.I am not deploying it anywhere. I had kept the ftime duration low so that testing can be fast, anyway I changed it to a minute but still nothing received at the gateway, please advise.

what is the air time of your uplink

calculate it per day

https://avbentem.github.io/airtime-calculator/ttn/eu868

to get a per packet and the multiply it for per day

you are allowed 30 sec total air time per day and 10 uplinks

then i can tell you about your other problems

If your car starts making funny noises, does making it work faster than designed help solve the problem?

And can you keep up with the flood of results or are you just filling the shared radio spectrum and possibly jamming up the local LoRaWAN network by hammering it in the hope that it will suddenly start working?

So much more scientific to have a push to send button, you push, it sends, you review results, you make adjustments, you push and so forth.

As above, help from the volunteers is inspired by co-operation, so please confirm you are working to the FUP.

Depending on various parameters, you may well be breaching your local laws as well. :police_car: :policeman: :judge:

Hi @descartes, Seems I made a big mistake, as a newbie in LoRa sincere apologies for it and thanks a lot for your valuable explanation. I want to explain my situtation that I am under incredible pressure to address a hard deadline (one of reason I am replying on weekend and deadline is by coming tuesday) which is committed to the management i.e. to demonstrate wireless communication if it’s possible due to which I proceeded with quick but incorrect path i.e. to simply follow tutorials on internet where they just enter 60 seconds of interval. Seems a big mistake.

Based on valuable feedback by @Piet_Pillay, I read FUP policy here and have realized that working on LoRa or any other wireless protocol is much more than programming an Arduino and being able to see the data wirelessly. After you pointed it out I am not powering on the node and the device, until I get your and communities valuable feedback that It’s good to go.

As suggested here, I entered payload size to be 1 and overhead size to be 12 the worst that I see is DR0 where 25msg/24 hour is allowed based on which 3456 seconds should be the time interval hopefully this should allow me to proceed.

To comply with the policy, I will modify the code with data to be a character i.e. a (1 byte) and change the TX_interval to be 5000 seconds to be on safe side. Now I can confirm I am working to the FUP policy and is in my KIV.

I am in urgent need of communities help, please help me to decide if it’s good to go, till then my devices are off.

Thanks a lot and sorry for making it complicated.

You are not the first and won’t be the last - it’s very frustrating that people do that. A push to send is far easier to monitor the results. But you are here now.

You want volunteers working on community projects to help fix a commercial Proof of Concept?

If management need a demonstration of wireless communication, what’s wrong with their smartphone or laptops WiFi.

If they want a demonstration of LoRa tech, there are so many extra pieces of the puzzle that they are likely to not care about or want to get in to or even fully understand.

We can assume that LoRa works - otherwise I’d not get to eat and TTI wouldn’t exist.

LoRa is usually very optimistically represented. Most radio system we measure the distances in meters, for LoRa we can measure in kilometres, under the right conditions. You could put some devices 500m away and still not receive uplinks, alternative you could put some devices 5,000m away and get uplinks reliably.

It’s not WiFi, so we can’t move lots of data. The maximum that fits most regions as you may see on the online calculator is 54 bytes. The uplink interval is restricted on TTN as it’s a free resource. But if you pay for your own server, you can uplink more frequently. It’s still not WiFi. Nor is it suitable for command & control as downlinks render the gateway deaf whilst transmitting, so no other uplinks can get through. And as we are using a shared radio spectrum, some interference may occur.

I’m telling you this now so that when we get your demo working that you don’t then end up with another mission impossible and hopefully that you will read all of the Learn section (an evening of your time) before Tuesday so you have a clearer idea of what LoRaWAN is about.

first search for rssi high levels or node to close to gateway

How much memory is reported remaining when you compile this - it is a very very tight fit on this hardware and you have to really know what options to turn off on LMIC to make it work.

This refers to the setup of a LoRaWAN server on the Pi itself - useful for testing with. It’s a marketing bullet point added to amaze but if you don’t know the details, it’s a gotach - seems it gotcha.

They need to be a minimum of 5m with a substantial (brick / plaster) wall between to reduce the signal strength - otherwise they will be shouting at each other so hard that it will distort the signal.

Apart from DR0 being illegal in your jurisdiction so really not a good idea, you still seem obsessed with the interval. Push button gives you control over tests and is useful for demos - particularly amazing when you push the button and by the time you’ve moved your eyes, the data is on the console. I’d use DR5 with a 7 byte payload and then at worst you can set the interval to 3 minutes.

Can you see the gateway statistics in the gateways activity console?

Can you see any uplinks in the gateways activity console that have the DevAddr for your device that match up with an uplink on the device console?

How confident do you feel with Arduino overall?

Normally I’d pause for answers, but as I’ve clients in AU, I know that you need a whole todo list. I’ll grab a coffee and give you the second half of checks shortly.

Four questions in bold, please ensure there are four answers to help move forward quickly.

By management, do you mean professor or tutor by any chance, given your location is reported as Nanyang Technological University …

Thanks a lot @descartes to reply.

Yes, you are correct. 20% of memory is remaining.

Noted, thank you, then I’ll revert the changed I made in library, and will proceed as default i.w. LoRaWAN 1.0.3.

Understood I put the gateway around 10 m away, on other desk for it to act as a wall.

Understood, then I will modify the code to DR5 and interval to be 180 seconds however will keep payload to 1 byte.

Yes, gateway is connecting with TTN.

No, nothing for my node.

Thank you so much for the questions, hope I answered your questions.

Ahh sorry, I am a bit concern to talk about location and my personal details on public form, can we talk about it privately. Thank you.

Sorry, I didnt got you clearly, you mean to keep gateway away from node? I put the gateway around 10 m away, on other desk for it to act as a wall. did I answer your question? please reply. Thank you.

what do you see in the console

rssi need to be down to -60~-70 to -110

It’s of public record because you use the internet which has IP addresses that allocated in blocks.

You are either a student or not - plenty come on here for us to do their homework - forum search will reveal this.

There is a pencil at the bottom of each post that allows you to edit rather than delete and put another post in.

How does another desk act as a wall?

Not enough - you need at least 800 bytes free for the heap to work inside the heart of the stack.

Makes no odds due to the way that chirps work - you can have 3 bytes for the same airtime.

I said four, you’ve answered three …