Join request number of retries not working ? about mkrwan HOT 6 OPEN

Hi @MarcoBenini ,
joinOTAA returns true if the network was joined; the same applies to endPacket(true) (true is necessary since it always returns > 0 if the message is unconfirmed).
From the application side these information should be enough to track what is going on and rate limiting the requests. Am I missing something?

from mkrwan.

I think I described in a wrong way the problem.
The MKR1300 WAN doesn't complete the join since a problem of timing of the PyCom "nanogateway" and so doesn't receive the message from the LoRaWAN network server (TTN).

Using the "LoraSendAndREceive" sketch is shown after n time the error message "Something went wrong; are you indoor? Move near a window and retry".

I modified the sketch to see what was the value of connected, that is 0.

int connected = modem.joinOTAA(appEui, appKey); Serial.print("Risposta join connected: "); Serial.println(connected); if (!connected) { Serial.println("Something went wrong; are you indoor? Move near a window and retry"); while (1) {} }

And I than have
"Risposta join connected: 0
Something went wrong; are you indoor? Move near a window and retry"

So join procedure is not completed since the MK1300 doesn't receive the downlink message join accepted.

Leaving MKR1300 continue to go, without resetting and doing nothing, the LoRa module continues to send join requests.
It doesn't stop after three retries as I understood it should do, if I interpreted well the firmware code, but I could be wrong.
Before I unplugged the MKR1300 it sent more than 90 join requests in 2.5 hours.

from mkrwan.

Right, it's probably a bug in the state machine handling the requests, or more likely an external event retriggers a send() which calls https://github.com/arduino/mkrwan1300-fw/blob/master/Projects/Multi/Applications/LoRa/AT_Slave/src/lora.c#L274 ; since this function tries to join again it may be causing the multiple retries.

from mkrwan.

Is there now a solution for this problem? At good days my mkr1300 connects instant and sometimes up to 100 join requests and still no connection (SF7)..

from mkrwan.

@Parr0t

Are the join requests actually being transmitted? I have a situation where I call joinOTAA() and the return code confirms that I have joined the network. However, the server doesn't receive a join request.

from mkrwan.

I actually think that continue retransmissions of join requests is how LoRaWAN specifies this. Typically nodes should start out at SF7 (or rather, the fastest datarate), try a few times, and then slowly (depending on duty cycle limits) move to slower datarates (with more range).

However:

• The firmware seems to continuously retry joins, even when a full cycle fails (this is a design choice, but might not be the best one): v1 firmware and v2 firmware.
• The library has a timeout on join (which defaults to 60s and can be configured using a joinOTAA() parameter, or is fixed to 60s in MKRWAN_v2). This means that after 60s, the join method returns failure / timeout, triggering the error message on serial above. However, this timeout does not cancel the join process, so it continues in the background. Since 60 seconds is (by far, I think) not enough for a full join cycle through all available datarates, this results in a weird situation (but I guess that's partly because a blocking API for this kind of thing is not ideal...).

I guess the proper way to do this is to: 1) make sure the firmware only does a single join sequence (across all datarates), returning a failure somehow if that did not work, 2) make sure the (default) library join timeout is long enough to allow a full join cycle to complete (so the timeout is triggered only in weird error cases / communication failures), and 3) ensure that any running join is canceled when a timeout happens.

from mkrwan.