Join mode differences

[Andrew Lindsay]

From the mdot.h file, for the function setJoinMode I read:

* MANUAL: set network address and session keys manually
* OTA: User sets network name and passphrase, then attempts to join
* AUTO_OTA: same as OTA, but network sessions can be saved and restored

Can someone explain exactly what the difference between OTA and AUTO_OTA mean?

In operation I dont see any differences?

Does AUTO_OTA perfrom the restoreNetworkSession() and saveNetworkSession() calls automatically?

What about setPreserveSession()? Comments say this is only for AUTO_OTA.

I’m trying to get an understanding of when the mDot is reading/writing to flash as it seems to do it even if I dont even attempt to join the network or send data.

Does the dot = mDot::getInstance(); cause flash reads and the sleep causes flash writes?

Thanks

Andrew

[Mike Fiore]

Andrew,

When the mDot constructor is called (first call to mDot::getInstance), configuration is read from the flash.

OTA and AUTO_OTA join modes are similar like you’ve observed, but with one significant difference: when entering/waking from deepsleep the mDot will save/restore the network session to/from flash if it is in AUTO_OTA mode. This is to allow the mDot to go into deepsleep without needing to join every time it wakes up.

In short, AUTO_OTA mode manages the session for you across deepsleep while OTA mode does not. If you prefer, you can use OTA mode and the save/restore session functions to manage the session yourself.

Normally when the mDot is reset or cold-booted, the session is reset. The setPreserveSession function can be used to disable this behavior. The use case here is if there is an external processor interacting with the mDot via AT commands. The mDot can be powered off in between LoRa transactions to save power. The external processor would put the mDot in AUTO_OTA mode, call setPreserveSession(true), and manually save the network session before powering down the mDot. When the mDot gets powered back up, the saved session is restored instead of the session being reset. OTA mode could also be used in this scenario and the external processor would manually save and restore the session around a reset or power down of the mDot.

Hope this helps!

Cheers,

Mike

[Andrew Lindsay]

Thanks for the detailed response.

If I have a mDot::getInstance and soon after a deep sleep call without any network interaction such as a join or send data will this break the session?

Thanks

Andrew

[Mike Fiore]

Andrew,

Are you referring to a situation like this?

mDot state         Session state    
----------         -------------
reset/boot         N/A
  |
getInstance()      OTA mode: session is reset       
  |                AUTO_OTA mode w/preserve session off: session is reset
  |                AUTO_OTA mode w/preserve session on: session restored
  |
deepsleep()        OTA mode: nothing happens
  |                AUTO_OTA mode: session saved
  |
wakeup             OTA mode: nothing happens
  |                AUTO_OTA mode: session restored

In AUTO_OTA mode, the session is saved when going into deepsleep regardless of the state of the session itself. Even if you don’t join or send packets, that session is still going to be saved.

Hope that answers your question!

Cheers,

Mike

• This reply was modified 7 years, 8 months ago by Mike Fiore.

[Andrew Lindsay]

A diagram always helps!

Thanks for this Mike.

Andrew

[Andrew Lindsay]

Following on from this, I have 2 nodes, both using the same version of libraries (mdot 121, mdot-rtos 110, libmDot 14), the first output below is from a mdot that uses the RTC to wake up from deep sleep, the second uses the interrupt pin to wake it up. There are some differences in what is output in the DEBUG and TRACE results, can someone explain why there are differences when it should be identical code within the library that is being executed?

The other difference is that the second device using interrupts to wake up doesn’t appear to send any data and is re-joining the network each time even though the code for both is almost identical and is set to preserve the session. The first one is able to join, send data, sleep, wake, restore session, send data, sleep, etc which is what I’d expect to see.

[INFO] Joining Network
[TRACE] Initiating join…
[TRACE] Join Network – Auto OTA
[TRACE] Join attempt #1
[DEBUG] Send Join Packet with DR0
[TRACE] Number of enabled channels: 3 Mask: 00ff
[TRACE] Check freq: 2 – 868500000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_JOIN_REQ
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 868500000 SF: 12 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 23 bytes 1482 ms
[DEBUG] Time off air: 148200 ms duty-cycle: 1.0 %
[TRACE] Rx Window 1 – Frequency: 868500000 BW: 0 SF: 12
[TRACE] Rx Window 2 – Frequency: 869525000 BW: 0 SF: 12
[TRACE] RxDone -75 30
[TRACE] Rx Packet Type: 1 Size: 33
[TRACE] FRAME_TYPE_JOIN_ACCEPT
[TRACE] mic: d57c91d7 rx: d57c91d7
[DEBUG] Network joined
[TRACE] Computing session keys…
[TRACE] NetID: 0x0E0E0E
[TRACE] DevAddr: 0x1D3FF247
[TRACE] rxDrOff: 0 rx2Dr: 3 rxD1: 1000
[TRACE] Add Channel Frequency 867100000
[TRACE] Add Channel Frequency 867300000
[TRACE] Add Channel Frequency 867500000
[TRACE] Add Channel Frequency 867700000
[TRACE] Add Channel Frequency 867900000
[INFO] Joined Network
[TRACE] Number of enabled channels: 5 Mask: 00ff
[TRACE] Check freq: 6 – 867700000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_DATA_UNCONFIRMED_UP
[DEBUG] UplinkCounter: 0
[TRACE] Encrypting application packet to buffer…
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 867700000 SF: 10 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 22 bytes 370 ms
[DEBUG] Time off air: 370000 ms duty-cycle: 0.1 %
[INFO] send data: 33332e382c32302e33
[DEBUG] Session saved to flash
[DEBUG] wrote 256 bytes
[DEBUG] file size: 256 bytes
[TRACE] 0 : 370000
[TRACE] 1 : 138774
[TRACE] 2 : 0
[TRACE] 3 : 0
[TRACE] configuring RTC Alarm A to wakeup 300 seconds from now
[TRACE] save timers: 138314 369540 0 0 0 138251
[INFO] entering deepsleep (standby) mode 00000037

Lines marked XXX are ones I’ve identified as being extra in this output.

[TRACE] Join Network – OTA
[TRACE] RTC ISR 00000037 00000020 00000020 00000000
[TRACE] restore timers: 0 0 0 0 0 0
[TRACE] Enable milli band
[TRACE] Band 0 : 0
[TRACE] Enable centi band
[TRACE] Band 1 : 0
[TRACE] Enable deci band
[TRACE] Band 2 : 0
[TRACE] Enable vari band
[TRACE] Band 3 : 0
[INFO] Joining Network
[TRACE] Initiating join…
[TRACE] Join Network – Auto OTA
[TRACE] Join attempt #1
[DEBUG] Send Join Packet with DR3
[TRACE] Number of enabled channels: 3 Mask: 00ff
[TRACE] Check freq: 0 – 868100000
[TRACE] Preparing frame
XXX [TRACE] FRAME_TYPE_JOIN_REQ
XXX [TRACE] PACKET: 23 bytes
XXX [TRACE] BUFFER: 00f60000d07ed5b370c59f0000000080005cb98b0b54a2
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 868100000 SF: 9 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 23 bytes 205 ms
[DEBUG] Time off air: 20500 ms duty-cycle: 1.0 %
[TRACE] Rx Window 1 – Frequency: 868100000 BW: 0 SF: 9
[TRACE] Rx Window 2 – Frequency: 869525000 BW: 0 SF: 12
[TRACE] RxDone -75 23
[TRACE] Rx Packet Type: 1 Size: 33
XXX [TRACE] FRAME_TYPE_JOIN_ACCEPT
XXX [TRACE] PAYLOAD SIZE: 33
XXX [TRACE] APPKEY: ec22cbc24733e3397b83c4c9dea685a8
XXX [TRACE] BUFFER: 20d91edf0e0e0e0145601c0301184f84e85684b85e84886684586e8400b6a3bbe0
[TRACE] mic: e0bba3b6 rx: e0bba3b6
[DEBUG] Network joined
[TRACE] Computing session keys…
XXX [TRACE] DNONCE: b95c
XXX [TRACE] ANONCE: d91edf
XXX [TRACE] NETS: dc7f91426ada01eacde85a6a428f5d6d
XXX [TRACE] APPS: 5cccbdd44b1f896a0cf4ca15ada9b6c5
[TRACE] NetID: 0x0E0E0E
[TRACE] DevAddr: 0x1C604501
[TRACE] rxDrOff: 0 rx2Dr: 3 rxD1: 1000
[TRACE] Add Channel Frequency 867100000
[TRACE] Add Channel Frequency 867300000
[TRACE] Add Channel Frequency 867500000
[TRACE] Add Channel Frequency 867700000
[TRACE] Add Channel Frequency 867900000
[INFO] Joined Network
// Data
[TRACE] Number of enabled channels: 5 Mask: 00ff
[TRACE] Check freq: 3 – 867100000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_DATA_UNCONFIRMED_UP
[DEBUG] UplinkCounter: 0
[TRACE] Encrypting application packet to buffer…
XXX [TRACE] PACKET: 14 bytes
XXX [TRACE] BUFFER: 400145601c000000017f87d9f070
[DEBUG] txPower: 14 AntG: 3 radioPower: 11
[INFO] TX Frequency: 867100000 SF: 7 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 14 bytes 46 ms
[DEBUG] Time off air: 46000 ms duty-cycle: 0.1 %
XXX [INFO] sent data to gateway
Sleep
[DEBUG] Session saved to flash
[DEBUG] wrote 256 bytes
[DEBUG] file size: 256 bytes
[TRACE] 0 : 46000
[TRACE] 1 : 12241
[TRACE] 2 : 0
[TRACE] 3 : 0
[TRACE] save timers: 12101 45860 0 0 0 12030
[INFO] entering deepsleep (standby) mode 00000037

Regards

Andrew

[Mike Fiore]

Andrew,

The code path around going to sleep and waking up is slightly different depending on the wakeup method, but it shouldn’t prevent the device from functioning properly.

I think one of two things may be happening. Either the library version actually aren’t the same, or there are major differences in the configuration between the two devices.

Can you confirm the library version of both devices? It would be great if you could log a call to mDot::getId() before joining and include it in the debug output.

Also, if you can post the at&v results from the AT firmware, that would be helpful as well.

Cheers,

Mike

[Author]

Posts