Set join SF

[kersing]

After checking the documentation and trying some options (like lora = LoRa(mode=LoRa.LORAWAN,sf=8)) it seems there is not way to specify the spreading factor to be used for an OTAA join? Am I missing something or is this essential feature on the backlog?

[rskoniec]

lora.join method (OTAA, ABP) uses LoRaWAN stack (mode), so following a Note to lora.init method https://docs.pycom.io/pycom_esp32/library/network.LoRa.html you can't specify SF and some other params.

lora.init Note:

In LoRa.LORAWAN mode, only adr, public and tx_retries are used. All the other params will be ignored as theiy are handled by the LoRaWAN stack directly. On the other hand, these same 3 params are ignored in LoRa.LORA mode as they are only relevant for the LoRaWAN stack.

LoRaWAN uses (ADR - Adaptive Data Rate) so LoRaWAN can automatically manage SF for each
end-device (to optimize for fastest data rate versus range, for maximize battery life, achieves maximum network capacity).

[bmarkus]

@rskoniec said in Set join SF:

LoRaWAN uses (ADR - Adaptive Data Rate) so LoRaWAN can automatically manage SF for each
end-device (to optimize for fastest data rate versus range, for maximize battery life, achieves maximum network capacity).

Use of ADR is optional, end device decides to use ADR or not. There are use cases where ADR is not optimal and you want to control RF settings. Also keep in mind use of ADR requires some attention on the device side.

See article below. It is about Loriot server and Microchip RN2483 module but worth to read:

http://openlora.com/forum/viewtopic.php?f=12&p=2730#p2730

[kersing]

@rskoniec said in Set join SF:

LoRaWAN uses (ADR - Adaptive Data Rate) so LoRaWAN can automatically manage SF for each
end-device (to optimize for fastest data rate versus range, for maximize battery life, achieves maximum network capacity).

Thank you for your answer, however:
If a node is known not to be near a gateway a join at SF12 takes seconds. Waiting for ADR to go from SF7 to SF12 takes minutes (due to airtime restrictions) and drains battery with a lot of avoidable transmissions. Also, ADR should not be used for nodes moving around as there is no way to know what transmission conditions will be on the next transmission, ADR in these cases could well result in avoidable packet loss.

So might I suggest being able to set the spreading factor for LoRaWAN before (and after) a join needs to be implemented?
(BTW, three other certified LoRaWAN implementations I'm using allow setting the SF before OTAA join, so it is not something out of the ordinary)

[cmsedore]

@kersing I have code ready to go that lets you set the SF and the uplink counter--I'm waiting for the source tree to be updated in Github before creating a pull request.

[affoltep]

@cmsedore Have you done the pull request? Both of your modifications to change SF and uplink counter would be essential.

[cmsedore]

@affoltep I have not done the pull request--the repository was modified and I haven't taken the time to sync this back up. I'll take a look in the next day or two to see if I can just clone the new repo and easily merge in the changes. It has been on my list to do the pull request for the SF change to make it easier to use my single channel gateway at home (while I patient wait for TTN to ship my full-fledged gateway).