I am running Chirpstack V 3.14 on a hosted server (Debian).
The server started off with LoRaServer but this was removed and Chirpstack installed when it was released.
The server has been running reliably but we have recently hit a problem.
We use devices on AU915, in ABP mode and always run withADR off and Acknowledged Packets (in effort to get a continuous data set from our devices which are sending long packets every 15 minutes)
- the Device Profile has been set to match the settings of teh LoRa WAN units: version 1.02 of the LoRa WAN stack and Regional Paramaters Version A
- at the start of a transmission cycle, the devices send a Link Check packet. If this is acknowledged, they start sending the sensor readings.
We set up a batch of devices on Chirpstack some time ago and they all ran fine with Acknowledged Packets. This would have been with an earlier version of the server (but I am not sure which version it was at the time)
Recently, we have added some new devices but they are not working in Acknowledge mode.
If we change the Node to Unacknowledged mode, they work fine.
So the device address, EUI, NwkSKey and AppSKey are all OK, otherwise the Server . But for some reason the downlink packet is being missed.
To make sure I had a proper handle on this, I took one of the new devices and loaded it with the config from one of the old devices (I downloaded the working config from the old device and loaded it to the new one):
- the new device (B) works fine when I load it with the credentials for a devce which was created when Chirpstack was at the earlier version
- the new device (B) does not work with a configuration created under Chirpstack Version 3.14
- if I load device (A) with the new configuration, it too stops working
My conclusion from this is that there is nothing wrong with the hardware.
But configurations created after the Chirpstack upgrade will not work in Acknowledged mode.
I suspect that something has changed with the settings for the downlink packets: either frequency, data rate or delay:
- we can see the Link Check packet go out and a reply come back. But the Node is missing the reply.
Maybe the devices created under the previous Chirpstack build may have an empty or null parameter for one of the settings; wherease new devices may have a value set which is causing the issue.
So my question from this is, does anyone have any idea on where next to look? Answering this may entail some additional knowledge on how the Device configurations are stored and from that a line by line comparison to see if there is a difference between the old and new.
Any help or thoughts would be appreciated.