-
Notifications
You must be signed in to change notification settings - Fork 274
EU RX2 parameters #155
Comments
Or maybe, for join accept, SF12 can be used in RX1 as well? (Indeed SF12 needs to be used in RX2, if RX1 was not used for some reason. But SF12 being mandatory for RX2 join accepts, might not necessarily mean that SF12 cannot be used in RX1 as well?) |
Due to the frequency plan, RX1 has a duty cycle of 1% and RX2 of 10%. Better to schedule long SF12 transmissions in RX2. Also, if the RX1 duty cycle is (near) full already, the join accept will be in RX2/SF12 anyhow. Additionally, in RX2 more power can be used. |
Can we label this as 'bug'. I wonder how people can actually use OTAA with TTN backend with this deviation from the spec. At least my libmDot does not allow me to change the SF for RX2 when it expects a JoinAccept message. |
If the consensus is to have join reply use the standard setting of SF12 in RX2, this should be implemented sooner rather than later. People are starting to build nodes for deployment, if this is changed after deployment those nodes will require firmware updates for the new setting. (Or ugly work arounds need to be added to firmware now) |
Feel free to submit a PR. We're a community project after all ;) |
Fix for join issues mentioned in "EU RX2 parameters #155", …
Fix for join issues mentioned in "EU RX2 parameters #155", ...
Thanks to @kersing this is fixed now. |
LoRaWAN specification 1.0/1.0.1:
"The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz)."
For scalability reasons TTN wil use SF9 as RX2 data rate (already implemented). End-nodes need to be (made) aware of that.
** OTAA **
The RX2 data rate configuration is communicated to the end-node in the join accept message (DLsettings). After the join, the node can be assumed to be aware of the RX2 SF9 rate. If the stack, e.g. LMiC, does not process the DLsettings correctly, then it needs to be configured manually on the end-node (after the join).
Before the join, the end-node still uses the default RX2 data rate (SF12). To be fully compliant with the specification, the TTN back-end needs to use SF12 in the RX2 slot during the join process. This alters the downlink logic from the current implementation.
join request SF7-SF11: join accept in RX1 (SF7-SF11)
join request SF12: join accept in RX2 (SF12)
** ABP **
ABP end-nodes need to be configured manually to use SF9 as RX2 data rate.
The TTN backend could try to facilitate this by sending MAC commands to set the correct configuration, for example after a frame counter reset. TBD.
The text was updated successfully, but these errors were encountered: