OTAA without joining the network

[onass]

Hello,

My end node activation mode is OTAA, and is supposed to enter shutdown mode and wake up after a specified period of time period, in order to save power, the end node should skip joining the network at every wake up.

I was able to skip the joining process by switching the activation mode from OTAA to ABP after the first join process, but after that, the server did not receive every packet sent from the end node like it used to when i was working with OTAA

I doubt this is a good solution since a lot of packets are lost

My questions are:

1) What do you think of my solution? is it missing something?

2) What are my options if I want to stick to OTAA while skipping the joining process?

3) Should I just go with ABP?

[JHCarter]

Hello @onass ,

I believe you are using the LoRaWAN_End_Node_LBM example application from STM32CubeWL-1.5.0.  I am also working with that application but on different hardware, the B-WL5M-SUBG1 board.  As long as you are using the low power mode (Disable Low Power Mode is NOT checked under LoRaWAN Application tab in CubeMX) then I think it should behave as you want it to.  If you set the Transmission Duty Cycle on that same tab to 300 seconds for instance, the application will join the network and then send a packet every 5 minutes.  In between those transmissions the MPU will go into STOP2 mode where it will draw less than 2 uA.  When it wakes up it just sends the next packet, receives any queued downlink packets, and goes back to sleep - it does not need to join again. This is my use case also and so far it is working well.  My LoRaWAN gateway is a RAK7258.

If you actually reset the MPU then it will have to join again, but as long as you utilize the low power mode it should work without having to join each time.

I may not fully understand your use case.  Let me know if this makes any sense.

[onass]

Hello @JHCarter !

Thanks for your reply!

I have to force the MCU into shutdown mode, when it wakes up from shutdown mode, it is like a reset, so in my case, after wake up, the device joins the network once again.

To avoid joining the network on every wake up, i switched to ABP after the first join process, but then I started losing packets and I don't know why!

How can I actually tell the MCU that it is joined to a network without actually joining that network once again? The device should already have all the needed keys, right?

[JHCarter]

Hello @onass 

I think shutdown mode is going to be a problem. I have not dug too deeply into the LoRaWAN protocol but I believe some temporary or "working" keys are generated during the join process.  That information survives going in and out of STOP2 mode, but does not survive a processor reset.  I did play with ABP back on WL v1.4.0 and it seemed to work OK, but I don't think it is well supported on WL v1.5.0.

Do you think you could come up with a way to use the existing mechanism of going into STOP2 mode rather than Shutdown?  It would simplify things considerably.

[onass]

Hello @JHCarter !

Unfortunately shutdown mode is needed for maximum power saving.

if ABP is not well supported on v1.5.0, would you suggest downgrading to v1.4.0?

[onass]

@JHCarter 

I noticed that in ABP mode, the DevAddr is equals to zero, I think this might be the problem, but i don't know why even tho I already set it with a certain address
Payload: 40 00 00 00 00 00 CB 00 02 E9 85 83 D2 F9 81 2E F0 9C BE 9F 72 B2 49

[JHCarter]

Hello @onass 

I think I would give v1.4.0 a try at least to see if it would work.  I did have good success with it on my application but decided to move on to v1.5.0 when it came out since I think the underlying modem code (LBM) in v1.5.0 is better and will certainly be better supported in the long run.

I'm curious about your need for maximum power saving.  I am seeing 1.4 uA in STOP2 mode on my B-WL5M-SUBG1 board as measured across the IDD header.  Would that be too much for your application?

[onass]

Hello @JHCarter 

To be honest, I think STOP2 mode will do, but I am bit curious to see if I can make it work

I will try with v1.4.0 and with v1.5.0 I will try to understand why the DevAddr is all zeros

[Imen.D]

Hi @onass ,

Any progress concerning your last update with v1.4.0 and v1.5.0?

Please provide an update on this thread and confirm whether the issue is resolved.