End Device join after OTAA

End Devices (Nodes) SAMR34
1

Hello all,
My apologies in advance if this has been already asked but I didn’t find a clear procedure for the following scenario.

I’ve bought a WLR089U0 module and fitted it on a custom board. Thanks to the posts being published here and the kindness of some user I’ve got my end device able to send and receive data as expected.

The next step is to implent the FUOTA functionality. After studying the Semtech paper, I thought that a good starting point to prove this concept is the clock synchronization using the DeviceTimeReq mac commands.
Unfortunately, this hasn’t been implemented on the Microchip example project and I’ve started developing it.
(I know this is not the Microchip forum and this topic is not focused on the Microchip Lora Stack but, if someone has any experience with the poor documented MLS in retrieving the GPS time being sent by TTN, I’d really appreciate any additional information).

Since I’m in the developing phase, I need to modify and download the module fw several times and therefore all the join information have to be re-entered.

I’ve joined using the OTAA just the first time and the following times I was joining using the ABP manually entering all the needed information and counters (if I don’t join using the ABP i get the “not_joined” response from the module).
This “trick” worked until I’ve migrated to TTN V3 and if I try to do It now I’m not able to receive ACKs when transmitting (with consequent down counter-frame mismatch ).

To be able to test my code now I’ve to reset the end device using the CLI commands :

  • ttn-lw-cli end-devices reset appID DevID --all
  • ttn-lw-cli end-devices reset appID DevID --mac-settings.resets-f-cnt
  • ttn-lw-cli end-devices reset appID DevID --resets-join-nonces (also tried with --resets-join-nonces “true” but this commands often doesn’t work and I get “DevNonce has already been used”).

My questions are:
Is there a right procedure to follow in order to get my device rejoined during the development?
Would this “procedure” be valid for a real-life application?

Thanks in advance for your help.
Best regards
Luca

2

Hi all, I’m updating this topic with the latest discovery.
I’ve noticed that the TTN team is making daily changes to the TTN V3 (thanks for doing this).
You may have noticed the UI for adding an end-node has changed and it is now asking for lots of additional information (including MAC and PHY layer version).
While manually adding a new device I’ve chosen :

  • device activation: OTAA

  • PHY v1.0.3 REVA

  • MAC v1.0.4

  • and I’ve ticked the “CLASS C” feature.

Being my board battery powered I need to switch the power to every single module including the LORA module (not in sleep, completely off), this implies saving and restoring the keys and “Rejoin” every time I power it up.

I’ve noticed that since I’ve chosen OTAA I can’t use the “trick” (described in my 1st post) anymore but, while APB activation isn’t working a new OTAA join request is going through! great!
Note: since I’ve ticked the “CLASS C” feature, to update the new set of keys on the end-device page, I need to send a confirmed uplink straight after the join req. As it is explained for CLASS C-capable device in the LoRaWAN spec

My questions are:

  1. It is correct the send multiple OTAA join req? (this behaviour is discouraged in every article I’ve been reading-. OTAA join req should be requested just once)

  2. If this is correct, what is going to happen once the DevNonce field (join req payload) will roll over?

regards

3

General guidance is Class C is not really suited to battery powered nodes, unless big capacity, changed frequently, and/or provided with some local charging mechanism (solar? RF scavenging? Thermal source? Peizo or other mechanical vibration harvesting etc.)

4

This looks like a hot mess of guessing - somewhat highlighted by your own use of “trick”.

The latest MLS needs 1.0.4, Class C is totally wrong as @Jeff-UK says, OTAA re-joins are the worst, TTI aren’t making daily changes and it’s always asked for that information.

There are all the facilities needed in MLS to get the session keys & counters which you could store but very very few people find a need to do that - it’s tricky and batteries usually self-discharge faster than the sleep power needed for a good design, so you may as well sleep rather than use up all the power you save by powering down and powering up.

5

Hello @Jeff-UK and @descartes, thanks very much for your replies.

Please accept my apologies if I haven’t used the right terminology but I’ve joined this community and I’ve started studying about LoRa and LoRaWAN just a few weeks ago.
Allow me to explain myself better.

My end device supports both Class A and Class C, It will operate in CLASS A most of the time and it will occasionally switch to CLASS C when a Remote multicast setup package will be received (for example to perform a FUOTA).

I rather say that this looks like a hot mess of questions since before writing a post in a community I’ve been reading and studying - no guessing here :wink:

My apologies for the wrong terminology, I’ve used the “trick” word intentionally because of its English definition (a sneaky scheme to deceive or cheat) since also for a beginner, it’s clear that the activation procedure described in my first post is incorrect.

And that’s why I’ve started this topic, for asking someone more expert than me what is the right procedure to follow:

You might have missed the preamble of this topic where I’ve specified that at the moment:

Although, I’ve also asked :

This is because, I think that what you wrote is not entirely correct:

I think (but I could be wrong) this depends on both the project requirements and how the application is meant to work. Imagin an end-device that needs to send an up-link once every week.

Not on The Things Network V2, and I thought to share these informations since they may help some inexpert user that recently migrated to V3 (like me).

So, to get to the bottom of this:

  • There isn’t a right procedure for rejoining, quite the opposite, this should never happen (but what if either a power cut occurs or the battery needs to be replaced?)
  • In the developing phase we don’t have any other choice but repeat the OTAA every time we flash a new fw.
    Are these assumption correct?
6

No.

Points arising:

  1. You gave us insufficient detail - now you tell us that it’s only sending once per week so your rebuttal to me is a bit rude and btw, I don’t need to imagine a device sending once per week, I’ve plenty already, but not many, most do at least one uplink a day. YMMV.
  2. By your own admission you are new to LoRaWAN yet you are trying a really hard project first - not only saving session keys but also switching to Class C for FUOTA, let alone FUOTA.
  3. At no point did anyone say that you can only join once in a devices lifetime, what we say is that it should not re-join as a matter of course - although most devices don’t have power cuts and many don’t get their batteries replaced because it’s cheaper to put a bigger battery in than have someone go and change a battery.
  4. In the developing phase you can either spin your wheels waiting for a join before you can test and then have to deal with the consequences of DevNonces, or you could use ABP. I shudder to think what you mean by manually entering the information / join information have to be re-entered.
  5. @Jeff-UK made the point about Class C having a reliable power source, your response provided no further information and didn’t address the point.
  6. I think the Microchip documentation is great.
  7. And finally, TTS v3 is not changing on a daily basis, the releases are well controlled & planned, albeit there was a hot fix yesterday.

As with many requests for information, this has become another drip-feed special where we give replies in good faith and then the OP gets all huffy because they don’t like the replies and eventually, several posts later, they realise that unless they share some actual background to the questions, as context is everything, it’s almost impossible for people to help.

It seems there are a number of issues here, apart from approach, which are:

  1. Configuring the firmware for ABP join during development
  2. Looking at the API’s for saving & reinstating the session keys (which may well require a better understanding of which keys & counters are required)
  3. Understanding Class C requirements
  4. Understanding FUOTA

The last two topics will be covered in the conference on Friday.

I’d try tackling the first issue of ABP joins first - is this working for you without typing anything in?

1 Like
7

Hi @descartes, thanks again for your reply.
First thing first, I’m sorry if what I wrote did sound rude and offensive, this has never been my intention.

Perhaps you are right, I should have been giving more details for my hw/sw design.
My apologies for this but, when I’ve started, I thought to write a generic topic just to understand what is the right procedure to join the network during the developing phase and once the end-device is released regardless of the application logic (perhaps I’ve chosen the wrong title).

You must have misunderstood the meaning of my following sentences:

What I meant here was related to the decision of putting the LoRa module (o whatever other module) either in sleep or shutting it down. In my opinion, this decision is a trade-off between project requirements and application logic.
For example, for a generic device that will send an uplink once a week, you may (or you may not) save more power by shutting the module down rather than having it in sleep mode for a long period of time.

Maybe here I should give you more detail for the hw design I’m using:
My custom board has a set of sensors and modules; one of these modules is the WLR089U0.
Sensors and modules have their own power domain and a master uC drives them and can shut them down independently.
So, when I’m writing “shutting the module down” I mean the WLR089U0 LoRa module.

I’m aware of the complexity of this challenge. I can’t put the FUOTA aside since it is part of the project requirements but I can break it down and accomplish it one step at the time.

Thanks for making this clear :slight_smile:

:joy: :joy: Please excuse my bad explanation.
Here I was trying to explain what I’ve experienced when my device was on TTN V2 and a better explanation is due:
I’m communicating with the WLR089U0 over serial port and, after the first OTAA and module reset, I had to manually enter all the information displayed on the end-device console to be able to perform the ABP (the “trick” :sweat_smile:)

That’s because I need to figure out which components (sensors and modules) on my board will go in sleep mode and which component is possible to shut down. Once I’ve got this clear in mind I’ll need to run a few tests and measurements for the overall power consumption and just then I can choose the right battery and charging mechanism to meet the requirements.

I agree to disagree, I’m referring to the MSL sw API reference manual in particular to the Stack Attribute section but this is not the right place for this.

I think I’ve already clarified this.

Again, my apologies if I gave you (or anyone else) this impression, not my intention; Why should I be huffy with someone that is actually trying to help me?

I still have to code the part where I will save the join information (address, keys, counters) in flash (in the future I think I’ll be using sure elements) but if I add a new device choosing ABP as device activation, I set the needed information via serial in the WLR089U0 module and then I trigger the APB join command, it works

Where I can get some more information for this conference?

Thanks :slight_smile:

8

You need to save more, in fact you need to save the state of the LoRaWAN stack. Additional parameters to save are at least the frequencies used, duty cycle for each frequency, spreading factor, transmission power. There is probably more, this is just what comes to mind when thinking about it for a minute,

As @descartes already mentioned, putting the module in low power sleep would be a far better solution. Less risk of getting things wrong and the module has few low power sleep mode.
BTW, the module is capable of running both the LoRaWAN stack and application logic, this allows replacing the ‘master controller’ in your setup and having just one controller. For a battery powered device having two controllers could be considered wasteful.

Read the forum, there have been at least 4 messages with announcements in different topics today.