# RN2483 timing

**URL:** <https://www.thethingsnetwork.org/forum/t/rn2483-timing/36278>\
**Category:** End Devices (Nodes)\
**Created:** [April 19, 2020, 3:05pm UTC](https://www.thethingsnetwork.org/forum/t/rn2483-timing/36278 "2020-04-19T15:05:50Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![dk9uv](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/dk9uv/32/27638_2.png) [@dk9uv](https://www.thethingsnetwork.org/forum/u/dk9uv)\
**Post date:** [May 3, 2020, 10:16am UTC](https://www.thethingsnetwork.org/forum/t/rn2483-timing/36278/6 "2020-05-03T10:16:09Z")

</div>

I did some further reading and would appreciate some advice on how to best use the RN2483.

According to the best practices of TTN devices should perform join operations the less possible  
in their lifetime.

E.g. a good practice would be to have the device join as part of the manufacturing process,  
and have the device use the same session for its whole lifetime.

But consider what happens in the case of a power cycle (intended or unintended).  
It would be necessary to perform a “mac save” after each transmission and then use  
“mac join abp” after power cycle to avoid an otaa join as described here:

> [@How often should a node do an OTAA Join, and is OTAA better than ABP?](https://www.thethingsnetwork.org/forum/t/how-often-should-a-node-do-an-otaa-join-and-is-otaa-better-than-abp/11192/47):
>
> Quite late, but just for future reference: Indeed, I’ve also seen that this is required for a Libelium device back in May 2016, which identified as RN2483 1.0.1 Dec 15 2015 09:38:09. And here’s the part that is relevant [from that link](http://www.microchip.com/forums/m945840.aspx), October 2016, numbered and formatted for readability: The initial RN2483 and RN2903 both contained an errata meaning that the sleep current is above spec, and this can be an issue for sleepy devices trying to achieve very long battery life. As hinted in the po…

The disadvantage is the Eeprom wear (and the small probability of eeprom corruption if the power cycle happens exactly during eeprom write).

So I thought of this procedure:

I once configure the keys and use “mac save”.

At startup or after a power cycle I expect that “mac get status” responds with join status 0.  
In this case I perform “mac join otaa”.

After successfull join I transmit data and goto sleep.  
If the join is not successful I do not transmit and goto sleep.

I wake up after some time and check with “mac get status” again.  
If “mac get status” responds with join status 1 I know that the join has been successful  
and there was no power cycle since then. Then I transmit and go to sleep again.  
(if there will never be a power cycle then it would not be necessary to check mac status, but you never know).

If the RN2483 may hangup during operation and does not respond anymore (unlikely but you never know) then I will reset the RN2483 and perform a join again.

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/rn2483-timing/36278)._