Hi everyone, what is wrong with this downlink I’ve sent?
Thank you,
Paolo
I don’t see anything wrong. Do you mean to ask why you sent a confirmed downlinks and it was not acknowledged?
Did you try more than once? Other than LoRaWAN frames possibly getting lost, the device can only receive messages during uplinks. If there is substantial latency for whatever reason, the downlink window could be missed. But all these could be temporary, which is why I suggest trying again.
Somehow, the TxAck seemed to have come quite late. Have you checked the TxAck for the outcome of the transmission?
Device, that is a Browan object locator device tracker, it update in stationary mode every 2 minutes, so I tried to increase this time interval. I did 3 downlink times but I didn’t get any change in frequency update time interval. One more information is that during this test device is close to a gateway ( only 5 meters).I’m not able to increase distance for a while.
Woukd you mean that acknoledged = false doesn’t mean anything wrong?
About txack, you say to check better his results, what shoud I looking for in his data?
I attached the command downlink as for reference manual:
What I did was to translate hex 01201C in base64, on port 204 for confirmed downlink as written in the manual and then publish the mqtt …command/down topic. Same I did for the chirpstack UI and after the first uplink I see the ack and after some minutes I see the txack.
Below Txack is how it’s looks like:
Thank you,
Paolo
“Ack” is meant to contain the outcome of the confirmed downlink. The screenshot of the contents of the “Ack” message, indicates that the device did not acknowledge a confirmed downlink. There is an uplink after TxAck. Since the Ack event indicates that the confirmed downlink was not acknowledged, it implies that the device did not receive the downlink.
From what you described, it does sound like you are doing it correctly. But something is not working as expected.
If the device is class A, it means that the transmission needs to take place 1s after an uplink. But in your screenshot, the “TxAck” appears 3s after the uplink. Now to think about it, perhaps Chirpstack had sent MAC commands before the downlink was sent, which were responded to by the device. Thus you wouldn’t see the downlink and the subsequent uplink, which would have triggered the ability to send thay downlink at 02:31.57.
“TxAck” may optionally contain an error, if the message could not be transmitted, but your later screenshot doss not show such a thing.
I feel that you should also study the LoRaWAN Frames window, not events. The Events list can only show you data that is relevant to the application, but this will exclude messages that contain only MAC commands. Those missing messages would help explain why the downlinks were sent at those times.
1 Like
I did a downlink again.
Some pictures:
I don’t know if I’m wrong, now it looks like up and txack don’t have 3 secs delay.
Thank you
It appears that you asked about this before, but there was no solution: Downlink is not working
On TheThingsNetwork forums, something similar happened. I guess, it’s you again.
Actually, is it possible that the documentation is wrong or doesn’t work with this device model?
Have you actually tried sending an unconfirmed downlink (don’t check the “confirmed” checkbox)?
Probably is the device, it doen’t have NFC or Bluetooth for easy setup.
With temperature umidity sensors and door sensors we have is very easy, we approach smartphone to the device and we can make changed in it ( I moved easily update temperature from 30 minutes to 2 hours for example). We think to have only NFC o Bluetooth friendly setup devices, so no need to send downlink
Downlinks are a part of LoRaWAN. I think the problem is with this device and/or the documentation you got. You should follow up with the vendor for help.
I suppose it was made to be low-cost and simplicity. Every bit of extra hardware, increases the cost and worsens battery lifespan.
I believe your device can receive downlinks because it could join the network, unless it is an ABP-mode device. So it may be an issue with the documentation for the downlink command.
1 Like
Thank you for your kindness
Paolo
Hi Li Woon Yung,
I want let you know that thanks to your suggestions and Browan people support I found the solution. Documentation was not clear, solution was an uncorfirmed downlink to the port suggested by them with a full exadecimal command as they suggested.
It worked as expected
Thank you again
1 Like