Hello,
I’m using an LPS8 Dragino gateway with firmware lgw-5.4.1601912950.
As a node I use a Heltec Wireless Stick.
For the chirpstack, I’m running it in docker on a raspberry pi using the latest github releases.
The settings used are just the docker-compose default settings.
I have a problem with my setup. I can’t reliably receive downlinks scheduled via MQTT, sometimes they are received, sometimes they aren’t. I can’t really make out a pattern. Downlinks scheduled manually are always received by my node.
All downlinks get txack’ed, so I think they all reach the gateway. In the Live Lora Frames log of the gateway in chirpstack, the packet parameters don’t differ between received and not received downlinks.
My Python MQTT code produces downlinks like this: “{“confirmed”:false,“fPort”:1,“data”:“ZGxfbnIgPSA5”}” (without outer enclosing quotes).
I can’t really share my Python and node code but they are based on paho and mcci lmic respectively. The code seems to work since I can receive every manual downlink and some mqtt downlinks. The Python code for scheduling MQTT downlinks is the same on every downlink, only a variable inside the base64 data part changes.
This is the log from my gateway. The first downlinks were manual and received, then there was one downlink scheduled via MQTT which was not received, then one manual received again and the rest was via MQTT and not received. I added annotations to mark them.
This is an example of a received MQTT scheduled Downlink.
I tried to research the problem but couldn’t find any solution. I’d appreciate any hints or help. Thanks!
Have you tried to push the down command through the api instead.?
1 Like
Hi there, did you check that all your downloads commands are being transmitted ok by the Chirpstack Gateway Bridge?
I suggest you to check the log to be sure that they are transmitted and try to define if the problem might be from the Downlink command or from Dragino gateway.
Have you tried to push the down command through the api instead.?
I haven’t directly. As far as I can tell, the webinterface uses the RESTful API to schedule downlinks. I’ll see if I can modify my Python script to use the API instead of MQTT to check for any changes in behavior. I do need MQTT to work though.
Hi there, did you check that all your downloads commands are being transmitted ok by the Chirpstack Gateway Bridge?
I suggest you to check the log to be sure that they are transmitted and try to define if the problem might be from the Downlink command or from Dragino gateway.
For every downlink, I get a “txack”. If I understand correctly, this should mean the downlink did reach the gateway. I’m not sure if that’s what you mean, if I misunderstood you, could you please elaborate?
When sending a downlink via gRPC from python, I get the same behavior as as seen over MQTT. The downlinks get txack’ed but I don’t get them on my node. In the frame logs, the received and lost downlinks look identical. Are there any timing things I need to deal with in my python code? I just schedule a downlink as soon as an uplink is published via MQTT.
Downlinks enqued by hand via JSON API are also seem to be reliably delivered, just the programmically sent ones are unreliable.
Here is a screenshot from the node lorawan frames, fCnt 10 was received, 11 wasn’t.
Dragino LPS8 uses a packet-forwarded LoRa transmission, so the Chirpstack Gateway Bridge receives the UDP message, transform it and publish a MQTT message in a topic.
Network-server and Application-Server uses this MQTT message to process it and show it, for instance, in the WebUI.
You are making the other way round, publish a message, the Chirpstack Gateway Bridge gets it and sends it to the Dragino Gateway.
When it sends it, it writes a log in syslog file or other if specified, even in a debug mode if configured on Chirpstack Gateway Bridge config file.
So what I suggest you to do is to check this log, in order to see if Chirpstack Gateway Bridge sends the message when you send the command from python.
This might have been a problem related to high sending frequency in testing, not setting the data rate for ADR properly and just (bad) luck since all the manual downlinks were received for some reason. I changed the maximum allowed data rate to 7. Still not all downlinks are received, but now at least the majority of them is.
Thank you very much for your suggestions.
Not sure what’s going on on my side, I’m queueing a downlink, and getting a fCnt, but not seeing any txack or error for it on the device events (via the API) sometimes. It seems to downlink got processed without notifying me. Running on app 3.10.
It could be a race condition?
This is likely caused by https://github.com/brocaar/chirpstack-application-server/pull/577, it will be included in the next release 
1 Like
If that was for me, thanks I’ll look forward to the new version so see if it helps. I was using mosquitto 1.6.9 though (on our production environment).
