joinOTTA uses SF7 (instead of SF12)

[fe64970103]

Hi,

I have range issues with my LORA sensor network and while debugging the whole thing I've noticed joinOTTA is not using SF12 as expected, but it uses mostly SF7 with some random changes to higher SF numbers.

The MKRWAN class library exposes a joinOTAA() function with a default timeout of 60s. Regardelss of this the FW on the STM32 seems to keep issuing the join requests till one of the is successful. It seems to be doing so on a 7s basis.

Attached is a log from my gateway showcasing the SF selection in 3 joinOTTA() function calls (board reset in between).

I would expect the module to start with SF12 and then to go on lower SF numbers based on ADR or based on a user setting. SF7 pretty much inhibits any long range joining attempt.

Is this the intended behavior? Any idea for a workaround provided this is an issue?

Thanks, Marko

joinOTTA.txt

[fe64970103]

Ok, by using MKRWAN_v2 (1.3.0 module firmware) the joinOTTA() is executed by using SF12 which makes total sense to me. However the delay is hardcoded to 60s. Considering joinOTTA() sends out 1 join request I see little sense in waiting 1 minute for a response. It would make much more sense to either:

1. Have a timeout based on lora specs.
2. Not block at all, but provide a polling "isJoined()" like function.

[sslupsky]

The modem firmware controls the join requests. Once you initiate the OTAA join request, the firmware takes over and will retry at various intervals to try and join a network. The timeout is pretty much irrelevant.

[fe64970103]

Not sure if that's completely true. We're only updating the STM32 part of the lora module and it's obvious that by changing this firmware the situation changes - as said 1.3.0 behaves differently than 1.2.3. By updating the STM32 firmware we are not changing the SX1276 part, do we? This means the behavior is under firmware of the STM32 control.