Any experience with WLR089? Having some trouble

End Devices (Nodes) SAMR34
#1

Hi there!

I’m using the WLR089 module ( WLR089U0 - Wireless Modules ) on a self-made PCB. However, I had different kinds of trouble. Two modules had a low ohmic shortage and heated up… even after desoldering some pins were still shorted, so the problem must have been on the module. Maybe I heated it up too much myself when soldering? Are some pins shorted by software? … if anyone has experienced something like that, please raise your hand.

I want to use the module controlled by UART externally and I’m using the software provided by microchip for that:

As far as I can see this stack is made for the Xplained Pro board and not the WLR089 module on its own. I’m unsure wether this is a problem. I commented out the usage of LED and button pins and the button interrupt.

Further down the road I got a module working and communicating with my microcontroller.
However, first I had problems joining (Join was denied by network), now it’s not sending any message at all to the network (as I can see by the network traffic of a close-by gateway).

And all I get is a “denied” response after “mac join otaa” uart command.

Here’s the complete communication for an OTAA attempt (<< indicating response from the module):

sys factoryRESET
<< System Reset Request
<< LoRaWAN Stack UP
<< USER BOARD MLS_SDK_1_0_P_5 …
mac reset 868
<< ok
sys get hweui
<< 0123456789123456
mac set deveui 0123456789123456
<< ok
mac set joineui 0000000000000000
<< ok
mac set appkey abcd1234…
<< ok
mac join otaa
<< ok
(waiting some seconds)
<< denied

Any hint or help appreciated!

Otherwise I will try with a fresh module next week to see if it’s not a hardware problem… but I’m not very eager to buy more and more of a module that might not be working properly for my case at all.

#2

Well, ok. Helped myself and sharing knowledge with you:

The high current is not yet understood. Most likely some soldering issue. I’m using a new module on the same PCB now and again the current is higher as expected but the module works.

Learnings about the UART parser on WLR089:

  1. sys factoryRESET also resets the used DevNonce and a new join over OTAA will fail if the backend side is not reset.

  2. As experienced with RN2483 before, ABP credentials should be initialized before joining by OTAA, in order to use join by ABP afterwards.

  3. The frame counter has to be “manually” counted upwards (“mac set upctr 12345”) in order to let more than one uplink pass through…

#3

That would appear to be a spec violation, a node is really supposed to keep track of dev nonces it has already used, or failing that make a sufficiently random guess, as re-using a nonce is prohibited.

  • As experienced with RN2483 before, ABP credentials should be initialized before joining by OTAA, in order to use join by ABP afterwards.

No. ABP and OTAA have nothing to do with each other, you’re in one mode or the other. There’s not even any portable sense of a “device” as far as a Network Server is concerned.

  • The frame counter has to be “manually” counted upwards (“mac set upctr 12345”) in order to let more than one uplink pass through…

That’s because you’re not allowed to reset the frame counter of an ABP node to zero, but only continue it forward from the previous used value.

As a beyond-the-spec hack, TTN will let you reset the expected frame count.

#4

Not my invention. :smile: But that is how the module behaves. So factoryRESET should only be used before registering the device… maybe that’s why it’s called factory reset… :smile:

Yes and no, these two are different types of joining but with similarities. I’m talking about the module’s specifics. You have to init the ABP credentials (Network Session Key, Application Session Key, Device Address) before joining by OTAA in order for the module to overwrite and store those values after a successful join by OTAA. After all, these two modes use Network Session Key, Application Session Key and Device Address for communication, while with ABP you will set those yourself, with OTAA they will be set from the server. With the microchip modules you have the chance to join by OTAA, store the credentials and next time you send something you can reuse those as if you’re joining by ABP, saving airtime.

Also I do know that. But the difference between RN2483 and WLR089 commanded over UART is that the first automatically increased the frame counter and reseted it when a new OTAA join was performed. The second has a new command and you have to update the counter from the host controller commanding the module.

I didn’t want to argue about LoRa specifications, but someone who switches from RN2483 to WLR089, like me, might find my learnings helpful. :wink: …and I’m still learning, too.

3 Likes
#5

This may be the source of the confusion. There’s no such thing as “joining by ABP” - an ABP device doesn’t join, it just sends packets using the pre-agreed secrets.

However, what you are describing as ABP-like is not legitimately ABP at all, but rather OTAA - the whole idea with OTAA is that you join once, and then you keep using those session details, preferably for the entire service lifetime of the device or at least for months to years at a time. But it’s still OTAA, not ABP.

But the difference between RN2483 and WLR089 commanded over UART is that the first automatically increased the frame counter and reseted it when a new OTAA join was performed. The second has a new command and you have to update the counter from the host controller commanding the module.

Counters are always reset when a join accept is received.

But OTAA devices are not allowed to reset their counters otherwise, just as ABP devices are not allowed to reset theirs.

It seems that the difficulty you are facing arrises from illegitimately trying to use an OTAA session as if it were an ABP registration and put that into a new or newly flashed device, which is not how OTAA is supposed to be used.

Either an OTAA or an ABP device should save key information - uplink and also downlink frame counters, and for an OTAA device the session secrets - across power loss, but that doesn’t make an OTAA session an ABP registration.

#6

You are right from LoRaWAN specification point of view, however not from the point of view of the Microchip API.

For the Microchip API it is perfectly valid. So I suggest we drop this discussion as it comes down to the way the vendor implemented the specification. As long as the result is LoRaWAN certified (and their firmware for the RN modules is) and their API works for the users of their hardware there is no problem so let’s not create one.

2 Likes
#7

I have been trying the WLR089U0 module standalone, just soldering cables on to the chip.

Connecting to TTN.
If you try to reset you will be denied next time.

I have been testing with mobile and OTG adapter, just chosing send.

Regards

Michael

1 Like
#8

Indeed - LoRaWan nodes aren’t supposed to be reset, as that leaves them out of sync with the state tracked in the network server.

If you reset an ABP node you also have to reset the expected frame counter on the network side, or update both uplink and downlink frame counters of the node to match the network’s expectation.

Request - DevMode toggle or Reset Nonce button
#9

Hello! I am facing the same issue. How can I join again if I reset it after joining once?

Thanks!

#10

Without knowing your code, it’s hard to tell.

If you’ve just used my procedure from the opening post, let me tell you that the “sys factoryRESET” should be avoided, as it resets the DevNonce on the module side. Like I described in my second post.

If, however, you have trouble sending messages after a successful join, check their frame counter value (must be increasing).

#11

I am not making sys factoryRESET, neither the first time de device joined. Only 1 time joined but it was after a lot of attempts. Y am making the “normal” reset. This is the issue I opened. I can see the device on TTI or TTN console, but the device remains as “No Free Channel Found”. I wait for a lot of hours and even days to try to join again but nothing happens.