Hi all.
I’m experiencing troubles with downlink communication.
What I do is grab the spec of my devices, find the downlink payload description, build the payload frame, encode it from bytes into base64 (with e.g. https://cryptii.com/pipes/base64-to-hex) then use the “Enqueue downlink payload” section in ChirpStack. The port is not always easy to find in the docs.
I managed to achieve successful downlink communication with a device, but I’m still struggling with other device types, so I’m thinking I must be missing something.
For example, we have ARF8200AA ANALOG PWR LoRaWAN® EU863-870 devices.
The spec can be found at https://www.adeunis.com/wp-content/uploads/2017/08/User_Guide_ANALOG_PWR_LoRaWAN_EU863-870_V2.0.2.pdf
Page 52 reads
Applicative port (downlink) 1
I’m assuming that’s the fPort I must enter in the enqueue downlink payload menu.
Page 75 describes the payload for a “Frame for updating the value of specific registers” (0x41)
Here’s my payload
0x41 - Type = Update frame
0x06 - CONF ID 1 = 300 + 6 = 306 (change mode)
0x02 - Set to mode 2 (test mode)
Encrypted in base64, that’s “QQYC”.
So I send QQYC on port 1.
I check “Confirmed downlink” and enqueue payload.
I wait until the next uplink for the message to be sent and in the device data tab, I get an “ack” message. The payload reads:
* applicationID:"2"
* applicationName:"MyApp"
* deviceName:"ARF8200AA_int"
* devEUI:"xxxxxxxxxxxxxxxxxxxxx"
* acknowledged:false
* fCnt:42
* tags: {} 0 keys
I can confirm the device config is not changed because the uplink rate would have changed.
I suppose “acknowledged:false” in the ack payload means the message was not understood by the device.
I’m clueless about what to do to get this to work.
Hopefully, someone will pick an error in the procedure I describe above.
Or maybe anyone can give me a hint about what to investigate.
Having issues with a device, I contacted the support, but I’m still waiting. Since I have the same symptoms with two different devices from different makers, I’m thinking maybe I’m doing it wrong.