RN2483 timing

[dk9uv]

Hi there,

I started playing with a RN2483 module (Firmware 1.0.5) which is generally working fine.

I wonder about the timing. e.g.

I send “mac join otaa” and receive “ok” and after some time “accepted”.
What is the maximum time between “ok” and “accepted”? I would like to use a timeout in my program if something hangs and therefore require the maximum time to wait.

The same applies to “max tx uncf …” or “mac tx cnf …”. I receive “ok” and “mac_tx_ok” after some time. I would like to use a timeout as well if something hangs.

With best regards

Chris

[kersing (Jac Kersing)]

How about reading the documentation?

For unconfirmed transmissions you are dealing with the receive delays so basically max 2 seconds for the windows and the time involved in receiving a max length packet at the slowest data rate.
For OTAA joins and confirmed transmissions things are not so simple as there may be multiple (re)transmissions involved. What is documented regarding the max number of retransmissions and number of OTAA join attempts? And what regarding the influence of data rates?

[dk9uv]

Thanks for the quick reply.

At the moment I use 5 seconds of timeout for uncnf. messages since this should provide a good safety margin with the 2 seconds rx2 window and the packet size (I must admit I did a bit of reading docs but probably not enough). What worries me more are join and confirmed messages. I have some experience with LMIC+Mega328+RFM95 and discovered sometimes very slow join (though I did relax timing, change gateway and so on, but I do need a bulletproof stable node which I can hopefully achieve with RN2483). So far RN2483 joins always within a few seconds, but the gateway is close and not much traffic in the area. I will further check docs.

With best regards

Chris

[kersing (Jac Kersing)]

If you are unlucky and there is no getaway nearby the join process can take quite a long time. You can test by entering an invalid appkey in the module and see what happens with the firmware you are using. Please report back as the behavior of 1.0.5 might be interesting for other users as well.

In my use of the RN2483 I didn’t suffer from it not reporting back after some (or a lot of) time, however the response wasn’t always the one I expected, so be prepared to detect ‘invalid’ responses as well. (I recall some times getting the boot message in stead of the documented join responses, however the circuit I used at the time was on breadboard with jumper wires so there might well have been an issue with the connections causing an expected reset. The pcb based test node ran for well over a year before I pulled the plug on it.)

[dk9uv]

Just made a quick test.

Unplugged the LAN cable of my gateway and entered “mac join otaa”,
after about 7s the RN2483 replied with “denied”.
Plugged the LAN cable into the gateway and entered “mac join otaa”,
after about 7s the RN2483 replied with “accepted”.
The joon request was sent with SF9 (when turning adr on then the join request was with SF12).

I will do some more detailed testing tomorrow.

[dk9uv]

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?

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, 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.