I have a node working at a fixed SF of SF8, sending unconfirmed uplinks. In the TTN console, ADR is switched off, and also the ADR bit in the FCtrl byte is set to zero.
However, I find that the network keeps sending LinkADRReq downlink messages after every uplink. The first LinkADRReq after joining requests the device to go to DR0. The devices answers with a mac command 0x03 0x05, meaning it confirms power and channel settings, but it does not confirm DR settings. The next LinkADRReq requests the device to go to DR4 = (by coincidence?) SF8 = the fixed DR at which it is operating. So the device replies with a mac command 0x03 0x07, meaning it confirms power, DR and channel settings.
But even after this confirmation, the network keeps sending a downlink after each uplink with a LinkADRReq requesting to go to SF8 (which it already uses).
I experimented with setting the ACK bit in the FCtrl byte when replying with a confirmation to the LinkADRReq, but this does not work either.
How can I silence these LinkADRReq requests because I don’t want these unnecessary downlinks?
Have you checked this topic?
@kersing Thanks for the link. Although this mentions ABP and my device is OTAA. Specific behaviour for OTAA is still a bit up in the air I understand from this post?
Anyway, it’s not logical imho for the server to request the device to transmit at SF8, when it is already exactly doing that. Waste of spectrum.
I’ll tell my customer to try and use the CLI-option, as I have no control over the keys that will be rolled out for devices with this software.
A typical real-world bug - PitA for a niche case but with a work around available. And they did all that coding for us for free!
If you want to influence the updates to TTS then filing a GitHub issue will help.
I can see exactly same behavior: no way to stop it.
It is a clear waste of resources, as every packet send out by the device results in the reply from the network, which otherwise would not be the case.
There is if you read the thread and follow the link 3 posts above
Facing this same issue with the GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment library on a TTGO LoRa32 V1 using an SX1276.
Verbose stream off:
Verbose stream on (note the MAC command answer missing and Link ADR request enqueued):
Example of one of the downlinks:
{
"name": "as.up.data.forward",
"time": "2025-06-19T10:20:04.760581184Z",
"identifiers": [
{
"device_ids": {
"device_id": "lmictest",
"application_ids": {
"application_id": "ttgo-lora32-sx1276-electronicallye"
},
"dev_eui": "70B3D57ED0070BE7",
"join_eui": "0000000000000000",
"dev_addr": "260DC5AB"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
"end_device_ids": {
"device_id": "lmictest",
"application_ids": {
"application_id": "ttgo-lora32-sx1276-electronicallye"
},
"dev_eui": "70B3D57ED0070BE7",
"join_eui": "0000000000000000",
"dev_addr": "260DC5AB"
},
"correlation_ids": [
"gs:uplink:01JY3V7TJ66TJK555KFJ8PK7ES"
],
"received_at": "2025-06-19T10:20:04.755646267Z",
"uplink_message": {
"session_key_id": "AZeHrMmedbA0J7uAwvbtMQ==",
"f_port": 1,
"f_cnt": 26,
"frm_payload": "SGVsbG8sIHdvcmxkIQ==",
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "eui-647fdafffe00b437",
"eui": "647FDAFFFE00B437"
},
"time": "2025-06-19T10:20:04.439Z",
"timestamp": 4288009828,
"rssi": -95,
"channel_rssi": -95,
"snr": 7.5,
"location": {
"latitude": -34.770833066481295,
"longitude": 138.719783330873,
"source": "SOURCE_REGISTRY"
},
"uplink_token": "CiIKIAoUZXVpLTY0N2ZkYWZmZmUwMGI0MzcSCGR/2v/+ALQ3EOSs1/wPGgwI1MjPwgYQz6OIhgIgoO21iubSDioMCNTIz8IGEMC3qtEB",
"channel_index": 15,
"gps_time": "2025-06-19T10:20:04.439Z",
"received_at": "2025-06-19T10:20:04.483825593Z"
}
],
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 12,
"coding_rate": "4/5"
}
},
"frequency": "917800000",
"timestamp": 4288009828,
"time": "2025-06-19T10:20:04.439Z"
},
"received_at": "2025-06-19T10:20:04.551189852Z",
"consumed_airtime": "1.646592s",
"network_ids": {
"net_id": "000013",
"ns_id": "EC656E0000000183",
"tenant_id": "ttn",
"cluster_id": "au1",
"cluster_address": "au1.cloud.thethings.network"
}
}
},
"correlation_ids": [
"gs:uplink:01JY3V7TJ66TJK555KFJ8PK7ES"
],
"origin": "ip-10-102-15-98.ap-southeast-2.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01JY3V7TRRHEBYYN43NY3FYYPG"
}
Decoded using https://lora-packet.vercel.app/:
YKvFDSYKGwADAAIAcQMAAP8BizxNoA==
Encoded = base64
Message Type = Data
PHYPayload = 60ABC50D260A1B000300020071030000FF018B3C4DA0
( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
MHDR = 60
MACPayload = ABC50D260A1B000300020071030000FF01
MIC = 8B3C4DA0
( MACPayload = FHDR | FPort | FRMPayload )
FHDR = ABC50D260A1B000300020071030000FF01
FPort =
FRMPayload =
( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
DevAddr = 260DC5AB (Big Endian)
FCtrl = 0A
FCnt = 001B (Big Endian)
FOpts = 0300020071030000FF01
Message Type = Unconfirmed Data Down
Direction = down
FCnt = 27
FCtrl.ACK = false
FCtrl.ADR = false
FCtrl.FPending = false
FOpts = 03 00 02 00 71 03 00 00 FF 01
The first byte 0x03 indicates this is a LinkADRReq MAC command, 4 bytes in length. Disregard the first one (which is not valid). The second is setting the data rate to DR0 and MaxEIRP (30 dBm) then ChMask of 0xFF00 = channels 8-15 (sub-band 2). None of this is accepted
Working through the links earlier in the thread now…
This statement is posted too easily. Why is it invalid? What does LMIC do? It is a completely valid LinkAdrReq payload.
If it was not accepted, we should see a NACK on the LinkAdrReq (“rejected”) in the console. But instead the answer is missing.
There are more details required than we currently have - are there any LMIC logs?
Hey Steven,
Those points you raised, all valid! Just edited my post to tidy up some poorly written sentences.
The LMIC serial monitor printout is very basic indeed. No more than TX_COMPLETE and the frequency.
I’ve shutdown my computer for the night, so just replying on mobile.
… which means the parts I quoted are not visible anymore to others that may try to catch up.
“An end-device answers to a LinkADRReq with a LinkADRAns command” - line 704, page 25 of v1.0.3 spec. Yet I still see that there is no LinkAdrAns in the screenshot, just “MAC command answer missing”. There actually should have been three replies: not only LinkAdrAns twice but also DevStatusAns. I’m not sure if each missing Ans racks up an entry in the console log or whether that one entry expands to include all three. But there is no DevStatusAns in the log. Soo… did your device even receive the downlink? (You only mention TX_COMPLETE.) If so, did it process the MAC commands (if that can be viewed in any way)? If so, is there an uplink missing in between causing the next uplink to be ‘empty’?
So many questions… (to be answered tomorrow).
Indeed, discombobulating a thread by editing what’s said is unacceptable - any information or context could change.
If you read the instructions and look at the settings you can turn on a very detail output …