Uplink shows "Payload Not Provided" after giving downlink from the TTN to node

Hi all,
I’m currently working with dragino Lora shield which is sending the data to TTN. While I’m giving downlink after the ack received the very next uplink is not getting properly that is it is showing “Payload Not Provided”. For every downlink, I’m getting this issue.

Can anyone help me out from this issue???


A few observations, assuming your Application Data shows the data for a single node:

  • The 10:54:41 uplink that shows “Payload: [not provided]” uses port number 0, which should only be used for uplinks that have no application payload. So:

    • If the node did include an application payload then it specified an invalid port.

    • If it indeed did not provide a payload but only sent some MAC commands, then what you see in TTN Console is simply correct. (Though one might argue that TTN should not invoke your payload function when there’s no payload, and/or when port 0 is used.)

  • The earlier 10:54:32 ACK (green icon) does not show a value for the frame counter, but it should be higher than the last used value of 8, so: 9. (At least for LoRaWAN 1.0.2 which is what TTN supports; I did not check for other versions.) This is indicated by {Cu+1} which denotes “uplink counter plus 1” in the following diagram:

    Downlink ACK

  • The above implies that the 10:54:41 uplink should have used counter 10, not 9. I feel that TTN should have rejected this re-use of an old counter value. Did you by any chance disable the security frame counter checks?

So: look into the full LoRaWAN packets in the gateway’s Traffic in TTN Console (if you have access to that) to see what’s received exactly, especially as for the frame counter, the port, and whether or not some application payload was included. An online converter might help (this needs the full LoRaWAN packet as seen on the gateway’s log or Traffic page), or copy/paste the text (no screenshot) of the full packets here.

And one more observation, unrelated to your problem: the hardcoded value 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 is text, and decodes to “Hello, world”. (And whatever your Decoder in the payload functions is doing, does not match that payload.)

Don’t send text.

Yeah! Thanks for your reply. Now i understood the down-link process when it is acknowledged (Green icon). So when i didn’t give confirmed for my down-link, i’m able to receive the uplink data without any issue!

Yes! Actually for testing purpose i have send the basic data as “hello world”.
Thanks for your reply!

Nice, though it sounds like a workaround. Of course, if you do not need a confirmation then you should not request it. But: it should work. It might help future readers to know if TTN Console matches the actual LoRaWAN packets that were received, and to know if you disabled the frame counter check security. There’s always the chance that TTN Console somehow messed up after receiving the confirmation.