I’m using the latest RAK4631 LoRaWAN Deep Sleep demo with v2.0.0 Sx126x-Arduino LoraWAN library and have noticed that instead of 2 Rx windows 1 second after the uplink I get one long 4 second Rx window.
as compared to an elsys EMS LoRaWAN sensor on the same Chirpstack network server through the same gateway which clearly shows 2 rx windows (won’t let me post the picture!).
My region is EU868, ADR is off, I’m on SF7.
Is there a setting I’ve missed or is this a bug/omission?
I’d like to get the 2 rx windows in order to save a little more power.
It is a problem inside the SX126x-Arduino library. The RX stays active from beginning of RX1 to the end of RX2.
It is a known problem and we are working on a solution.
I have some issue with RX2 and I think it’s linked : I can’t join a french operator (Live object) because Join Accept is never received. I checked everything and for it’s because of bad freq or SF. So is it possible that RX1 windows, staying active means that RX2 window is not activated ?
PS : with TTN it works like a charm, but as I understand it, TTN sends on both RX1 and RX2 join accept packet.
It is not that RX2 window is not activated. The behavior of the library is that RX1 and RX2 windows are connected and the transceiver is listening from beginning of RX1 to the end of RX2.
This behavior is not easy to change and it does not limit the functionality, it only has an influence on the power consumption.
I looked into Orange Live Object, because I wanted to run a test.
But it is not clear how I would connect my gateway to their LoRaWAN server. Can Live Object only be used with Orange owned gateways?
Yes Orange is the historic telephone operator in France. They just created their own LoRa offer, so you have to buy subscriptions to access their LoRaWAN network.
Yes I got your behaviour, but are we sure that RX2 window parameters (freq, SF …) are applied ? I tell that because the first jeflofts’s current analysis is very flat, like nothing is changed.
We tested the library against all LoRaWAN regions and with TTN V3, Chirpstack and ResIoT (myself) network servers and there was no problem with the RX2 window parameters. Is there a way to find out what Orange is using for the RX2 window? Are they different from the EU868 definitions in the LoRaWAN specifications? The latest I have (RP-2-1.0.3) says: The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz)
When I create an object in Liveobject’s platform, I can specify a profil (typically SF9RX2 or SF12RX2) and I tested a lot of them without success. As I’m testing other platforms and stacks, I know it should work because some of them work (but to be honnest, I did not succeedf on all of them, but TTN yes).
I tested with my TTNv3 gateway and it was ok but when I look in gateway logs, it shows that the join accept is sent with SF=7 so I guess it’s RAK4631 use RX1 (more, I guess TTN sends join accept both on RX1 and RX2).
My point of view is : LiveObject use RX2 only, so it explains why it fails with it and not with TTN if RX2 parameters are not applied. I will try to force the library to use DR_0 and 869.525 MHz for RX1 and I will see …
Ok so I did my tests … Nothing. I switch back my modifications … Device joined ! So I guess when I change device profile on LiveObject platform it’s not taken account immediatly.
I will try to switch back to other profiles to be sure …
EDIT : confirmed, it was just a profile issue … For the record : use “Generic_classA_RX2SF12”
Humm in fact I may I have spoken too quicly … days later, my device doesn’t join. I checked : I don’t know why, but now LiveObject gateway doesn’t seem to send JOIN_ACCEPT on RX1 (so same SF as device used to JOIN_REQUEST) but RX2 (so SF12).
As strange is LiveObject behaviour, it seems that RAK4630 doesn’t receive RX2 messages. When JOIN_ACCEPT was sent on RX1 it was OK.
More : speaking this SX126x-Arduino library author, it seems that the Semtech library used as base is pretty old Increase SF during join · Issue #49 · beegee-tokyo/SX126x-Arduino · GitHub
I can’t find time to update it. The sources are 2 1/2 years old and work so far without bigger issues. Yours is the first major problem I encounter since a year. The Semtech code changed a lot and it is not a weekend job to update it to the latest
Yes I already spend few hours on it xD I’ve done a very basic integration of the “new” version of Semtech’s library, it compiles but integrating your board.cpp, loramachelper etc … is the biggest part ^^’
I will keep you in touch if I make something which works …
Joins are always done with standard LoRaWAN settings. A custom/alternate RX2 setting (such as using SF9 as TTN does in Europe) can only apply afterwards, as the details are communicated in the join accept. It’s only with ABP nodes where you need to manually configure the RX2 settings.
Any network server can use either of the valid RX windows to send any communication. It is not supposed to use both for the same message.
I agree there is something very strange with this operator, and its documentation is too light on this point. With a generic profil, join accept are sent on SF12 (so it’s why I guess it’s using RX2 windows and not RX1 or both RX1 and RX2).
I will try to switch to others device profiles, maybe there is a better one …
Again, a LoRaWAN network server may use either RX1 or RX2 at its momentary whim.
There is no predictability which will be used in any given join attempt. It could use RX2 100 times in a row and then randomly decide to use RX1 instead.
But these are also required to be the standard RX window settings defined for joins, they may not be customized. Customized RX windows are only allowed for normal traffic after join, not the join itself.
So no, there’s nothing odd at all, and no unique configuration needed.
That additionally means there’s no need for a network operator to document their join RX window usage, as it’s all in the LoRaWAN specification.
I don’t completely agree with you : LoRa in his history evolves and operators can’t just drop devices because there are impossible to update to new Lora’s version. If I use your example : you coded a device using RX2 SF9, and the standard is now RX2 SF12, it’s not a bad idea to allow with device to continue to use your network. My reproach is LiveObject doesn’t provide the characteristics of the different profiles. Some of them are standards compliant, some other clearly are not to allow “old” devices to be usable.
Anyway RX1 or RX2 I agree, but here clearly when network answer on RX1 it works, and not on RX2. But for me it’s a rare problem because in all devices, and all networks I tested, RX1 was used. I’m using another historic LoRaWAN operator in France (Objenious) and I have no problem (but it uses RX1 … maybe if it switch to RX2 I may not join).
For the third time customization of RX windows does not apply to join accepts.
It applies only afterwards.
LoRaWAN has actually changed some other details of the join accept, but this is handled by setting the device’s LoRaWAN version when entering its registration details with the network before attempting to join. If a network wants to support the old device, it sends an old format join accept to a device that is registered as having an older LoRaWAN version. If it doesn’t want to support that, it doesn’t allow registering devices with old LoRaWAN versions in its database of devices it is willing to send a join accept to.
But the RX windows used for join accepts have NOT changed. RX2 is SF12 for joins in EU868 just like it always has been, even on networks where post-join RX2 is SF9
But for me it’s a rare problem because in all devices, and all networks I tested, RX1 was used
That’s not a reasonable position to take at all. RX2 is part of the LoRaWAN spec, and plenty of networks use it quite heavily. You cannot derive any meaning from which window you see a network server use when you are looking, it may choose either when you are not looking, and if it’s remotely decent, it will use one when the other is not available, rather than have fixed behavior.
