OTAA join retries

[fabiano]

Hi,
I'm making some test with LoPy (1.18.0) to understand how internal stack behaveas in critical cases of low coverage leading to a join faiulure.
I'm simulating this setting wrong app_eui/key.

What I see from gateway logs is that, regardless of timeout passed as parameter to join function, LoPy internal stack goes on to try again and again with join request even if I correctly receive the timeout exception after correct timeout period.

My join request:

lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=20000)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TimeoutError: timed out

Is there a way to stop the join procedure?

Also I noticed that the retry frequency is strongly variable in relation to SF: every 10 seconds in case of SF7, up to 2 minutes in case of SF12
Instead in documentation I read "Internally the stack will automatically retry every 15 seconds until a Join Accept message is received"

Why this so long time in case of SF12?
Also considering gateway answer in RX2 window, 20 seconds should be enough, isn't it?

Thanks and best regards
Fabiano

[jcaron]

@fabiano IIRC it is a requirement of the LoRaWAN specifications to not send join requests too often. I believe the frequency will actually decrease after one hour, and even further some time later (a day? Would have to check the spec).

Also remember that in some regions like EU868 there’s a duty cycle limit of 1% airtime. At SF12 a join request probably takes more than a second to transmit, which means the device needs to wait for at least 99 seconds before transmitting again in the same sub-band (in a simple and naive implementation of the duty cycle). The default join channels are probably all in the same sub-band (sorry, too lazy to check right now).

There have been discussions on this topic before, hopefully the search feature should yield them for you.

[fabiano]

This post is deleted!

[fabiano]

This post is deleted!

[fabiano]

@jcaron
thanks for your answer.

And what about the possibility to stop the join request procedure?
I'm still struggling with it but I can't find a solution: internal stack goes on in any case triyng (I guess) with all channel and all SF.

The reason behind my need is the following: I'm going to install my LoRa devices in a very remote area with the concrete possibility that gateway is unreachable.
So this unstoppable join procedure is very power consuming and useless. I would like to try just few times, maybe starting with middle/high SF, and if unlucky stop it and try next time (maybe after some hours, waiting for human intervention looking for a better place)

[jcaron]

@fabiano I don't think you can LoRa.deinit(), so the only option I would see is to store a flag in NVRAM and reboot. Check on reboot if the flag is set and then don't attempt a join if so.

Or just going to deep sleep without saving state (optionally with a flag to avoid joining, or maybe a retry counter), since waking up from sleep is like rebooting.

Note that the frequency of the join attempts should go down after a while. The LoRaWAN spec allows 36 seconds transmit time in the first hour, 36 seconds in the next 10 hours (i.e. on average 3.6 seconds per hour), then 8.7 seconds per 24 hours. However I have no idea if this is actually correctly tracked if you try to deep sleep (I quite doubt it).

[Gijs]

If you're looking at saving the LoRa data in Nvram to be used after a deepsleep, have a look here: https://docs.pycom.io/tutorials/networks/lora/nvram/

[fabiano]

@jcaron thanks for the hint.
I made some experiments and It seems that it's possible stop the join process reinitializing LoRa class with something like:

lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)

This avoid the start of new one retry but, the current running try is in any case completed, probably in respect to radio duty cycle.
In other world: if I start a join process with SF12, calling

lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0, dr=0)

I can stop the join process reinitializing LoRa class but in any case I have to wait minutes before start another join proces