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
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 
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.
Hi Nick
thanks for your concern.
Hello, world! encoded as Base64 is SGVsbG8sIHdvcmxkIQ==
It’s more the other way round, you find out how the hardware is connecting the DIO pins and then tell the sketch in the pins section.
No, no, no, no, no, no, no. OMG, who told you that?
Confirmation links are rare. When your gateways transmits the ack it can not hear anything at all, so all other nodes may be transmitting but their uplink won’t get through.
And as an individual device, your gateway may then exceed your local legal limits.
We use confirmed uplinks when we HAVE to know the gateway heard it. Even then it doesn’t confirm that the entire backend has acted on the uplink.
Downlinks are completely the opposite - they are messages from you to the device, which you can also choose to have confirmed if you wish, but again should be used sparingly.
Thanks again Nick.
Clear no need for confirmation of node message.
What I need is now modify my sketch to send readings from a bmp pressure temperature sensor and be able to read and store it in Chirpstack.
If I modify the first contact sketch and include the bmp readings, where can I access and store it in Chirpstack?
Brgds
Emilio:
My ultimate goal is to implement a 14 node lorawan network with 7 sensors per node and store it in the internet, creating later a dashboard with grafana. All this is to be implemented in a lemon plantation in South east Spain in the coming 6 months as a company practice of my studies in technical school
Perhaps review the docs related to integrations and uplinks?
Yup!
I will look for them and study.
I have found my Hello World message!!! 
you have to press a little down arrow in Device Data in the Device!
Hello again guys
I managed to send node/device info from node to AWS SNS.
But I think there was a problem RAK could solve, and I say as feedback:
DNS server for the RAK7243 is not configured with the configuration protocol in web.
I had to do so using Putty linux commands and then I got access to AWS SNS
Before that, I could ping from Putty SSH connection to 8.8.8.8, but not to google.es
Nevertheless, my RAK 7243 is not valid for AWS IOT Core, so I must stop here and get a new RAK 7258 to do so.
Is that a proper gateway for handelling 14 nodes with 7 sensors each, 8 mobile esp32 sensors to track tractors, and 40 one month seasonal nodes for sending 2-3 photos per day each of citrus pest traps? All nodes being lora ESP32?
I will need 1 RAK 7258 to try and 4 to 14 more, if I succeed, so Vladislav, If can get a discount for the company let me know how do it.
Thanks for all your help. You have clarified my way a lot, and make me realise how some things work, that without your help would have stopped me.
REally, thank you both
Emilio
