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.
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:
sys factoryRESET also resets the used DevNonce and a new join over OTAA will fail if the backend side is not reset.
As experienced with RN2483 before, ABP credentials should be initialized before joining by OTAA, in order to use join by ABP afterwards.
The frame counter has to be “manually” counted upwards (“mac set upctr 12345”) in order to let more than one uplink pass through…
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.
Not my invention. 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…
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. …and I’m still learning, too.
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.
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.
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.
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).
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.
I’ve been using the WLR089U0 xplpained board and can offer some advice.
Try using the Range Test example. I’ve had a lot of issues trying to use the Mote example, (AU915), but none with the Range test. I would also recommend using the CLI to disable the devNonce check. Particularly when you are developing your code.
Take a look here: Request - DevMode toggle or Reset Nonce button - #18 by zygurt for how I did it.
Hello Basler. A quick question please.
We got a WLR089 module but I can not communicate with it.
Does the WLR089 ic comes preloaded with basic lorawan stack or you have to program the module ?
Thanks
Depends - do you have the WLR089U Xplained development board as that usually does have code on it that you can access over the serial port. Or at worst read the docs on setting up Atmel/Microchip Studio to program the base code.
If it’s just the module, I don’t know because I always put my own firmware on it.
If you only have the module and not the dev board, you’ll need to mount it in some way to access the pins.
If you need a PCB to mount it to, this is one I’ve been working on in the past year.
I use Altium Circuit Maker, and am mostly happy with where the PCB is at. The programming header and the direct power header are too close to each other to be both plugged in easily, but that’s my only concern at the moment. The link is to a clone of the project, so is stable and won’t be updated.
You don’t need most of the parts for basic operation, and all of the pins have been broken out. The BOM doesn’t show correct parts, but the comment and designator are correct. This mainly applies to the resistors and capacitors.
Also note that the DSBGA packaged 3.3v buck converter is a real pain to solder by hand. It can be done, but really really stretched my skills.
If you are using the bare chip, it doesn’t come pre-programmed. I’m hoping to have a base firmware covering the functions I require completed in the next couple of weeks. I’d suggest loading an example session, probably the range test example. You’ll need the EUI which can be found at 0x0080400A and put it into conf_app.h.
I had all sorts of issues getting ABP to work in Australia, so am using OTAA. The catch is that when you’re doing development, the nonce gets reset each time you upload code, so you’ll need to turn off that TTN safety feature. My previous comment has a link to the process that I used.
Hello guys, trying to use the same topic as you. I’m working with the WLR089 X Plained board. The examples works well, however I really would like an example with a real situation. Like just waking up and send a data and goes to sleep. Typical class A example. I’m trying to do my self but the example have to many informations and is not working well.
Do you guys have one?
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… 
…and I’m still learning, too.