LoRaWAN fix over consumption on scheduled tx

[hallard]

Summary of changes

Put Radio into sleep mode when waiting for scheduled transmit packet

Impact of changes

When TX packet send is scheduled, Radio is not put into sleep mode waiting time to TX. This is causing overconsumption. In majority of case the impact is minimal because radio packet is sent quickly, but in case of failed join and Duty Cycle activated (device not declared on NS or no network) the join process delay next try on each attempt and it can be very long causing overconsumption and draining battery.

On STM32WL consumption is 650uA instead 1.5uA waiting time to send packet this PR put the radio into sleep mode in the interval.

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@jeromecoutant @0xc0170

---

[jeromecoutant]

Should we request a review from ARMmbed/mbed-os-example-lorawan#227 actors ?
or ARMmbed/mbed-os-example-lorawan#222 ?

[hallard]

Not sure it's related because it's happening only in between "We want to send a packet" and "we send the packet" so in 99% of time delay in between is very short (so related impact).

Except is on Network Join phase, where each join retry is delayed to avoid flooding network (see below).

[DBG ][LSTK]: Initiating OTAA
[DBG ][LSTK]: Sending Join Request ...
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: TX: Channel=2, TX DR=5, RX1 DR=5
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 868500000
[DBG ][LMAC]: RX2 slot open, Freq = 869525000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: TX: Channel=1, TX DR=4, RX1 DR=4
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 868300000
[DBG ][LMAC]: RX2 slot open, Freq = 869525000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: DC enforced: Transmitting in 5145 ms
[DBG ][LMAC]: TX: Channel=1, TX DR=3, RX1 DR=3
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 868300000
[DBG ][LMAC]: RX2 slot open, Freq = 869525000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: DC enforced: Transmitting in 13900 ms
[DBG ][LMAC]: TX: Channel=1, TX DR=2, RX1 DR=2
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 868300000
[DBG ][LMAC]: RX2 slot open, Freq = 869525000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: DC enforced: Transmitting in 30554 ms
[DBG ][LMAC]: TX: Channel=2, TX DR=1, RX1 DR=1
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 868500000
[DBG ][LMAC]: RX2 slot open, Freq = 869525000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: DC enforced: Transmitting in 75529 ms
[DBG ][LMAC]: TX: Channel=2, TX DR=0, RX1 DR=0
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 868500000

But does not hurt to give a try.

[0xc0170]

Thanks @jeromecoutant for referencing these 2 issues and going back to one of them. Lets see if anyone responds.

[0xc0170]

CI started

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️