I have nodes with custom firmware (CubeWL/LoRa-Node based) connected to Helium network.
OTAA works fine, but downlinks are sent with a 2s RX1 delay (shown in the downlink payload, see screenshot below), even though the regional settings show a 1s RX1 delay.
So, the devices receive the downlinks in the RX2 window most of the times, but unreliably - but as I understood that should be more of a fallback.
I registered one device with TTN and there are no problems, downlinks received in RX1 and very stable.
So, my questions are:
Is this spec-conform behavior from the LNS? Is the problem my LoRaWAN stack which does not adapt to the RX1 adjustment (I have not modified a thing in the stack though)?
When I try to modify RX delays manually by LmHandlerSetRx1/2Delay to 2/3s, downlinks are not received at all anymore. Why could that be?
I cannot change the RX delay myself with my LNS. Where does the increase come from?
Looking at the frequency in your screenshot, ChirpStack is scheduling the downlink in RX2. In the default config, ChirpStack first tries to schedule the downlink using RX1, failing that RX2. This means that probably the downlink using RX1 parameters got rejected by the gateway / Helium. If this is consistent, then this is probably caused by network latency (the gateway rejected the downlink because it arrived too late).
Ok, that could be an explanation, thanks!
So that would mean this is an issue with the LNS and I should try to find a provider with less latency?
Strange that this happened with both providers I have tried so far (helium-iot.xyz and iot-wireless.com).
Is there a possiblity to check the logs on a hosted LNS?
Nope, you can just increase the rx1_delay value in the ChirpStack configuration. E.g. rx1_delay=3 instead of rx1_delay=1. Devices will automatically receive the config update through mac-commands or as part of the join-accept payload.
