My end device console in TTN(dragino lora shield with DHT11 sensor) is not receiving uplinks although the gateway is receiving uplinks. I used ABP. The NWKSKEY, APPSKEY and device address in my code are correct(msb format and device addr in uint32_t format).
Try switching to OTAA and see how it performs then would be 1st step - assuming you have everying else configured corrrectly, Keys, MSB/LSB, freq plan etc. Also check what spread of channels the received messages at GW are seen on. Which firmware stack are you using? (source link). Signal strength high but not a concern at this point (another meter or two of seperation might be useful). Can you post configs from server and device and any serial o/p from device?
Also change (reduce!!!) uplink rate - just letting it run free hammering uplinks wont solve problem, perhaps add a push to send button then you can see a message in isolation⌠with such a strong signal and good SNR suprised to see missing fcounts so clearly something else is wrongâŚ
At what frequency are the uplinks received by the gateway? And which frequencies have been configured for the end device?
Both gateway and end device is configured at 865402500 Hz.
Your end device uses multiple frequencies. Which? And what is configured in the TTN console for that device (device settings, Network layer, Advanced MAC settings, did you add any frequencies there)?
I use only one frequency(865402500). I can show you the settings of my device.
Here is my arduino code:
#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
#include <DFRobot_DHT11.h>
DFRobot_DHT11 DHT;
#define DHTPIN 3
// ABP credentials (replace with your own)
static const u1_t NWKSKEY[16] = { 0xA7, 0x63, 0xC1, 0x3F, 0xBE, 0xA4, 0x04, 0xB8, 0x4F, 0xA3, 0x2D, 0x91, 0x3C, 0xEF, 0xBE, 0x2E };
static const u1_t APPSKEY[16] = { 0x45, 0x0E, 0x3F, 0xB6, 0x04, 0x2E, 0x8D, 0x51, 0x66, 0x05, 0xF5, 0xF1, 0x8C, 0x3E, 0x15, 0x93 };
static const u4_t DEVADDR = 0x260D65BF;
// LoRa pins for Dragino LoRa Shield
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 6, LMIC_UNUSED_PIN}
};
void os_getArtEui(u1_t* buf) {}
void os_getDevEui(u1_t* buf) {}
void os_getDevKey(u1_t* buf) {}
osjob_t sendjob;
const unsigned TX_INTERVAL = 30; // seconds
void do_send(osjob_t* j) {
delay(2000); // allow DHT to stabilize
DHT.read(DHTPIN);
Serial.print("Temperature: ");
Serial.println(DHT.temperature);
Serial.print("Humidity: ");
Serial.println(DHT.humidity);
uint8_t payload[2];
payload[0] = (uint8_t)DHT.temperature;
payload[1] = (uint8_t)DHT.humidity;
LMIC_setTxData2(1, payload, sizeof(payload), 0);
Serial.println(F(âPacket queuedâ));
}
void onEvent(ev_t ev) {
Serial.print(os_getTime());
Serial.print(": ");
switch(ev) {
case EV_TXCOMPLETE:
Serial.println(F(âEV_TXCOMPLETE (Transmission complete)â));
os_setTimedCallback(&sendjob, os_getTime() + sec2osticks(TX_INTERVAL), do_send);
break;
default:
Serial.println(F(âUnknown eventâ));
break;
}
}
void setup() {
Serial.begin(9600);
delay(1000);
Serial.println(F(âStarting LoRa DHT11 ABP TTN SenderâŚâ));
os_init();
LMIC_reset();
// Set up single IN865 channel (865.4025 MHz)
for (int i = 0; i < 9; i++) {
if (i != 1) LMIC_disableChannel(i);
}
LMIC_setupChannel(1, 865402500, DR_RANGE_MAP(DR_SF7, DR_SF7), BAND_CENTI);
LMIC_setSession(0x1, DEVADDR, NWKSKEY, APPSKEY);
LMIC.seqnoUp = 0;
LMIC.seqnoDn = 0;
LMIC_setLinkCheckMode(0);
LMIC_setDrTxpow(DR_SF7, 14); // SF7, TX power 14 dBm
// Give sensor time to stabilize
delay(2000);
DHT.read(DHTPIN);
// Start transmission only after sensor read
do_send(&sendjob);
}
void loop() {
os_runloop_once();
}
This config of you overriding the LMIC settings, particularly the channel settings, is quite far outside the general design & intent of LoRaWAN, so anything could be happening to break the system.
But at the very least, you need to add the frequency you are using to the device on the console.
Or go with OTAA as it sorts out so much of this âstuffâ for you.
That does not sound LoRaWAN compatible. Devices in India should use three channels as listed in the TTN channel plan.
If you look at the received data in the gateway part of TTN, what is the frequency listed? (Please show the json TTN provides when you click on the received data line formatted using the tools at the top of the textbox.)
Can you stop hammering the airwaves and TTN infrastructure every 30 seconds? You should adhere to the TTN fair use policy which limits you to 30 seconds airtime a day. With this frequency of transmitting you can only run the device for a under 2 hours before breaching the fair use policy.
This is my internship project only. I am new to this field and I fixed TX_INTERVAL as 30 seconds only for testing this. My intention is to just demonstrate this to my professor. Yeah, I can provide you the json data of uplink.
{
"name": "gs.up.receive",
"time": "2025-06-09T20:53:31.755356560Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "dragino-gateway-iot",
"eui": "A84041FFFE1BF050"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
"message": {
"raw_payload": "QL9lDSaACgABKtE9vIm1",
"payload": {
"m_hdr": {
"m_type": "UNCONFIRMED_UP"
},
"mic": "PbyJtQ==",
"mac_payload": {
"f_hdr": {
"dev_addr": "260D65BF",
"f_ctrl": {
"adr": true
},
"f_cnt": 10
},
"f_port": 1,
"frm_payload": "KtE="
}
},
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7,
"coding_rate": "4/5"
}
},
"frequency": "865402500000000",
"timestamp": 3318223085,
"time": "2025-06-09T20:53:31.673762Z"
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "dragino-gateway-iot",
"eui": "A84041FFFE1BF050"
},
"time": "2025-06-09T20:53:31.673762Z",
"timestamp": 3318223085,
"rssi": -44,
"channel_rssi": -44,
"snr": 7.8,
"location": {
"latitude": 26.185423425317786,
"longitude": 91.69131398900774,
"source": "SOURCE_REGISTRY"
},
"uplink_token": "CiEKHwoTZHJhZ2luby1nYXRld2F5LWlvdBIIqEBB//4b8FAQ7aGgrgwaDAjLk53CBhC2zZLnAiDIu4isydoC",
"channel_index": 7,
"received_at": "2025-06-09T20:53:31.753182390Z"
}
],
"received_at": "2025-06-09T20:53:31.753182390Z",
"correlation_ids": [
"gs:uplink:01JXB7GGZBPFCYVBKRJG21NGZK"
],
"crc_status": true
},
"band_id": "IN_865_867"
},
"correlation_ids": [
"gs:uplink:01JXB7GGZBPFCYVBKRJG21NGZK"
],
"origin": "ip-10-102-13-194.ap-southeast-2.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01JXB7GGZBT7K8YSX2BAS39YN7"
}
How to add frequency? Do I need to change the Rx2 freq and desired Rx2 freq in advanced mac settings of network layer to 865.4025 MHz?
I only passed my driving test last week your Honour, so I thought Iâd drive really fast to see what it is like âŚ
Then I saw a community first aid station and thought Iâd take all the bandages just in case, so nothing is left for the rest of the community.
Add it to the âFactory preset frequency listâ - the extensive documentation is well worth reading.
No. You need to learn the basics of LoRaWAN as this is a fundamental.
PS, Please ensure you use the </> tool to format the text/logs/JSON please - you can edit your post to do this now.
The IN865 band does list 865.4025MHz as one of the three main uplink channels, so this frequency looks perfectly fine, without the need to define this frequency as a factory preset channel.
I formatted the code. Please check it.
1 Like
I added my frequency to factory preset frequency. It didnât help.
My professor gave me dragino LG01 gateway. Is that the real cause for not getting the uplinks to end device?
The point is that the device should use all three available channels, LoRaWAN devices should never use just one channel to avoid saturating the frequency.
The use of a single channel usually means a non LoRaWAN compliant gateway (single channel packet forwarder) is being used which is detrimental to the network.
So why is this ABP device just using that single channel? @nibil97
Yes, please disconnect it immediately, it is not supported on TTN and its presence disrupts the network as you have discovered. See: Single Channel Packet Forwarders (SCPF) are obsolete and not supported
YMMV - last time I used ABP, when v3 was all new & shiney and theyâd just plumbed in a fresh water supply to the street, if you didnât put all eight frequencies in for the channel plan you were using, it didnât work.
Things on The Things Server may have progressed since then.
My ABP device uses single channel gateway, so I configured only one channel. Now I tried configuring 3 channels and it didnât work.
It doesnât matter, your Single Channel Packet Forwarder wonât be able to cope with three channels like a proper gateway can and because it creates a denial of service to other users, should NOT BE USED!
Please confirm that this LG-01 is disconnected. If you tutor has a problem, ask them to message me or @kersing on the forum.