Only receiving data once after OTAA, with Dragino LPS8

Hello all,
This is my first post here I hope it is in the correct format and place.

I have an ESP32 along with an RFM95C (915mhz). I have a gateway that is a Dragino model LPS8
I am attempting to send data to TTN through my gateway. I am using otaa as this seems to be the most recommended.
I am using the Arduino IDE, Version 1.8.12, on Linux Mint. I am using the libraries lmic.h and hal/hal.h

When I attempt to send data, connection will join the gateway after some time. and will send data. however, the issue is that this will only happen ONCE. Any future attempts will not result in TTN console displaying that any data has been received. Is this, by any change by design? Is it hiding dup payload data? Or am I doing something wrong?

This applies to both sending and recieving data. When I use TTN console to simulate sending data to the esp32, the esp32 will report on the arduino IDE’s serial console that the data was received from TTN… but only once, the next requests will not be received UNTIL i reboot the ESP32.

Below is the full sketch I am using:

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

const lmic_pinmap lmic_pins = {
.nss = 5,
.rst = 27,
.dio = {26, 25, LMIC_UNUSED_PIN},

static const u1_t PROGMEM APPEUI[8]= { 0x79, 0x07, 0x03, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
static const u1_t PROGMEM DEVEUI[8]= { 0xB4, 0xA5, 0xC2, 0xC8, 0x53, 0x5C, 0xF4, 0x00 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
static const u1_t PROGMEM APPKEY[16] = { 0xC0, 0xFF, 0xBE, 0xBB, 0x88, 0x9A, 0x33, 0x39, 0x5D, 0x7C, 0x76, 0x80, 0x39, 0x47, 0x76, 0x46 };
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;

void setup() {

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

// Start job (sending automatically starts OTAA too)

void onEvent (ev_t ev) {
switch(ev) {
    case EV_JOINING:
    case EV_JOINED:
        Serial.println(F("EV_JOINED SUCCESS"));
        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.println(F(" bytes of payload"));
        // Schedule next transmission
        os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
        // data received in ping slot
    case EV_TXSTART:
        Serial.println(F("EV_JOIN_TXCOMPLETE: no JoinAccept"));
        Serial.print(F("Unknown event: "));
        Serial.println((unsigned) ev);

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

Here is my IDE’s Serial output:

Packet queued
344445: EV_JOINED
344451: EV_TXCOMPLETE (includes waiting for RX windows)
4094484: EV_TXSTART
Packet queued
4235905: EV_TXCOMPLETE (includes waiting for RX windows)
7985934: EV_TXSTART
Packet queued
8064706: EV_TXCOMPLETE (includes waiting for RX windows)
Received 1 bytes of payload
8095348: EV_TXSTART
8234201: EV_TXCOMPLETE (includes waiting for RX windows)
11984230: EV_TXSTART
Packet queued
12125649: EV_TXCOMPLETE (includes waiting for RX windows)
15875678: EV_TXSTART
Packet queued
16017102: EV_TXCOMPLETE (includes waiting for RX windows)
19767131: EV_TXSTART
Packet queued
19908549: EV_TXCOMPLETE (includes waiting for RX windows)
23658579: EV_TXSTART
Packet queued
23799998: EV_TXCOMPLETE (includes waiting for RX windows)
27550028: EV_TXSTART
Packet queued
27691446: EV_TXCOMPLETE (includes waiting for RX windows)
31441476: EV_TXSTART
Packet queued
31582894: EV_TXCOMPLETE (includes waiting for RX windows)
35332924: EV_TXSTART
Packet queued
35474343: EV_TXCOMPLETE (includes waiting for RX windows)
39224378: EV_TXSTART
Packet queued
39365796: EV_TXCOMPLETE (includes waiting for RX windows)

And here is all that I see in the console:
Screenshot from 2020-06-22 18-51-26

I figured that I should have added my gateway config and my integration. My integration is a Node.JS server that has been running for quite some time. It works 100% I have tested it using swagger and can simulate multiple POST requests. The integration does send the data over (but again… only once per boot)

Here are the pics of my gateway config:

gateway channel settings
gateway radio settings

Another Update…

I figure maybe the 1 request I get at the Node.JS side may be of use:

Received uplink from  test-device1
  app_id: 'cropwatchus',
  dev_id: 'test-device1',
  hardware_serial: '000E87281C6C2B48',
  port: 1,
  counter: 0,
  payload_raw: <Buffer 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21>,
  payload_fields: { result: 'Hello, world!' },
  metadata: {
time: '2020-06-23T03:34:16.067490565Z',
frequency: 902.7,
modulation: 'LORA',
data_rate: 'SF9BW125',
airtime: 205824000,
coding_rate: '4/5',
gateways: [ [Object] ]
  gtw_id: 'eui-a840411d91384150',
  timestamp: 133387876,
  time: '2020-06-23T03:34:16.022732Z',
  channel: 2,
  rssi: -120,
  snr: -6.8,
  rf_chain: 0

My goal is to send data from sensors, I am sure getting it into the uint8_t will be a challange too. But I would love to get this solved first.
If there is any more detail you would like me to provide, please let me know.
Thank you very much for the assistance!

(Aside: devices do not join gateways, but they join the network. The gateway only forwards the packets it receives to TTN and does not know anything about the devices.)

How many attempts are needed? Any chance the attempt only succeeds when the device uses a specific frequency (902.7 MHz in your info above)?

And for the uplink too: any chance you’re always see that on a specific frequency too? (You can click a row in the device’s Data page, to see those details.)

A proper device will alternate between the available channels, so will use a different frequency for each uplink. It may also use a different spreading factor SF if it thinks the reception quality needs that, but that is not likely to change after only a single uplink. You might see it increase during the OTAA Join though.

So, my first guess: the channel configuration is just not correct, in either the device or the gateway. Did you ever wait for a longer time, say 20+ messages, to see if some more are received? (And then: on which frequency?) Note that the documentation says for AS923:

We use two frequency plans, depending on the country. OTAA devices use two common channels: 923.2MHz and 923.4MHz. They will receive the additional channels on a successful join.

Which LMIC are you using? Does it support that? If not, then manual configuration in the device will be needed.

If the channels seem correct in both device and gateway: I do not know that gateway, but your Dragino LPS8 gateway seems to be a fully compliant gateway, hence supporting multiple channels and spreading factors. Good. But the screenshots confuse me and make me wonder if it’s not actually some other single-channel forwarder, not a true gateway. The configuration page about the “multiSF channel x enable” makes me wonder if you’ve configured it to support only a single SF. (But that alone does not explain a lot, as the SF will not change after just one uplink.)

Although this part of TTN Console might be very unreliable: what does the gateway’s Traffic page in TTN Console show you?

That is not simulating sending data. That’s truly scheduling a downlink to be transmitted on the next opportunity. But as the TTN Community network only supports “Class A” devices, transmitting such downlink needs TTN to receive a new uplink first. So, this seems related to your uplinks not being received.

Oh, wait. In another post you’re saying you’re in Japan, hence my mention of AS923 above. But how come you’re using 915 MHz then? The 902.7 MHz does not seem valid for Japan either?

For US915, I think TTN only uses about 8 out of 64 channels, so that surely needs configuration too. See also the Initial ADR request which your LMIC might not support?

When the unreliable gateway’s Traffic page in TTN Console does show traffic then that, or the logs in the gateway itself, may also reveal that the first downlink also includes network MAC commands. You can paste the full LoRaWAN packet into an online decoder to see if there’s anything in FOpts.

Such MAC command may set the channels (like the initial ADR Request mentioned above), after which your device’s configuration may no longer match that of the gateway. (Which would then indicate that the gateway’s configuration is not what TTN expects.) It may even instruct your device to change its data rate (SF and bandwidth) if it was using a very bad data rate for the OTAA join (which I think will not be the case for you, given your log showed SF9).

As for LMIC, it seems is best supported.