My application's downlink is always queued for next uplink

[roberthulsebos]

I did some testing but never managed to get an application’s response message in one of the node’s receive windows. Instead, it always seems to be queued for the next uplink message…

So, should the following be feasible in the real world?

1. Class A node sends uplink message.
2. Application server, which has subscribed to TTN back end using MQTT, receives uplink message notification and immediately prepares response message.
3. Application server publishes response message to TTN using MQTT within 1 second of uplink message reception notification.
4. Response message is transmitted as downlink message to the node in one of the two receive windows of the uplink message.

[htdvisser (Hylke Visser)]

Yes this is definitely possible, however, step 3 should be done immediately. If the application is not fast enough, the downlink is scheduled for the next opportunity.

[kersing (Jac Kersing)]

How about adjusting the RX1 slot to 2 or 3 seconds to allow for gateways with slower internet connections and allow applications a decent amount of processing time as well?
Allowing to set this on a node by node base to allow for backward compatibility with deployed nodes would be the ultimate solution.
@htdvisser should I create an issue?

[htdvisser (Hylke Visser)]

We are indeed planning to add a 5 (/6) second rx window in addition to the existing 1 (/2) second window.

[roberthulsebos]

That would be nice!

[mahe]

Hi!

I’m wondering if this is still the plan? I’m working on a project, where I would like to be able to send a downlink IF the uplink is something specific (scheduled e.g. by a HTTP request)… Is this considered possible? I read somewhere else, that if the downlink is received later than 100 ms from the uplink, it will be scheduled for the next transmission:

Problems receiving downlinks using the Java API

We do understand that some applications might require sending an immediate reply, so we allow for a short wait time of 100ms. If your application takes 500ms to respond, the downlink will have missed this window, and will be scheduled for the next opportunity.

Is this still the case?

I am quite new to a lot of this, so I don’t know if that makes it impossible to schedule a downlink for an incoming uplink?

Thanks!

[arjanvanb (Arjan)]

If the application is not fast enough, the downlink is scheduled for the next opportunity.

And for future reference, this “next opportunity” refers to the next uplink (not to RX2 when the application is too late for RX1):

Configure Downlink Frequency of a Gateway

The application has a fixed time to respond to uplink messages directly, regardless of the selected RX window. If the application is too slow for that, the response is scheduled for the next opportunity.