How to connect LoRa node through the RAK7243 gateway to the chirpstack?

@Emilioher,

You can DM me, I am available now.

Regards
Vladislav

Hi Vladislav.
No I Can’t See the raw data. Lora device (esp32) sending corrector bmp80 sensor info.
Another node(esp32) receives info +300 metres away. So, believe is not RF problem.

Gateway visible in Chirpstack, but device no, and sensor info neither.
Thanks
Emilio

Hi Vladislav
Dont know What is DM.
Without children International Mc Auto un South Spain.
Possible Tomorrow?
Thanks a los
Emilio

Hello Vladislav.I answered you yesterday from phone, but seems didnt go through.
I do not use Instagram. Cannot DM.
Are you available today?
Can I send meet link and show you my screen, to configure whenever you can?
Thanks
Brgds
Emilio

If another node can receive the info then it would be deeply unlikely you are running LoRaWAN code on the ESP and as it is not transmitting any data in the LoRaWAN format, the gateway won’t be able to process the RF signal.

I have transmited and received between nodes using lora.
But now I have loaded a lora node sketch into an ESP32, that is transmiting a Hello World packet and Gateway not receiving.
Thanks for info

@Emilioher ,

This is exactly what @nmcc is implying. If you are trying to use a P2P sketch it will not work. The fact that you are not seeing any data in the Gateway Live data tab means there is simply no data that is transmitted on any of the available Channels with a proper DR.
Cn you share the sketch, seems your problem is the node, not the gateway.
DM means Direct message, it has nothing to do with Instagram.

Regards
Vladislav

Hello Vladislav.
This is the sketch I am using:
/*
LoRa Simple Gateway/Node Exemple

This code uses InvertIQ function to create a simple Gateway/Node logic.

Gateway - Sends messages with enableInvertIQ()
- Receives messages with disableInvertIQ()

Node - Sends messages with disableInvertIQ()
- Receives messages with enableInvertIQ()

With this arrangement a Gateway never receive messages from another Gateway
and a Node never receive message from another Node.
Only Gateway to Node and vice versa.

This code receives messages and sends a message every second.

InvertIQ function basically invert the LoRa I and Q signals.

See the Semtech datasheet, http://www.semtech.com/images/datasheet/sx1276.pdf
for more on InvertIQ register 0x33.

created 05 August 2018
by Luiz H. Cassettari
*/

#include <SPI.h> // include libraries
#include <LoRa.h>

const long frequency = 915E6; // LoRa Frequency

const int csPin = 10; // LoRa radio chip select
const int resetPin = 9; // LoRa radio reset
const int irqPin = 2; // change for your board; must be a hardware interrupt pin

void setup() {
Serial.begin(9600); // initialize serial
while (!Serial);

LoRa.setPins(csPin, resetPin, irqPin);

if (!LoRa.begin(frequency)) {
Serial.println(“LoRa init failed. Check your connections.”);
while (true); // if failed, do nothing
}

Serial.println(“LoRa init succeeded.”);
Serial.println();
Serial.println(“LoRa Simple Node”);
Serial.println(“Only receive messages from gateways”);
Serial.println(“Tx: invertIQ disable”);
Serial.println(“Rx: invertIQ enable”);
Serial.println();

LoRa.onReceive(onReceive);
LoRa.onTxDone(onTxDone);
LoRa_rxMode();
}

void loop() {
if (runEvery(1000)) { // repeat every 1000 millis

String message = "HeLoRa World! ";
message += "I'm a Node! ";
message += millis();

LoRa_sendMessage(message); // send a message

Serial.println("Send Message!");

}
}

void LoRa_rxMode(){
LoRa.enableInvertIQ(); // active invert I and Q signals
LoRa.receive(); // set receive mode
}

void LoRa_txMode(){
LoRa.idle(); // set standby mode
LoRa.disableInvertIQ(); // normal mode
}

void LoRa_sendMessage(String message) {
LoRa_txMode(); // set tx mode
LoRa.beginPacket(); // start packet
LoRa.print(message); // add payload
LoRa.endPacket(true); // finish packet and send it
}

void onReceive(int packetSize) {
String message = “”;

while (LoRa.available()) {
message += (char)LoRa.read();
}

Serial.print("Node Receive: ");
Serial.println(message);
}

void onTxDone() {
Serial.println(“TxDone”);
LoRa_rxMode();
}

boolean runEvery(unsigned long interval)
{
static unsigned long previousMillis = 0;
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval)
{
previousMillis = currentMillis;
return true;
}
return false;
}

I loaded 868 frecuency. not 915

I am using an ESP 32 T Beam by Lilygo. Sorry about brand name

There is NO LoRaWAN library in use here - just the library to drive the radio chip in LoRa mode. You need a LoRaWAN library like the MCCI LMiC.

but lorawan is from Gateway into the WAN, isnt it?
In the “LAN” ( nodes and sensors, and part of the gateway) is LoRa protocol, isnt it?
Thanks

LoRa is the radio transmission system.

LoRaWAN uses that radio transmission system to add a Media Access Layer - a specified sequence of bytes that relay the information & control messages.

You can send bytes like “48 65 6c 6c 6f 20 77 6f 72 6c 64” via LoRa to LoRa.

But there is no device identification, no encryption, no session, no counter, no headers, nothing that allows a gateway to know who it’s from & where to pass it on.

So, you can either continue to send LoRa packets out in to the wild OR you can get busy with a LoRaWAN library / stack.

Understood Nick.
Thanks a lot.
Have homework to do to understand and get ready to use LoRaWan.
Any video or written tutorial is wellcome.
Thanks a lot
Emilio

the RAK 7243 Lora Gateway is visible in Chirpstack

@Emilioher ,

There should be plenty of example sketches for your particular node. Just google LMIC for it.

Regards
Vladislav

Thanks a lot Vladislav.
Thanks both.
Look it up, try and feedback
Brgds and saludos amigos!

Hi guys
after much struggle just managed to connect my device to the RAK gateway.
THere are issues though. Do not get the Hello World message from the sketch and it says: " unconfirmed dataup"
Can you help me on that? Almost there :sweat_smile:

I have used IBM LMIC ttn otaa library renamed on behalf of my first contact:

/*******************************************************************************

  • 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 OTAA (Over-the-air activation), where where a DevEUI and

  • application key is configured, which are used in an over-the-air

  • activation procedure where a DevAddr and session keys are

  • assigned/generated for use with all further communication.

  • 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 an AppEUI, DevEUI and AppKey.

  • Multiple devices can use the same AppEUI, but each device has its own

  • DevEUI and AppKey.

  • Do not forget to define the radio type correctly in config.h.

*******************************************************************************/

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

// 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]={ 0x5b, 0xb1, 0x7b, 0x37, 0xe7, 0x5e, 0xc1, 0x4b };
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] = { 0x2c, 0x2f, 0x6f, 0x96, 0x9d, 0xee, 0xc6, 0x84, 0x05, 0x1a, 0x8e, 0xf0, 0x76, 0x3e, 0x77, 0xa4 };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}

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 = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 23,
.dio = {26, 33, 32},
/// .dio = {2, 3, 4},
};

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”));

        // Disable link check validation (automatically enabled
        // during join, but not supported by TTN at this time).
        LMIC_setLinkCheckMode(0);
        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;
        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();

// Start job (sending automatically starts OTAA too)
do_send(&sendjob);

}

void loop() {
os_runloop_once();
}

I suspect there could still be a pin assignation problem, or a problem in my void Enqueue dowlink payload config:

That’s normal. The payload will be encoded Base64 and probably appear on another layout.

What makes you suspect that?

What makes you suspect that? Particularly this bit, that’s for downlinks, not uplinks.