Setting pre-JOIN RX2 download for TTN

[terrillmoore]

When using The Things Network in the EU868 region, you must set the pre-JOIN RX2 Data Rate to SF9 (DR4). It turns out not to be as simple as it should be. We need a better way of tailoring LMIC for pre-JOIN (and ABP) network parameters. The more that people have to modify LMIC.* datafields by direct assignment, the less flexibilty we have for correcting names that don't match the spec, etc. Even for ABP, we no more want people changing LMIC.dn2dr directly than we want them changing LMIC.channels[] directly

@cyberman54 wrote:

Moved a small step forward here. Found out why in my code the setting RX2 == SF9 for ttn did not work. I called LMIC.dn2Dr = EU868_DR_SF9 right before LMIC_startJoining() but this can't work*. After i moved LMIC.dn2Dr = EU868_DR_SF9 to the event handler (put it to case JOINING, as found in the compliance script) i now see correct setting SF9 for RX2 in the log while joining. Perhaps this should be documented somewhere, otherwise probably most of TTN & LMIC users will use wrong RX2 setting.

*) Because LMIC_startJoining is calling resetJoinParams() which overwrites
LMIC.dn2Dr = DR_DNW2;

Originally posted by @cyberman54 in #455 (comment)

[jpmeijers]

It should not be necessary (it is actually wrong) to set the dn2dr when doing OTAA, as the network will configure it during join.

For ABP using LMIC.dn2Dr = EU868_DR_SF9 should be fine as there is no join process to override this.

I think the confusion in the original issue is at which SF the join needs to happen. TTN let's you join at SF12 on one of 868.1, 868.3 or 868.5MHz - which is the LoRaWAN regional params for EU. During join the network needs to configure custom channels and custom datarates. It is therefore incorrect to configure the dn2dr before a join.

[manuelbl]

I've come to the same conclusion. Also see this issue. It discusses the same question. And the conclusion is a commit that changes the data rate to SF12 (for join).

[terrillmoore]

a commit that changes the data rate to SF12 (for join).

Old comment for history, but... this is incorrect. I forked the current code and investigated. I came to the same conclusion: SF12 is used for JoinAccept.

I think we're all violently agreeing. It should not be done after join; but pre-join, you're not going to have a good TTN experience without setting LMIC.dn2dr. The point of this issue is that there needs to be an API to take care of this (and other network-specific pre-join parameters).

The reference issue indicates that TTN uses SF9 for RX2 JoinAccept. It recommends a change, but to my knowledge this change has not been made in the network. A review of the current code shows (activation.go, line 112):

	lorawan.Rx2DR = uint32(band.RX2DataRate)

This looks like it uses the same data rate for JoinAccept as it does afterwards. So I conclude that SF9 is needed for JoinAccept processing on TTN.

[manuelbl]

Do you have any hard evidence that SF9 is used for JoinAccept in Europe?

I just stumbled across this statement from Jac Kersing (re EU868):

And TTN does send OTAA replies using the standard RX2 parameters as documented in the LoRaWAN standards document

Standard RX2 parameter is SF12.

[jpmeijers]

(Note that my comments are only relevant for EU868.)

Yes, have a read through TheThingsArchive/ttn#767 and also note that I made a change to TTN's v2 code base - a change that is running in production since 15 October 2019.

For OTAA:

• Join accept in RX2 will be sent using standard SF12
• During the join the device is configured for TTN RX2 with SF9
• From then on forward TTNv2 will always use SF9 for RX2

For ABP:

• TTNv2 tries using SF9 for RX2
• If the ADR acks are not received by TTNv2 it will fall back to using SF12 for RX2 and stay there - never trying SF9 again

[terrillmoore]

Closing this as being mistaken.