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:
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.)
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.
Hello, I am having the same problem. I am supposed to have datas for every 15 seconds however it keeps shows "payload not provided’ message to port 0 even I am not using that port for uplink messages. I think there is a problem with my end device, it is having ACK and MAC problems with the TTN gateway but I still couldn’ t find the bug on software. The first two messages are being sent correctly but afterwards it keep sends that dummy messages. The duty cycle of my tx is around 15 seconds. Anyone can help?
These are automatic uplink confirmations triggered by unwise choice of “confirmed downlink”. Unless the node stack has other useful data to attach to the ack to, it just sends an otherwise empty packet. And it sends it on port 0, which is reserved for network housekeeping and prohibited for application use.
The answer is really quite simple: send unconfirmed downlinks. Then in your next regular uplink set a bit in your application packet which by private agreement with yourself indicates that a downlink has been received.
datas for every 15 seconds
Please don’t do that; you’ll certainly violate the TTN usage guidelines in short order, and in many places would also violate legal limits.
Keep in mind that the TTN fair usage guidelines limit downlink even more strictly that they limit uplink