LoRaWAN OTAA, ABP and LoRa MAC current profiles

[João Rocheteau]

Hello there,
I've been studying the energy consumption of all three of these protocols, and I have a couple of questions about this matter.

For LoRa RAW i've been doing only uplinks to change variables like tx power that I couldn't in LoRAWAN

1. Does LoRa RAW have RX windows just like OTAA and ABP? If so is there any timing I should be aware?

For this last 2 tests i've been capturing the current profile when I do an uplink and downlink, and both are confirmed by The things network that are working fine

1. I've noticed something very interesting: when I was making an uplink and a downlink using ABP, I noticed that I could only see one big RX window, yet, when I made no downlink (only uplink) I could see perfectly both RX windows (smaller too). Why is that? Shouldn't both RX windows appear? Even if it's for a small-time?

When I don't schedule a downlink :

When I schedule is something like the profile below of OTAA

This big RX window can be changed in TTN

1. I have been having problems with OTAA because again, I can only see one big window 5 seconds after TX , is it something I should be worrying about?

Thank you

[João Rocheteau]

@jcaron Hello, thank you for your answer.
About the last picture, these 5 seconds are the "RX1 delay" that happens right after a TX window.
I was thinking it had to be 1 second for OTAA, but in my tests, I found it was 5 seconds (Both uplinks and downlink were verified by TTN), and making a quick search on the internet seems like is the default for it using TTN V3.
I'll try to find a way to reduce it, seems like I have to use the TTN "CLI".
Cheers.

[jcaron]

@João-Rocheteau

RX windows are a LoRaWAN concept. In LoRa, it's up to you to device when you transmit and receive (though I wonder if you actually have control over when the modem is in RX mode in raw LoRa using the Pycom API).

In LoRaWAN, if something is received in the first RX window (RX1), then that's it, there's no RX2. So if the network sends the downlink in RX1, that's it. If there's no downlink or the network sends downlinks in RX2, then the device will listen again in RX2, and then stop listening.

If you care about power, it's usually a very bad idea to increase the RX delay, as this means your device will stay awake longer, and draw more power. Unless you have a very good and specific reason, keep the default 1 second.

It's unclear what your second graph captures. If that's a join request + answer, it's normal, the RX delay for joins is 5 seconds.

Note also for subsequent frames, even if you didn't schedule a downlink, the network can have MAC commands to send, especially after the first few uplinks following a join (sending all the network settings), or of course if you use confirmed packets.