UnconfirmedDataDown message

What does it mean this “UnconfirmedDataDown” message? I see that the speed of the transmission slowed significantly with this message.


And this strange:

How do you define “speed”?

In LoRaWAN, uplink and downlink messages can be either confirmed or unconfirmed. Being confirmed means that an acknowledgement is expected from the other side. If there is no acknowledgement, the application on the sender’s end is expected to try again or to take some action on its own.

Confirmed messages should only be used where necessary, as this will involve an additional transmission. Transmissions may possibly also block the receipt of messages, depending on the node/gateway’s capabilities. It also puts an additional message on air, meaning you get another possibility for collision.

Thanks for your reply @sp193,

But as you can see, I send only unconfirmed data to the gateway. So, I don’t expect any messages from the gateway to the end device.

How do I see the data rate?

I have two methods:

  • I can count messages delivered to the gateway,
  • We have the Received/DR chart on the application dashboard; the data rate has a range from 0 (the worst data rate) to 5 (the best data rate).

As you can see in my post, the Received/DR had zero value in this chart.

Messages may be sent by either the node or LNS, to exchange MAC commands. MAC commands will not be propagated to the application, as they are meant to stay within the LoRaWAN layer. Such messages have either no FPort (null) or the FPort is 0.

Having these messages occasionally exchanged is not a problem. If the exchange seems to happen with every single uplink, then it may be an indicator of some compatibility problem.

If you’re on the “LoRaWAN Frames” tab: You can click on the small magnifying class beside the “Unconfirmed” word, to view the details of the message. On the right, a panel displaying a JSON representation of the uplink/downlink message will be shown. The datarate is indicate as part of this.

If you’re on the “Events” tab: the datarate is printed on the row.

The times shown on your screen are weird for the uplink messages, but the order might be correct. I’m guessing that the uplink times come from the LoRa gateway. If it has a GPS that is enabled, does it have a line of sight with the sky?

1 Like

Where is this data rate in this JSON? I see only data ranges (0…5) for each channel:

You’re looking at a downlink, rather than an uplink from the device.

Anyway: in this case, we can interpret the datarate from “modulation”, which has a “lora” block. Here, it is mentioned that the bandwidth is 125000Hz (125KHz) and a spreading factor of 12. This makes it SF12BW125, which is defined as DR0 in EU868.

I still don’t uderstand which role plays this message when I send only UnconfirmedDataUp messages to the gateway.



I have only DR 0 now.

But yesterday I had


Between the LoRa Network Server and the node, MAC commands can be exchanged. These are used by the LNS to manage the device’s state, such as conveying information on operator-defined channels (EU868 only defines 3 channels, everything else is defined by the operator) or for the Adaptive Data Rate (ADR) operation. There are more functions, but I think these two are perhaps the most important and most commonly seen.

Since they can be sent by the node and/or LNS without you making a request, LNS like Chirpstack may log these messages.

In this case, it looks like Chirpstack is trying (possibly even endlessly trying, since the FCntDown is now very big at 540) to inform your device of 3x additional channels: 867.1MHz, 867.3MHz and 867.5MHz. I would say that it’s more natural for channel setup to be done when the device first joins the network, rather than this late.

As for why you’re getting more messages at DR0 at this point, it’s hard to tell without studying the exchange of MAC commands.

The LNS can increase the datarate with ADR, with the LinkADRReq MAC command. On the other side of the coin, the node is allowed to attempt to resolve an inability to receive downlinks (responses) from the LNS under ADR, by reducing the datarate on its own. The node does so in steps, until it either successfully receives a response from the LNS or finally reaches the lowest-possible datarate.


A few minutes after resetting my gateway…

A new up mesage comes after 20 seconds.