Issue with Uplink Transmission Limitation on a LoRaWAN Network Using Arduino Uno R3 and RAK7248c

Taregh_Khanjari · January 13, 2025, 1:58pm

I am currently developing a LoRaWAN network and have encountered a recurring issue that affects the uplink communication from my node, an Arduino Uno R3, to my gateway, a RAK7248c, with ChirpStack serving as the network server integrated within the gateway.

Problem Description: After initiating the network, the node is able to send only five uplink messages successfully. Following these transmissions, the network server ceases to respond with downlinks, and no further uplinks are processed. This behavior persists despite multiple attempts to reset and reconfigure the system.

Configuration Details:

Node Device: Arduino Uno R3
Gateway: RAK7248c
Network Server: ChirpStack integrated on the gateway
Frequency Plan: [Specify frequency plan, e.g., EU868]

I am seeking insights or potential solutions that might explain the limitation to five uplink messages and the lack of subsequent downlink responses.
Any suggestions or diagnostic tips from experts in the community would be greatly appreciated.

Liam_Philipp · January 13, 2025, 2:11pm

Some logs would help. If you aren’t seeing errors in the Chirpstack or Gateway logs it is likely an issue with the code of your device.

Taregh_Khanjari · January 13, 2025, 2:42pm

Thank you for your respond I can not see any error in the chirpstack and about the code fir device I use the orginal code of MCCI LoRawAN LMIC library code and just enter the data of APPEUI and DEVEUI

Liam_Philipp · January 13, 2025, 3:02pm

Can you share the code? When I check the github for lmic there are plenty of examples.

And when you say:

Can you explain what this means a little more. Do you still get uplinks in the gateway’s “lorawan frames” in your chirpstack application? Do you still get events in the devices events tab? Or is it just silence as far as you can tell after the first 5 uplinks?

Taregh_Khanjari · January 13, 2025, 3:39pm

this is the situation on my netwrok server :

Liam_Philipp · January 13, 2025, 3:45pm

Did you just start using Chirpstack? If so you really should be using v4 instead of v3. I’d highly recommend re-installing with the newer version.

I’m also a little confused why you are downlinking with each uplink, the uplinks are unconfirmed so they shouldn’t need a “reply” from the NS.

What interval are you expecting the device to uplink at? As every 4 seconds should not be the typical usage, perhaps it only does the 5 rapid uplinks at startup and now the LMIC code is waiting for an event before uplinking? Again, I’d need to see the code to confirm.

Taregh_Khanjari · January 13, 2025, 4:05pm

As I explained in the first message, I am using the RAK7248C gateway, which has ChirpStack version 3 installed. I recently reflashed the gateway, and the latest version of ChirpStack is now installed on it.

Regarding uplink and downlink communication, I believe this is the situation in the LoRaWAN protocol:
The node continuously sends uplinks and waits to receive downlinks from the network server.
For each uplink sent by the node, there should be a corresponding downlink.

Liam_Philipp · January 13, 2025, 4:37pm

This is not typical LoRaWAN protocol, it is possible, but if so the device should be sending ConfirmedDataUp, not unconfirmedDataUp. That distinction is what tells the network server to send a downlink to the device in response to the uplink. And if the downlink doesn’t come the device should retransmit its uplink.

Is this the code you are using:

github.com

mcci-catena/arduino-lmic/blob/master/examples/ttn-otaa-feather-us915-dht22/ttn-otaa-feather-us915-dht22.ino

/*******************************************************************************
 * The Things Network - Sensor Data Example
 *
 * Example of sending a valid LoRaWAN packet with DHT22 temperature and
 * humidity data to The Things Networ using a Feather M0 LoRa.
 *
 * Learn Guide: https://learn.adafruit.com/the-things-network-for-feather
 *
 * Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
 * Copyright (c) 2018 Terry Moore, MCCI
 * Copyright (c) 2018 Brent Rubell, Adafruit Industries
 *
 * 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.
 *******************************************************************************/
#include <lmic.h>
#include <hal/hal.h>

This file has been truncated. show original

If so the code does not require a response, and intentionally sends the data as unconfirmed up, indicated by the line:

LMIC_setTxData2(1, payload, sizeof(payload) - 1, 0);

Where the last parameter is whether the uplink is confirmed or not.

The default tx_interval in this code is 30 seconds. So if this is the code there should be more coming in regardless of whether the downlink is sent or not. Can you confirm if this is the code?

Taregh_Khanjari · January 13, 2025, 4:53pm

Yes I use this part and the problem is the same
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.
}

Liam_Philipp · January 14, 2025, 2:17pm

So you are not using that code but this instead:

github.com

mcci-catena/arduino-lmic/blob/master/examples/ttn-otaa-feather-us915/ttn-otaa-feather-us915.ino

/*******************************************************************************
 * 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. It's pre-configured for the Adafruit
 * Feather M0 LoRa.
 *
 * 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.
 *

This file has been truncated. show original

What do your logs look like on the device. Is the ev_txcomplete event triggering after the fifth uplink? As it waits for this event before sending another uplink. If it’s not getting the event you can work backwards from there, potentially a misconfiguration of the rx windows.

Taregh_Khanjari · January 14, 2025, 2:31pm

Thank you for trying to help me.
This code is designed for the US standard, but I am in the EU.
I fixed the problem by modifying the do_send loop.
Thank you for your help; your work is very valuable to me.
If anyone in the EU has the same problem, I can help.