You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement proposal related to a problem? Please describe.
The current implementation of lorawan_send only waits for the transmission to complete if the LORAWAN_MSG_CONFIRMED flag is set. For unconfirmed transmissions, the application is free to call lorawan_send again before the receive windows for the first transmissions have finished, resulting in lorawan_send returning -EBUSY.
Ideally there would be some application level way to wait until the stack is ready to accept new commands/transmissions.
This can be done without changes to the stack as McpsConfirm is already called when all transmissions complete.
Describe the solution you'd like
The simplest solution I have identified is forlorawan_send to always wait on the mcps_confirm_sem, regardless of the confirmed flag. This would add some application level latency for unconfirmed transitions if the application was already guaranteeing sufficient packet spacing.
Alternative solutions include:
Adding an additional flag to signify the driver should wait for unconfirmed transmissions to complete.
Adding a new function that blocks until the stack is ready to accept new commands.
I'm not sure if the second alternative is feasible, as it sounds like waiting on a boolean flag.
Describe alternatives you've considered
The application could either wait for some fixed time period after each unconfirmed transmission, or delay and retry if -EBUSY is returned. Neither solution is very nice, as the LoRaWAN driver already knows when the stack is ready again.
The text was updated successfully, but these errors were encountered:
Wait for MAC operations to complete when transmitting. Unconfirmed
messages still open receive windows and can cause error conditions,
which are currently dropped.
It is also possible for a second send to be requested before the first
one has finished processing, which results in `LORAMAC_STATUS_BUSY`.
Empty frames (due to insufficient payload space) now also block until
the MAC layer is ready to accept new commands.
This change means the application no longer needs to guess-and-check
when it is possible to send unconfirmed messages.
Fixes#33456.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
jmahkye
pushed a commit
to cdo2com/zephyr
that referenced
this issue
Apr 20, 2021
Wait for MAC operations to complete when transmitting. Unconfirmed
messages still open receive windows and can cause error conditions,
which are currently dropped.
It is also possible for a second send to be requested before the first
one has finished processing, which results in `LORAMAC_STATUS_BUSY`.
Empty frames (due to insufficient payload space) now also block until
the MAC layer is ready to accept new commands.
This change means the application no longer needs to guess-and-check
when it is possible to send unconfirmed messages.
Fixeszephyrproject-rtos#33456.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Is your enhancement proposal related to a problem? Please describe.
The current implementation of
lorawan_send
only waits for the transmission to complete if theLORAWAN_MSG_CONFIRMED
flag is set. For unconfirmed transmissions, the application is free to calllorawan_send
again before the receive windows for the first transmissions have finished, resulting inlorawan_send
returning-EBUSY
.Ideally there would be some application level way to wait until the stack is ready to accept new commands/transmissions.
This can be done without changes to the stack as
McpsConfirm
is already called when all transmissions complete.Describe the solution you'd like
The simplest solution I have identified is for
lorawan_send
to always wait on themcps_confirm_sem
, regardless of the confirmed flag. This would add some application level latency for unconfirmed transitions if the application was already guaranteeing sufficient packet spacing.Alternative solutions include:
I'm not sure if the second alternative is feasible, as it sounds like waiting on a boolean flag.
Describe alternatives you've considered
The application could either wait for some fixed time period after each unconfirmed transmission, or delay and retry if
-EBUSY
is returned. Neither solution is very nice, as the LoRaWAN driver already knows when the stack is ready again.The text was updated successfully, but these errors were encountered: