The MatchX gateway is tested with Brocaar’s server, Peter’s server, and additionally also big operators such as Loriot. Recently there have been concerning reports about the delay of the downlink message on some 3rd parties network, which results in the failure of the downlink. We would now like to provide factual evidence as to why this is occurring:
LoraWAN uplink and downlink flow
Usually, a server will respond immediately for the downlink, to multiple gateways that communicate with the sensor. In this case, the problem is on the gateway side, where the red circle is.
However, sometimes a gateway has long network delay, or internal delay, which will schedule the LoRa packet later, this means that the Gateway can no longer compete with the other gateways for the downlink. As a result the downlink is generally not sent with these long latency, slow gateways.
What can you do to resolve the long latency / slow gateway to “sent”?
Brilliant idea at the server-side, to delay the downlink
External organisations can delay the downlink in a way that the slow gateways can also receive the message? It’s unfathomable that this would be happening, however, in this case, it is exactly what is happening. In addition, it can result in blocking MatchX and, or some other brands gateways from sending any downlink.
You can, of course, continue working with external partners who change their system (at their users peril), however, MatchX LPWAN cloud will always be free to all the users, we promise, and we won’t delay the downlink to take care of the slow gateways, we support LORA and the LORA community, the downlink should always be chosen with the fastest gateway!