LoRaWAN: Reporting scheduling failures #7495
Conversation
hasnainvirk
force-pushed
the
scheduling_failure_report
branch
from
956fcd3 to
874f257
Compare
| (void) status; | ||
|
|
||
| if ((schedule_tx() != LORAWAN_STATUS_OK) && nwk_joined()) { | ||
| _scheduling_failure_handler.call(); |
There was a problem hiding this comment.
I think these can be just _scheduling_failure_handler();
|
@kjbracey-arm Can you please review ? |
|
@hasnainvirk Would you mind taking a look at ARMmbed/mbed-os-example-lorawan#88? I'll review this right now and get CI started immediately after. |
| { | ||
| _lora_time.activate_timer_subsystem(queue); | ||
| _lora_phy->initialize(&_lora_time); | ||
|
|
||
| _ev_queue = queue; | ||
| _scheduling_failure_handler = scheduling_failure_handler; |
There was a problem hiding this comment.
Is it fair to say that a null function pointer will never be passed to this function?
There was a problem hiding this comment.
It is an internal API and we always pass a legitimate pointer of the callback that's why probably we don't need a null check here.
|
/morph build |
Build : SUCCESSBuild number : 2654 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 2287 |
Test : SUCCESSBuild number : 2396 |
|
Waiting for @kjbracey-arm / @AnttiKauppila approval |
|
@SeppoTakalo Can you please review this ? |
|
@hasnainvirk Can you rebase to resolve a conflict (another patch for lora caused it) |
It is quite possible that the user request for scheduling an uplink is deferred because of backoff or if it was a CONFIRMED message, a retry may take place on a different datarate and different channel. We didn't have a hook for such deferred scheduling, telling the user whether the async rescheduling worked or not. This commit adds that capability and now we can tell the application if a scheduling failure took place after the original schedule request was accepted.
hasnainvirk
force-pushed
the
scheduling_failure_report
branch
from
874f257 to
b07c3e7
Compare
|
@0xc0170 Rebase done. |
|
/morph build |
Build : SUCCESSBuild number : 2717 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 2351 |
Test : SUCCESSBuild number : 2449 |
…eport LoRaWAN: Reporting scheduling failures
Description
It is quite possible that the user request for scheduling an uplink is deferred because of backoff or if it was a CONFIRMED message, a retry may take place on a different datarate and different channel.
We didn't have a hook for such deferred scheduling, telling the user whether the async rescheduling worked or not. This commit adds that capability and now we can tell the application if a scheduling failure took place after the original schedule request was accepted.
Pull request type
Target Release
Mbed OS 5.10