and more later, i get other uplink without the warning with a downlink after.
I want to know how much is the time to retry the uplink (At this moments in my lora app is 1 minute, equals to my device send data time)
I want to know why i receive UnconfirmedDataUp and not ConfirmedDataUp, where and how to set it?
There is no such thing as SF 0, so the issue is not where the warning is being generated, but in whatever it giving it a false SF of 0 to try to look up. Trying to find the associated raw uplink MQTT message from a gateway that triggers this would be useful.
and more later, i get other uplink without the warning with a downlink after.
Behavior in LoRaWAN is basically to drop things that are corrupt or nonsensical; there’s little practical difference between this and a packet that gets lost due to interference or range or backhaul network issues.
I want to know how much is the time to retry the uplink (At this moments in my lora app is 1 minute, equals to my device send data time)
That’s up to you and how you chose to utilize your network.
I want to know why i receive UnconfirmedDataUp and not ConfirmedDataUp, where and how to set it?
Your node firmware sets a bit in the header to indicate if it does or does not expect a confirmation response.
The confirmation/retry scheme in LoRaWAN is not particularly well thought out (in particular it badly handles the case where it is the acknowledgement not the initial message which gets lost), for many uses it may be better not to resend old data (and especially not as a resend with the same frame count) but rather to try again with new, fresher data and a new distinct frame count value. Or at least in the case where you are measuring something. You are probably better off doing any strategic confirmation/resend at “application” level than at network (MAC) level.
Also beware that sending downlink confirmations is “expensive” in that a gateway cannot receive from nodes on any of its 8 channels while it is busy transmitting a reply to one of them.
