Hi, I’m having trouble trying to send a downlink packet to a Class A sensor using the Web UI and wondering if I’ve overlooked something simple. I can successfully send the packet to the sensor (as it acks on the next uplink) but the sensor ignores the packet.
I want to send the hex payload ‘FF037800’ on port 85. I Base64 encode it (using https://cryptii.com/pipes/base64-to-hex) to get the string ‘/wN4AA==’, then hit ‘Enqueue Payload’.
On the next uplink, the packet is sent to the sensor and the sensor acks it on the following uplink. However the sensor appears to ignore the payload. I’m using an off the shelf sensor so cannot look at any logs on it to determine what the sensor is doing.
Am I missing something here as I thought this would have worked?
That looks correct, and the device ack indicates that the device received the confirmed downlink. Does the device send any uplink to confirm change of configuration?
Could this be an Ursalink device? If that’s the case, FF037800 will set the report interval to 512 minutes. If you want 2 minutes, use FF030078. If you want 2 hours (120 minutes), use FF031C20.
Thanks for your responses @bconway and @mfalkvidd. I managed to successfully send the downlink in the end, but I had to disable ADR on the device to get it to work.
For some reason ChirpStack was sending ‘LinkADRReq’ packet to the device every time the device transmits a packet on the uplink. This interferes with the downlink request and the device ends up ignoring the downlink request. I’m not sure why the ‘LinkADRReq’ packet was being continuously sent, but disabling ADR on the device stopped that from happening.
BTW I found the device was not actually acknowledging the downlink packet when I thought it initially was. Even though an ‘ack’ packet was shown in the Device Data stream, when I looked closer the ‘acknowledged’ flag was set to false. Once it started working properly the ‘acknowledged’ flag was set to true.
If you have a Class-C device make sure that when you create a “device-profile” in Chirpstack, under the “CLASS-C” set field *"Class-C confirmed downlink timeout " to 10. I always got acknowledge false if had it set to 0.
This is because gateway needs to wait a bit in order for acknowledge to arrive.
I think this depends on your device firmware. In this case, ChirpStack will expect an ACK within 10 and if not, it will assume a nACK. If it is expected that the device responds within 60 seconds, then you should set it to 60 etc…
