How to make a join ABP process with RN2483A module?

End Devices (Nodes) Hardware
1

Hi,

After join OTAA i want to make a join ABP process (mac join abp) but always I get the message keys_not_init. (i save after each transmission with mac save)

The first time after initialization of the RN2483A module I make a join OTAA process and transmit some bytes and all works fine. After that, I made a reset (sys reset) and want to join with join abp.

Here my initialization process…

Reset RN2483
-> RN2483 1.0.5 Oct 31 2018 15:06:52

mac set deveui 0004A30B00Exxxxx
-> OK

mac set appeui 70B3D57Exxxxxxxx
-> OK

mac set appkey C38F67D221xxxxxxxxxxxxxxxxxxxxxx
-> OK

mac set devaddr 00000000
-> OK

mac set nwkskey 00000000000000000000000000000000
-> OK

mac set appskey 00000000000000000000000000000000
-> OK

// set duty cycle ch 0 … 7
mac set ch dcycle 0 999
-> OK
…
mac set ch dcycle 7 999
-> OK

// set data range ch 0 … 7
mac set ch drrange 0 0 5
-> OK
…
mac set ch drrange 7 0 5
-> OK

radio set pwr 15
-> OK

radio set sf sf11
-> OK

// set channel status ON ch 0 … 7
mac set ch status 0 on
-> OK
…
mac set ch status 7 on
-> OK

mac set adr on
-> OK

mac save
-> OK

mac join otaa
-> OK
-> accepted

mac tx uncnf 1 1234
-> OK
-> mac_tx_ok

mac save
-> OK

Here I made a reset with sys reset…

sys reset
-> RN2483 1.0.5 Oct 31 2018 15:06:52

and now I want to join ABP…

mac join abp
-> keys_not_init

Can somebody give me a hint what’s going wrong?

2

First all you have to switch also in TTN to ABP. When you get new keys. And ABP is not an “join”.
Here you can read something about this. https://www.thethingsnetwork.org/docs/lorawan/addressing.html

3

No, that is not required for this use case.

Have you checked if there is any information available on the microchip forum regarding this behavior? I recall having seen messages either on that forum or on this forum describing the same issue. I can’t recall what the solution is.

4

@kersing OK thats new is their any document that describes this process? I thought I can only use one method to join.
@ledi007 I read you do an sys reset. Could it be that you loose here your stored Mac keys and so on? Could you read it back checking this first?

5

See OTAA then ABP.

Agreed, the sys reset between the mac join otaa and mac join abp looks weird. Why are you doing that?

If it still does not work without that, then:

I wonder if the dummy values are still needed for 1.0.5, and if that might even make the RN2483 stop overwriting the dummies with the OTAA-supplied values? (I know, it doesn’t make sense, but neither does the need for those dummies make sense.)

Or maybe starting afresh with a sys factoryRESET helps?

(Aside: a long time ago, for 1.0.1 when this hack surely was needed, it took me a long time to realize why things stopped working after a factory reset. After doing a true ABP activation during early testing, and switching to OTAA later, the mac join otaa, mac save, mac join abp sequence would work just great. Until at some point I did that factory reset and no ABP values were stored anymore, which broke that sequence. So, now I actually always do a factory reset whenever restarting the node, to get a clean state.)

Aside: is that needed? For OTAA in EU868, I never did anything like that.

6

Maybe it’s actually okay, and not much different from removing power from the module. From the manual:

2.3.2 sys reset
…
This command resets and restarts the RN2483 module; stored LoRaWAN protocol settings will be loaded automatically upon reboot.

…

2.3.4 sys factoryRESET
…
This command resets the module’s configuration data and user EEPROM to factory default values and restarts the module. After factoryRESET, the RN2483 module will automatically reset and all configuration parameters are restored to factory default values. All LoRaWAN protocol settings set by the user will be lost.

…

2.4.4 mac save
…
The mac save command must be issued after configuration parameters have been appropriately entered from the mac set <cmd> commands. This command will save LoRaWAN Class A protocol configuration parameters to the user EEPROM. When the next sys reset command is issued, the LoRaWAN Class A protocol configuration will be initialized with the last saved parameters.

Any idea if the OTAA Join succeeds right away? Peeking into some old code that uses a Libelium wrapper around an RN2483 1.0.1, I once documented:

Save the intermediate configuration to allow setLoRaWAN to reset the LoRaWAN module when joinOTAA fails

So, in that code I did a mac save before the mac join otaa as well. But, I don’t know if the Libelium wrapper or the RN2483 was invoking some reset there. (The comment also confirms that sys reset should not lose the configuration.) Oh, not relevant: you’re already doing that.

Aside, as per earlier discussions: note that you may not need all this trickery when not removing power from the module, but when instead using deep sleep (with recent versions of the RN2483 firmware), and do a new OTAA join in case of rare conditions that restart the module. Even more: even in 1.0.5, mac save might not store all required settings, like for confirmed downlinks.

7

You should also set ABP parameters first (can be just 0 values) before setting the OTAA values and calling the initial OTAA join.
I’ve seen several times the module does not store anything if some values are never set.
Not sure if that’s firmware revision related, but worth a try.

Also make sure to wait long enough after calling mac save as it does take quite a while to save the settings. So wait for the OK message before calling anything else.

N.B. have not tried this myself yet, as it is still on my todo list, so let me know if you run into other issues trying.