As far as I know, according to specification my node send to “unconfirmed data up” packet.
The server probably not send ACK(unconfirmed data down) to my node. But I watch my server why my node setup “unconfirmed data up”, the server can send ACK to me?
If you send a Confirmed Data Up you receive an ACK (the downlink you see) that is tagged as UnconfirmedDataDown Because your device does not have to confirm the ACK.
If you unfold the Downlink you can check what’s inside the downlink packet
Node-------------------------------------------Gateway ----------------------------------------------- Server
|---------(Send unconfirm data up )----------->|-----------(Send unconfirm data up )------------------->|
Server doesn’t send Send “unconfirm data down” to Node.
confirm:
Node-------------------------------------------Gateway ----------------------------------------------- Server
|---------(Send confirm data up )--------------->|-----------(Send confirm data up )------------------>|
|<---------(ACK confirm data down )--------------|<-----------(ACK confirm data down )-----------------|
As far as I understand, the issue of uplink acknowledgement and downlink acknowledgement are separate.
if the node sends an “Unconfirmed Data Up” then this would result in nothing coming down from the server.
If the node sends a “Confirmed Data Up” then an acknowledgement is sent back. In your example the Acknowledgement is an “Unconfirmed Data Down”
As a result of this the node does nothing.
Now let’s examine the scenario if the server had sent its acknowledgement as a “Confirmed Data Down” then the node would be required to acknowledge with a further packet in the Up Direction. This would continue until one or other does not require an acknowledgement.
In your example the Node requested an acknowledgement and the server responded. The server did not require its down packet to be acknowledged. If the node does not receive an acknowledgement (uplink or downlink failure) then it will resend. There is no need for the Server’s message to be acknowledged.
In summary, if you send ConfirmedDataUp, you should at least expect an UnconfirmedDataDown with ack true. I say at least because it could carry some mac commands too.
On the other hand, if you send an UnconfirmedDataUp, you should not expect a corresponding downlink to acknowledge it, but there could be a downlink which piggybacks from your uplink to send mac commands.
Beware that in practice this can work out a little bit differently than intended - because it’s entirely possible that the node fails to hear the network’s ACK, even though the network heard the uplink and advanced the uplink frame counter as a result.
A typical node implementation may then try to retransmit the uplink with the same frame counter. Because the network has already seen that frame count, and already acked it, the retransmission will be ignored - the node can re-transmit as many times as it likes and it will never get an ack because as far as the server is concerned, it already did!
So if you’re going to re-transmit on lack of an ACK, it’s probably preferable to send fresh readings with an incremented frame count number, and not merely re-send the same exact packet, or at least, sharply limit the number of resends before incrementing the frame counter.
(A possible alternate behavior would be to make the server willing to re-ack the most recently seen uplink frame, with the same exact downlink count - but that’s probably only worthwhile if you have an application where getting 100% of a perhaps increasingly stale data set through is more important than getting current data through often enough.
I am using Arduino + LoRa shield as end node and using LMIC library. And dragino as gateway. I am using single channel ABP for uplink. I am receiving Unconfirmed Data Up. Although i turned off ADR from loraserver.toml script. What else should i do to receive correct payload. The lorawan frames that is being received are
With ADR on (turned on in loraserver.toml, and on node with " LMIC_setAdrMode(1);") i’m getting both unconfirmedDataUp, and then unconfirmedDataDown. UnconfirmedDataUp:
I believe my Gateway, and server is running correctly as I don’t see any warnings or errors. I suspect my problems could be on the node, so I am getting info with the following function:
void showInformation() {
Serial.println(“LMIC parameters”);
Serial.println(“netid=”+String(LMIC.netid));
Serial.println(“devaddr=”+String(LMIC.devaddr));
Serial.println(“freq=”+String(LMIC.freq));
Serial.println(“txpow=”+String(LMIC.txpow));
Serial.println(“datarate=”+String(LMIC.datarate));
Serial.println(“rps=”+String(LMIC.rps));
}
Which returns in the serial monitor:
521413: EV_TXCOMPLETE (includes waiting for RX windows)
Rx1 window LMIC parameters
netid=0
devaddr=17961211
freq=923300000
txpow=30
datarate=3
rps=150
“netid=0” does’nt look to good.
Not sure what parts of my server + node are misaligned, any guidance would be amazing.
Thanks.
What about this seems problematic to you? It looks like it’s your first post in this thread so unclear what overall issue you are reporting or why you consider this behavior odd?
The downlink you show is the ADR response containing that information in FOpts, it doesn’t have any payload.