I am encountering an issue on downlink messages.
My first installation was on Google Cloud, and thought that this issue may be due to a misconfig, and decided to put everything in one box, but the issue still persists.
I realized there was an issue when no downlink messages was displayed when looking at data and frames in the web app console, and also that my gateway was constantly sending the downlink message after my device sent an uplink, even if it was unconfirmed.
In other words, Chirpstack stack is believeing that sending the downlink message failed, constantly retries as it keeps it in the queue, and on each try the gateway is actually sending the message through the air.
After analyzing Semtech UDP datagrams, My LoRaWAN gateway is apparently dealing with v1 (byte 0). In v1, the gateway doesn’t acknoweldge (TX_ACK) it accepted the (PULL_RESP) downlink message for transmission.
Also I see that Chirpstack sends v1 Semtech datagrams to my gateway, which is correct.
So I suspect that a Chirpstack component, probably the network server, is waiting for this ack to define the downlink message has been accepted by the gateway, stops retrying, and displays it in the console.
Uplink messages are handled properly.
Logs will follow this message as I don’t have access to my test env yet, but if anybody has an idea on why this is behaving like this, it is very welcome.
The ChirpStack Network Server does not wait for an ACK or nACK. It stores the downlink(s) (e.g. RX1 / RX2) in Redis and when there is an ACK, it is logged. If there is a nACK, it will retry with the second downlink option (e.g. RX2).
When the gateway does not send any ACK / nACK, then the downlink is probably sent if everything was configured correctly, but this is only an assumption.
Any reason not to update the Packet Forwarder on your gateway?
I made some deeper investigations and found the issue. There are two actually.
First I will answer your question about upgrading the packet_forwarder: there is none, it is a custom implentation of Smtech protocol: https://github.com/things4u/ESP-1ch-Gateway
I am trying to make this single channel gateway work and finally succeeded, here are some hints:
Downlink packets are send over the air, but are not displayed and logs show and TX ACK coming from the gateway are not recognized:
I figured out that the gateway uses V1 packets. It is threfore not supposed to send ACKs, I believe. I made some changes to the code, for it to be V2, and now the downlink are diplayed and no errors in the logs.
Seond issue about downlinks constantly being sent after an uplink: I found out that these were MAC commands sent by Chirpstack, and it appears the device I use doesn’t want to process them. I need to dig further.
Hi @brocaar , is this a strict assumption made by the network server? I am seeing a situtation where it appears as if the network server is not incrementing the FCntDown when it doesn’t recieve the txack for the gateway. I need to do more investigation but this is my working hypothesis after a few days of debugging.
As to why not switch to v2 protocol?: Some older hardware doesn’t seems to support it.
The TX_ACK is required as only then ChirpStack knows that the downlink has been (or will be) transmitted by the gateway. In this case the downlink application payload is not removed from the queue in case the gateway could not transmit the downlink. Without the TX_ACK from the gateway, this would not be possible.
Yes, initially ChirpStack (by then LoRa Server) was doing a “fire and forget”. Quite a while ago (more that a year ago at least), this was improved to be more reliable.
Sorry to revive this topic, but in my case I can Hardly upgrade old gateway with Semtech Packet
I Was using a really old ‘loraserver’ and try to migrate to chirpstack 4.0 dockerized server. got some problems due to API changes but it was running well for the Uplink part. However I cannot make it work the DL part (mainly class-C) because of this TX_ACK that is not implemented in Semtech packet fowarder V1.
I have in mind a few ‘really dirty’ patches that can be used but before implementing one :
Is there a way to force server to use packet-fowarder protocol V1? Or it is really incompatible now?
No such option exists. What you could do is build a script which subscribes to the downlink MQTT topic and sends an ack for each downlink. That would be the easiest to work around this.
May I ask which gateway you are using and why it is not possible to upgrade the packet-forwarder?
Hi,
Your suggestion is cleaner than the solutions I have in mind.
The gateway is not managed under Linux environment and is used with an embeeded private LoraServer with specific features developped internally (could give some info in PM). Having some in spare, I was using it for some product testing and have made testsuite tools to use it through the old ‘loraserver’.