LoRaWan receive window for downlink is mandatory for node ?
-
LoRaWan receive window for downlink is mandatory for node ?
So if my LoPy spends 3s starting, reading sensors, setting up LoRaWan, sending the payload with LoRaWan. Can I enter deep sleep after that if I don't want to receive downlink messages ?
Or may I wait for N seconds after TX before deep sleep so to have 1s before 1st RX window and 2s before 2nd RX window ? What about the RX window duration ? For LoRaWan US915 it seems it is limited to 400ms, and for LoRaWan EU868 is up to 3s, right ?
IMHO, the LoRaWan definition for class A devices is not explicit about receive window for downlink being mandatory or not.
-
@jcaron said in LoRaWan receive window for downlink is mandatory for node ?:
@bmarkus At least in the EU region, RX2 on the standard frequency has the advantage that it allows for a much higher use (10% duty cycle vs 1% in most other bands), and much higher power (if the gateway allows it). Depending on your data rate mix, you might be better off in RX2 than on RX1
RX2 is using a single channel with low data rate. It is obvious, that RX1 using 8 channels and various data rates, specially set automatically by the ADR algorithm offers much higher througput than RX2. Why to demage network performance if not necesary?
It could be even better if the gateways allow higher transmit powers and you can use faster data rates than the default on RX2.
Not sure I see the link between RX2 and 3G backhaul, unless you mean you need the additional time, but one could set RxDelay to a higher value for that (though that is definitely not a good thing for battery life) rather than pick one window over the other.
3G connections typically offering longer latency than 1s which makes RX1 unusable, and usually changing rapidly even going up to 3-5s.
In a production environment it is not a good practice to change RX1 timing anyhow.
-
@bmarkus At least in the EU region, RX2 on the standard frequency has the advantage that it allows for a much higher use (10% duty cycle vs 1% in most other bands), and much higher power (if the gateway allows it). Depending on your data rate mix, you might be better off in RX2 than on RX1. It could be even better if the gateways allow higher transmit powers and you can use faster data rates than the default on RX2.
Not sure I see the link between RX2 and 3G backhaul, unless you mean you need the additional time, but one could set RxDelay to a higher value for that (though that is definitely not a good thing for battery life) rather than pick one window over the other.
-
@rcolistete said in LoRaWan receive window for downlink is mandatory for node ?:
Thanks for all the answers.
@bmarkus, what about if it is used a LoPy nano gateway, so frequency, SF, BW and possibly CR are fixed ?
In this situation, without any planned downlink activity, it would be acceptable to enter into deep sleep after sending a LoRaWan packet ?As I wrote, it is not about GW but Network Server.
-
Thanks for all the answers.
@bmarkus, what about if it is used a LoPy nano gateway, so frequency, SF, BW and possibly CR are fixed ?
In this situation, without any planned downlink activity, it would be acceptable to enter into deep sleep after sending a LoRaWan packet ?
-
@robert-hh said in LoRaWan receive window for downlink is mandatory for node ?:
@rcolistete If you do not expect a downlink message, then you can set your device to sleep again immediately.
It is not so simple. Network server my send MAC commands like ADR adjustments, requests Batterylevel/DevSNR where device responds, etc. If you block them you are killing your network.
I do not know details of the LoRaWAN stack, but as far as I know it is running on a different CPU core than user applications and it is not necessarily true that going to deep sleeps also stops LoRaWAN stack immediately without finishing tasks. It must be confirmed by PyCom
-
@jcaron said in LoRaWan receive window for downlink is mandatory for node ?:
In the EU region I believe many if not most networks use only RX2
Which networks are you referring? To use RX2 only is a terribly bad practice, it kills network performance, device energy management, etc. RX2 is only for special cases, like GW with 3G connection. Use always RX1 and RX2 only ins special cases as exception. BTW, there are certain network servers can select RX1/RX2 automatically.
-
@rcolistete In oder to combine @jcaron and my comments:
after sending (issue socket.send()) you must wait for the message being sent. That may take a while, depending on the data rate and the message size.
At DR5, the send time is 1.4 ms per byte. You have to add 13 bytes for the message header, 8 bytes for the lead-in. A typical airtime for a 10 bytes messag is 50-60ms at DR5. And the xxPy devices need at least 6 ms for setting up the sending. So so not switch off to early.
In the TTN network, the RX1 window is set to 5 seconds for OTAA response and 1 second for other messages, including confirmations. As far as I understand, the gateway can decide to deliver a message in the RX2 window if it missed the RX1 window. But that is to be assessed.
Edit: Reading a little bit further in the LoRa spec and TTN comments:- TTN tells to avoid the RX2 window, especially sice it does not allow channel balancing
- A network server can send MAC messages in the response window and change the communication parameters, including the message delay times, data rates, channels, etc. Since the transport mechanism is not reliable, these messages have to be acknowledged. Until then, the settings are not agreed upon. Besides that code on a xxPy device cannot tell whether these parameters have been changed. There is no interface in the module.
-
@rcolistete If you do not expect a downlink message, then you can set your device to sleep again immediately. Normally, downlink messages are not sent, except the the OTAA join response. They are only sent for confirmed uplink messages or if it is requested so by the protocol you define. In any case, messages either way are not guaranteed to arrive.
TTN limits the number of downlink messages at 10 per 24 hours, including confirms. This is not enforced at the moment, but there is a limit.
The RX1 window duration of Pycom devices is set to 20 ms (target time +/- 10 ms). I never have observed a device receiving in the second window, but I did not look for that deliberately. The nanogateway example does not support that.
-
@rcolistete if you don’t wait for the RX windows then you won’t be able to receive MAC commands sent by the network, which would make the device not LoRaWAN compatible.
In the EU region I believe many if not most networks use only RX2, so you must wait at least RxDelay + 1 to the beginning of RX2, plus a short time to check for an incoming message (that’s definitely not 3 seconds though). If a message is received, you must wait until it is finished, otherwise you can go to sleep at that time.
Note that the default value of RxDelay is 1, but I’ve seen networks which set it to 5 seconds. That’s a lot of time awake for nothing :-(
I think there are things that could be done in the firmware to enter lower current consumption modes during the wait time, but that’s another topic...
