Confusion around ack message request

#1

I am using HTCC-AB01V2 board with version 1.15.0 of cube cell environment

I am calling LoRaWAN.send() - in other words with no parameters

My understanding is that acknowledgements are off by default - is that correct?

However I receive an “unconfirmed downlink” message in serial monitor

In that message I see the line ack: true - does that mean it is an acknoledgement?

If I declare the “void downLinkAckHandle()” function, it gets called, so I assume it is an acknowledgement

I acually want this behaviour because I want to know if the uplink message was successfully received

I am just confused why I am receiving this acknowledgement given that I don’t believe I asked for it?

Thanks

#2

There are no parameters for that function. The confirmed is set via a global variable that you can see in the top half of the basic example.

The excitement of the LW library means the downlink ack handler may be related to responding to the MAC requests that usually arrive on a join. It’s hard to say without seeing the actual serial log, using the </> tool to quote it and a direct link to the code you are using.

By design, LW is not best suited for habitual use of confirmed uplinks - it renders the gateway deaf whilst it is transmitting the ack.

#3

Many thanks for the clarification

I found examples of LoraWAN.Send being called with three parameters one of which was the AckRequest boolean. I must have been looking at the wrong board/ library…

Thanks again

#4

My bad, looking at the wrong library, there is that parameter as you say, but the rest of the comments stand - if we have some more detail like serial output and gateway/device console screen shots we can be more specific.

#5

Thanks

The isTxConfirmed global is indeed set to true - it’s set to LORAWAN_UPLINKMODE which is set to CONFIRMED in Tools. So obviously I was requesting acks without realising it!

Here is an example of the uplink message JSON:
{
“name”: “as.up.data.forward”,
“time”: “2025-03-06T11:22:49.712600563Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “my-test-device”,
“application_ids”: {
“application_id”: “woodside”
},
“dev_eui”: “70B3D57ED006EA96”,
“join_eui”: “0000000000000000”,
“dev_addr”: “260BB8E9”
}
}
],
“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.ApplicationUp”,
“end_device_ids”: {
“device_id”: “my-test-device”,
“application_ids”: {
“application_id”: “woodside”
},
“dev_eui”: “70B3D57ED006EA96”,
“join_eui”: “0000000000000000”,
“dev_addr”: “260BB8E9”
},
“correlation_ids”: [
“gs:uplink:01JNNK388NW8RMR8ECM8D1BBVE”
],
“received_at”: “2025-03-06T11:22:49.704162225Z”,
“uplink_message”: {
“session_key_id”: “AZVrMUoB8huMerdQYiAvZw==”,
“f_port”: 2,
“f_cnt”: 2,
“frm_payload”: “AQ4OBQ==”,
“decoded_payload”: {
“bytes”: [
1,
14,
14,
5
]
},
“rx_metadata”: [
{
“gateway_ids”: {
“gateway_id”: “woodside-kona-micro-1”,
“eui”: “647FDAFFFE007B0B”
},
“timestamp”: 2631707355,
“rssi”: -38,
“channel_rssi”: -38,
“snr”: 9.8,
“uplink_token”: “CiMKIQoVd29vZHNpZGUta29uYS1taWNyby0xEghkf9r//gB7CxDb1fLmCRoMCImLpr4GELC36+oBIPjO7e/L4CM=”,
“channel_index”: 4,
“received_at”: “2025-03-06T11:22:49.478909984Z”
}
],
“settings”: {
“data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 7,
“coding_rate”: “4/5”
}
},
“frequency”: “867300000”,
“timestamp”: 2631707355
},
“received_at”: “2025-03-06T11:22:49.494292276Z”,
“confirmed”: true,
“consumed_airtime”: “0.051456s”,
“version_ids”: {
“brand_id”: “heltec”,
“model_id”: “cubecell-dev-board-class-a-otaa”,
“hardware_version”: “unknown_hw_version”,
“firmware_version”: “1.0”,
“band_id”: “EU_863_870”
},
“network_ids”: {
“net_id”: “000013”,
“ns_id”: “EC656E0000000181”,
“tenant_id”: “ttn”,
“cluster_id”: “eu1”,
“cluster_address”: “eu1.cloud.thethings.network”
},
“last_battery_percentage”: {
“value”: 0.7905139,
“received_at”: “2025-03-05T18:24:56.579998324Z”
}
}
},
“correlation_ids”: [
“gs:uplink:01JNNK388NW8RMR8ECM8D1BBVE”
],
“origin”: “ip-10-100-4-208.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01JNNK38FG9N8FAD5CW4M4ZV2S”
}

#6

I’m not sure what this is for - sure, it shows that it’s got the confirmed flag and I’m sure you know you only get 9 more of those today when using TTN, per Fair Use Policy.

Would be easier to read if formatted with the </> tool.

Do you see MAC requests in the device console - with such an old version of LW I’d expect all sorts of Rx1 type sends.

#7

Apologies, I misread your previous message. I thought you asked for an example of the uplink message

Here is a screenshot of the device console

2025-03-06_15-31-13
2025-03-06_15-31-13.png1942×578 77.5 KB

When you say “with such an old version of LW”, are you referring to the Heltec Cube Cell board environment or the 1.0.2 version of the actual hardware?

If the former, I thought I was using the latest version? Where are you seeing the LW version in the uplink message?

#8

The LW implementation that comes with the CubeCell is a bit dated now so the LW LNS has a lot of making up to do to keep things sane.

Your RSSI is way too high - LoRa = Long Range - too close and the receiver circuits become overloaded and can’t hear properly.

You are breaching TTN FUP by a ginormous margin so YMMV and if you are in any EU country, breaking the law plus LW can’t actually keep up with such a send frequency - it needs at least 7 seconds to send and then do the Rx delays. LW is designed for battery powered sensors uplinking somewhere between 15 minutes and 3 hours and the TTN community like to keep their servers free.

#9

FUP noted but this is not a deployed node, just a test node with a push button and I was repeatedly pushing it to generate some traffic for the screenshot :slight_smile:

Yes, much too close to gateway but once again, it’s just for development

I am really just testing the end to end path from node->gateway->TTN-> Mosquitto MQTT client/ MQTTNet based custom client

Would value any suggestions for small form factor nodes capable of low power/ sleep mode like the CubeCell but more up to date?

Many thanks for your help

#10

More issues…

I wrote a simple Windows C# client using the MQTTnet framework

Uplink messages from my test device were being received fine so I decided to publish a downlink message

I did not intend for it to be a confirmed message but I fear it was

The result is I now get an “received unconfirmed downlink” message in the Serial Monitor every time I send an uplink

This downlink message DOES NOT appear in the TTN portal

Does this sound lik this could be related to issue discussed on other threads whereby an unconfirmed downlink causes TTN to resend the donlink message after every uplink?

I have tried resarting the device but it still happens.

Any suggestions on how to analyse the unexpected downlink to determine its origin?

[NOTE: I know I have not supplied any screenshots or message dumps, but that’s because I am not sure what would be useful at this point…]

Thanks

#11

Congratulations, you are only the second person ever that I’ve interacted with to achieve this continuous loop.

There are no LNS generated confirmed downlinks. They can only come from user requests. And this is exactly why older versions of LW suck because if they sort-of support a feature set but don’t quite, they fail to process the downlink as expected and don’t send back the ack …

You can’t replace this downlink as it’s no longer in the queue - it’s buried deep inside a server in the Hive below Raccoon City and the Red Queen will do everything she can to get that Ack.

You can either delete the device & re-provision it. Or use the CLI to reset the MAC state.

#12

Bit hard to say without knowing the use case - what sensors, likely uplink period, size, power, indoor or outdoor etc etc

#13

OK thanks. It’s always reassuring to achieve notoriety :slight_smile:

Just to confirm, this loop was caused by my Windows client sending the downlink?

If so, would it have been a flagged as requiring confirmation at an application level or is this MAC level behaviour that I have no control over? I am asking in terms of trying to make sure I don’t do it again

Sounds like I need to prioritise finding a node wwith a newer LW implementation

Many thanks

#14

Yes

Yes

No:

The LNS will generate downlinks to bring the device settings in to line and expects some ack flags back in the next uplink - even if that’s in 10 days time.

#15

Many thanks, I will try CLI or else removing/ re-adding the device

#16

I am having problems running the CLI command. [I have never used this utility before BTW]

Here’s what I did:
Downloaded ttn-lw-cli utility for Windows
Opened a CMD window
Ran: ttn-lw-cli.exe use eu1.cloud.thethings.network
Ran: ttn-lw-cli login --api-key API_KEY_HERE
Ran: ttn-lw-cli dev set woodside my-test-device --unset mac-state.pending-application-downlink

I got this response:
INFO Telemetry is enabled. Check the documentation for more information on what is collected and how to disable it {“documentation_url”: “https://www.thethingsindustries.com/docs/reference/telemetry/cli”}
WARN [dns]dns: TXT record v=spf1 -all missing grpc_config= attribute
error:pkg/auth:token (invalid token)
correlation_id=02e780cc3f6c412bbc1716e7bdb569bc

What am I doing wrong?

Thanks

#17

In the end I removed and readded the device

Thanks

#18

You don’t use an API key here - just login, it opens a browser window, you login, it catches the credentials, done.

Where did you read to use an API key?

Not having the CLI to hand is like not having your highly tuned scalpel available to sort out intractable issues.