Waiting for end-device ack or response

What logic do you recommend I use in my mobile application? I am using street light controllers in class C, but sometimes I do not receive the ACK that the light was actually turned on or off. My logic is to press the button and block it for a while until I receive the ACK, and if it does not arrive after 4 seconds, unlock and try again. Is there anything that can be modified in the TTN configuration?


with rf you have no guarantee on the up or down link working that is just rf

what is the rf environment like

what is the snr rssi sf

have you tried waiting for 6 sec

The RF environment is clean.
SNR = 5.5
RSSI = -102
The ACK sometimes arrive from 3-5 sec, and sometimes I need to downlink payload again to receive uplink ACK

I posted the values, what is your recomendation?

that looks good

how often do you tiger this

Remember also to follow TTN FUP (Search) - max 10 DL per day and should really be thinking 10 per fortnight or 10 per month…

Even with an apparently ‘clean’ RF environment (if just looking at console/log RSSI/SNR values) you may be succeptible to noise and or burst interferers with each SF having specific SNR headroom requirements even when generally effective below noise floor, LoRa is great for resiliance c/w most legacy modulations but isnt fully immune. An SDR looking at your local environment may tell you more. Also remember you are somewhat traffic dependent as GW’s/Devices cant Rx when they Tx so other traffic can cause actions or collisions and as noted may be timing dependent.

How many street light controllers do you have? Are they all actuated at the same time?
If you have many class C devices there is a good chance that they all send the ACK at the same time and disturb each other.

at least 2 times

20 is our approach

how fast with in a few sec less than a min

i have tried less than a min with class c and most of the time it fails

do it every 2-3 min most of the time it works