When I use OTAA mode, I am always getting downlink data on RX1. Is there any configuration parameter to receive downlink data on a chosen receive window (RX1 or RX2) without switching to ABP mode?
Is this behaviour related to the end-devices or to the loraserver?
Currently this can’t be configured from the user interface. The reason is that I want to improve the LoRa Server scheduling in the future, where it will select either RX1 or RX2 (based on timing, availability of gateways, etc…). So then the RX1 or RX2 selection happens just before transmitting and not as a configuration.
suppose i set RX window manually using my own algorithm. So will it be application specific or device specific? i mean to ask that suppose I set RX2 manually… So will it persist for that device only or for the all the devices under that application?
Huh. So for Class C devices, all downlinks use the RX2 frequency (since there really isn’t an RX2 “slot” for Class C, right)? Do you ever plan to support RX2 for Class C devices? I’m not specifically wanting it, I’m just curious. Can you provide any insight on this decision?
What I mean is that for Class-A devices, LoRa Server currently only uses the RX1 receive-window. My plan is to support a RX1 / RX2 switch or RX2 fallback (when scheduling on RX1 fails, the packet-forwarder sends a nack on error) for Class-A. The challenge here is that RX1 and RX2 have different constraints (e.g. the payload that you can schedule using RX1, might not fit for RX2 because of different data-rate). Also when using RX1 you benefit from frequency hopping where RX2 uses a fixed frequency. But this preference can be made configurable through loraserver.toml.
Class-C devices use the RX2 parameters, so that is why you are able to configure these parameters in the loraserver.toml configuration.
@brocaar I have a type of node that just doesn’t want to join on my network and I suspect it might be the fact that this stack only listens to join accepts in RX2. At least I can see in the server that it transmits a join accept on every join request, and I can see on my spectrum analyzer that the gateway is transmitting the join accept exactly 5 seconds after the uplink. But the node just goes in timeout and keeps resending the join request.
The maker claims his device works perfectly well on KPN and TTN, but as my experience is, these networks use mainly RX2 for joining.
The question I am getting to: do you foresee on reasonable term that some kind of scheduling of subsequent join accepts between RX1 and RX2 is added, just to accommodate the fact that there might be nodes out there with an incomplete stack when it comes to the join process?