I am using the MQTT integration to connect my LoRa Application to the App-Server and two questions arose:
Is it possible, from the application, to decide not to ACK a confirmed data up packet?
As far as I can see, I am only able to queue some data for RX. But it’s not possible to piggyback something on the downlink ACK frame that corresponds to a frame i just received on application/rx, right?
So what I want to do is basically:
Send a confirmed Uplink from Device -> Lora(App)Server -> MQTT -> Application
Process the packet in the application
Decide if I want to send an ACK and what data I send with the ACK.
push this data to MQTT -> Lora(App)Server -> Device
Is there a possibility to get this behavior without touching Loraserver or at least without breaking compability to LoRaWAN?
# Get downlink data delay.
# This is the time that LoRa Server waits between forwarding data to the
# application-server and reading data from the queue. A higher value
# means that the application-server has more time to schedule a downlink
# queue item which can be processed within the same uplink/downlink
# Please note that this value has influence on the uplink/downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
This means that it will wait for your app for 100 ms by default to post some valid downlink on device Queue.
The ACK is part of LoRAWAN specs so if you want not to touch it you will have no problems but the payload will join the ack packet if you deliver the data to app server in the configured time. If you are trying to have a faster downlink by using piggyback you should immediately make the device emit an ACK even if the payload is empty, a C++ library such LMIC should be doing this for you.
Hello. Where is this information now on Chirpstack in 2020? I’ve read chirpstack-application-server.toml chirpstack-network-server.toml and chirpstack-gateway-bridge.toml but i haven’t found it. Thank you