We’ve set up a configuration with the full ChirpStack package (no ChirpStack Gateway bridge on the Conduit) on a server, and are using a number of Multitech Conduits as gateways to communicate with the ChirpStack server. The Conduits are using mobile data connections (cellular links) for internet connection.
We’ve set up the conduits using the AEP interface, enabling the built-in port forwarder and opening the firewall for incoming connections. As I said, this works fine for uplink connections, for join accepts and for a few of the downlink connections.
The system (nodes and server) are configured to use ADR.
The uplink communication is always working (or at least very close to always), there are no issues in joining the network and sending data always works. However, there are major difficulties with the downlink connections (except the join accept mentionned above).
I suspect that this could be caused by latency in the GW or in the mobile connection, it would be good to get some suggestions on how to address this…
Here are some behaviors that we’ve seen this far:
Join works every time, we the join accept is acknowledged by the nodes.
Adding downlink packages to the ChirpStack server logs the downlink packages in ChirpStack, but very few of these packages are received by the node.
When setting the nodes to request ACK for all packages, most of the ACKs are missing but a few are received. I can see in ChirpStack that the node has requested a Confirmed Package and that there is a response.
ADR configurations works about as often as the ACK/downlink message. At startup packets are sent using SF12 but sometimes SF7 is used after a few connections. For test purposes, the Gateway within a couple of meters from the node.
The nodes are based on the Multitech xDot and I’ve also tried connecting the xDot in AT-command mode from a PC, with similar results.
Any ideas? Is a mLinux conversion of the gateway + installation of the Gateway Bridge on the gateway a likely solution?
Any suggesteions or tips would be greatly appreciated!
I can’t speak to your downlink issue, but we run Gateway Bridge on the AEP version without issue (including successful downlinks). MultiTech recommends not using the mLinux build unless you are planning on also building your own connection manager and other tooling that is included with the AEP version.
Thank you for the feedback. I’ve installed the Gateway Bridge on one of the gateways and I got it to work. The funny part is that some of our gateways are showing statistics in ChirpStack, where as the one I tested on did not report any statistics until after I installed the Gateway Bridge…
After setting up the Gateway Bridge (and setting the keepalive_interval to 1) it feels as if more downlinks/ACKs are being sent. This is an improvement, but it’s still not a stable solution… Maybe the gateway is too old (it’s a MTCDT-H5-210A), though I have the latest AEP version installed on it (v5.1.2).
I’ve been experimenting with the link check functionality and have it set to the default count = 3 and threshold = 5. It seems as the xDot decides that the connection has been lost every 15 transmissions, which (to me) seems like it’s not getting the response from the server. I think this is what also causes ADR to work sporadically.
Maybe the next step should be to try with a newer gateway…
OK, just to provide some more information, in case someone has similar issues.
I tried with a newer Conduit, with a new Lora card and ethernet connection. That proved to be working perfectly, regardless of if the gateway-bridge was used or not. Next I disconnected the cellular connection on the older Conduit and configured it for an ethernet connection, and now everything seems to be working as expected.
I guess it’s safe to assume that the cellular connection is to blame for this issue. My next question is if anyone knows of anything that can help improve the conditions? Maybe switching mobile operator?
The device opens the JoinAccept RX window 5sec after transmitting the JoinRequest. This leaves 5 sec for the complete back & forth exchnage between gateway and NS over cellular.
However normal downlinks RX window may be 1 & 2sec after uplink (this would be the default value).
It is possible to chnage that latency setting but i believe the current NS version does not allow this. This is something to check with Orne and it would be a valluable feature…