OTAA join successful, no payload data received

Issue:
Using OTAA, the sensor joins the gateway but no payload data is received in the uplink. TTN shows activation but no data. Gateway packet logger show join request, join accept and uplink but contains no payload.

Setup: RAK7258 gateway in testing with no nodes running

LoRa® Server: TTN

Details:
This issue appeared recently but seemed to fix itself but now has returned.
The nodes I am testing with have worked in the past with this gateway and work fine with other gateways but only recently has it stopped working.

Below are the packet log details from the RAK gateway:
Join request:
{ "fType": 0, "freq": 917000000, "chan": 1, "tmst": 4174065620, "rfch": 0, "stat": 1, "rssi": -70, "size": 23, "modu": "LORA", "datr": "SF12BW125", "codr": "4/5", "lsnr": 8.3, "data": "AHm8AdB+1bNwe6nf+mkEIwBAlEnO4E4=" } { "MHDR": { "MType": "Join Request", "RFU": 0, "Major": 0 }, "JoinRequest": { "AppEUI": "70 B3 D5 7E D0 01 BC 79 ", "DevEUI": "00 23 04 69 FA DF A9 7B ", "DevNonce": "9440" }, "MIC": "4EE0CE49" }
Join accept:
{ "freq": 923300000, "mode": "timerstamped", "tmst": 4180065620, "rfch": 0, "powe": 16, "prea": 8, "ncrc": true, "modu": "LORA", "datr": "SF12BW500", "codr": "4/5", "ipol": true, "size": 17, "data": "IB5khCrYVeW72cwkblKwS9U=" } { "MHDR": { "MType": "Join Accept", "RFU": 0, "Major": 0 }, "JoinAccept": "1E64842AD855E5BBD9CC246E", "MIC": "52B04BD5" }
Uplink message:
{ "fType": 0, "freq": 917600000, "chan": 4, "tmst": 4181719660, "rfch": 1, "stat": 1, "rssi": -71, "size": 19, "modu": "LORA", "datr": "SF12BW125", "codr": "4/5", "lsnr": 7.5, "data": "QMAsBiaAAAABG67jQQnNzHJFiA==" } { "MHDR": { "MType": "Unconfirmed Data Up", "RFU": 0, "Major": 0 }, "MACPayload": { "FHDR": { "DevAddr": "26062CC0", "FCtrl": { "ADR": true, "ADRACKReq": false, "ClassB": false, "ACK": false, "FOptsLen": 0 }, "FCnt": 0 }, "FPort": 1, "FRMPayload": "01 1B AE E3 41 09 " }, "MIC": "CC724588" }
Below is a photo of the TTN console. It shows activation with no uplink. Uplink data with no payload is shown on the TTN gateway traffic which is mostly the same as the packet logger on the gateway.

Some advice on this topic would be much appreciated, cheers.

Hi @Spark,
It would seem from the image that only the quin request is present, there is no join accept there, meaning that the node probably never received it. Seems like there was never n activation, the node should either try to join again, or stop sending all together. Sending an up link that goes through seems highly unlikely. Can you check you application configuration, are all the 3 keys as they should be in both the node and the TTN application?
Perhaps therein lies the issue ?
Regards
Vladislav

Thanks for the response,
All three keys are matching so it doesn’t appear that’s the problem. This node worked in the past without changing any of its software.
When the node it turned on, it sends its join request and receives its join accept from gateway. This can be seen on the serial monitor of the node below.


The node then appears to transmit its uplink which is received by the gateway and shown in the gateway packet message (at the start of my post). The TTN gateway console also shows the join request and accept as well as the uplink message but said message contains no payload data.

Something that I noticed from the data in the uplink message in the packet logger on the gateway said "MType": "Unconfirmed Data Up", - this can be seen on the inital post.
I don’t know if this is meaningful or not for this situation

Hi @Spark,

Apparently there is a 19 bytes payload in TTN, yet you say there is no payload ? Are all 19 bytes 0s or something ?

Regards
Vladislav

All 19 bytes are not zeros, they are seemingly random HEX values that do not decode to anything useful. I’m not sure why they are there or what they mean. The packet is supposed to be only 6 bytes long.

@Spark,

Honestly, no idea what to tell you. In summary:

  1. Gateway is connected and visible in TTN
  2. Node send a join request and receives a join accept and this is visible both in the TTN console and the gateway
  3. There is payload data that is visible both in the Gateway and in the TTN console
  4. Payload data is seemingly random
  5. Nodes have worked before with this exact Gateway

I have no idea what could cause such behavior? Could you update to the latest firmware:
https://downloads.rakwireless.com/LoRa/Indoor-Gateway-RAK7258/Firmware/

@velev Any ideas ?

Regards
Vladislav

I’ve updated the firmware and it made no difference. I also tested using a dragino lora node to ensure it wasn’t a fault in my other nodes and it still showed the same behaviour. I then made sure it wasn’t the code by running a LMIC example sketch that i know works and it still acted the same way. I can only conclude that the issue is with the gateway.

HI @Spark can you send me the Dragino code? To test this behavior.
Thank you.

This is the Dragino code. Its however for 915mHz so i’m not sure if it’ll work if you use another frequency.

`/*******************************************************************************

  • Copyright © 2015 Thomas Telkamp and Matthijs Kooijman
  • Copyright © 2018 Terry Moore, MCCI
  • Copyright © 2018 Betina Wendel and Thomas Laurenson
  • 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.
  • Sketch Summary:
  • Target device: Dragino LoRa Shield (US900) with Arduino Uno
  • Target frequency: AU915 sub-band 2 (916.8 to 918.2 uplink)
  • Authentication mode: Over the Air Authentication (OTAA)
  • This example requires the following modification before upload:
    1. Enter a valid Application EUI (APPEUI)
  • For example: { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
    1. Enter a valid Device EUI (DEVEUI)
  • For example: { 0x33, 0x22, 0x11, 0x11, 0x88, 0x88, 0x11, 0x22 };
  • This is little endian format, so it is in reverse order that the server
  • provides. In the example above, the original value was: 2211888811112233
    1. Enter a valid Application Key (APPKEY)
  • For example: { 0xe4, 0x17, 0xd3, 0x3b, 0xef, 0xf3, 0x80, 0x7c, 0x7c, 0x6e, 0x42, 0x43, 0x56, 0x7c, 0x21, 0xa7 };
  • The DEVEUI and APPKEY values should be obtained from your LoRaWAN server
  • (e.g., TTN or any private LoRa provider). APPEUI is set to zeroes as
  • the LoRa Server project does not requre this value.

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

#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

// 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]= { };
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]= { };
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 the TTN console can be copied as-is.
static const u1_t PROGMEM APPKEY[16] = { };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}

static uint8_t mydata[] = “OTAA”;
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 for Dragino Lorashield
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 6, 7},
};

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”));
{
u4_t netid = 0;
devaddr_t devaddr = 0;
u1_t nwkKey[16];
u1_t artKey[16];
LMIC_getSessionKeys(&netid, &devaddr, nwkKey, artKey);
Serial.print("netid: ");
Serial.println(netid, DEC);
Serial.print("devaddr: ");
Serial.println(devaddr, HEX);
Serial.print(“artKey: “);
for (int i=0; i<sizeof(artKey); ++i) {
Serial.print(artKey[i], HEX);
}
Serial.println(””);
Serial.print(“nwkKey: “);
for (int i=0; i<sizeof(nwkKey); ++i) {
Serial.print(nwkKey[i], HEX);
}
Serial.println(””);
}
Serial.println(F(“Successful OTAA Join…”));
// Disable link check validation (automatically enabled
// during join, but because slow data rates change max TX
// size, we don’t use it in this example.
LMIC_setLinkCheckMode(0);
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;
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.print(F(“Received “));
Serial.print(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;
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”));
Serial.print(F("Sending packet on frequency: "));
Serial.println(LMIC.freq);
}
// 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

#if defined(CFG_au921)
Serial.println(F("Loading AU915/AU921 Configuration..."));
#endif

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

LMIC_setDrTxpow(DR_SF7, 14);
LMIC_selectSubBand(1);
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

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

}

void loop() {
os_runloop_once();
}`

Thank you. Will test it and give you feedback about this problem.

You are looking at the raw packet as sent over the air, which contains 9 bytes of LoRaWAN header, 6 bytes of encrypted payload, and then 4 bytes of cryptographic checksum.

You’ll only recover your original application-level payload after the raw packet has been processed, decrypted, and validated by the network and application servers.

In terms of the original topic, join requests do not contain any applications data. Additional, after a join you may see some housekeeping traffic going back and forth sent to port 0 - traffic sent to port zero is reserved for network use, so that also would not have any application data.

It does seem though that at some point you had an actual application uplink packet - the 6 bytes of applications payload and 13 bytes of framing totaling to 19 bytes. Why you aren’t seeing that come through is unclear, but it’s not entirely clear if the various situations you’ve reported (screenshots vs text logs) are all the same test, or different tests.

@Spark
Hello!
Can you try and use RAK7258’s built-in lora server?
You can add your node information to RAK7258’s built-in lora server.
If sending data is unsuccessful, we can get the log of the built-in lora server to troubleshoot the problem.

@ZhuQI are you able to give me some guidance on how to add my node to the build-in lora server and get the log?

If conditions permit, you can install chirpstack on your pc, you can refer to https://github.com/RAKWireless/ChirpStack_on_Ubuntu

The next 5 days are our holidays, you can email me at [email protected] .

1 Like