subsys: function" lorawan_get_payload_sizes() " is it working properly?

[ayunumm]

Describe the bug

Hello,
I hope get help or opinions for this issue about Zephyr-based LoRaWAN application.

In my Zephyr-based LoRaWAN application, I aim to keep our messages within roughly 80% of the 1% duty cycle limit to leave room for more time-critical transmissions. (with EU868)

I'm using the " lorawan_get_payload_sizes() " function to check how much payload my device can send, but it seems like the result doesn't reflect duty cycle restrictions as we expected.

Even when the function reports that I have bytes available, the MAC layer still blocks transmission due to duty cycle limitations.

Is this expected behavior? Is lorawan_get_payload_sizes() not designed to account for duty cycle constraints?

What would be the best way to accurately retrieve how much data we can send under current duty cycle conditions?

Regression

• This is a regression.

Steps to reproduce

Relevant log output

Current Datarate: DR_0, Max payload for next: 242 byte, Max payload this datarate: 242 byte  
[00:09:09.147,000] <err> lorawan: LoRaWAN Send failed: Duty-cycle restricted  
ZEPHYR lorawan send failed: -111  
[00:09:10.632,000] <inf> sensors: Sensor 1 value: 129.00  

Current Datarate: DR_0, Max payload for next: 242 byte, Max payload this datarate: 242 byte  
[00:09:11.882,000] <err> lorawan: LoRaWAN Send failed: Duty-cycle restricted  
ZEPHYR lorawan send failed: -111  
[00:09:13.367,000] <inf> sensors: Sensor 1 value: 129.00  

Current Datarate: DR_0, Max payload for next: 242 byte, Max payload this datarate: 242 byte  
[00:09:14.647,000] <err> lorawan: LoRaWAN Send failed: Duty-cycle restricted  
ZEPHYR lorawan send failed: -111  
[00:09:16.132,000] <inf> sensors: Sensor 1 value: 129.00  

Current Datarate: DR_0, Max payload for next: 242 byte, Max payload this datarate: 242 byte  
[00:09:17.382,000] <err> lorawan: LoRaWAN Send failed: Duty-cycle restricted  
ZEPHYR lorawan send failed: -111  
[00:09:18.867,000] <inf> sensors: Sensor 1 value: 27.00

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

• Host OS: Windows 11 Pro (with Ubuntu via WSL2)
• Target Board: ESP32-S3 DevKitC-1 v1.1
• LoRa Transceiver Module: XL1276-POI
• Zephyr Source Path: Function void lorawan_get_payload_sizes(uint8_t *max_next_payload_size, uint8_t *max_payload_size) located at /zephyrproject/zephyr/subsys/lorawan/lorawan.c
• Build System: Zephyr RTOS using west and CMake

Additional Context

// lorawan_get_payload_sizes(.h file)
(/zephyrproject/zephyr/include/zephyr/lorawan/lorawan.h)
/
@brief Get the current payload sizes

Query the current payload sizes. The maximum payload size varies with
datarate, while the current payload size can be less due to MAC layer
commands which are inserted into uplink packets.

@param max_next_payload_size Maximum payload size for the next transmission
@param max_payload_size Maximum payload size for this datarate
/
void lorawan_get_payload_sizes(uint8_t *max_next_payload_size,
uint8_t *max_payload_size);

---

// lorawan_get_payload_sizes (.c file)
(/zephyrproject/zephyr/subsys/lorawan/lorawan.c)
void lorawan_get_payload_sizes(uint8_t *max_next_payload_size,
uint8_t *max_payload_size)
{
LoRaMacTxInfo_t tx_info;

/* QueryTxPossible cannot fail */
(void) LoRaMacQueryTxPossible(0, &tx_info);

*max_next_payload_size = tx_info.MaxPossibleApplicationDataSize;
*max_payload_size = tx_info.CurrentPossiblePayloadSize;

}

// typedef struct sLoRaMacTxInfo
( \zephyrproject\modules\lib\loramac-node\src\mac\LoRaMac.h)
typedef struct sLoRaMacTxInfo
{
Size of the application data payload which can be transmitted.
uint8_t MaxPossibleApplicationDataSize;
/
The current maximum possible payload size without MAC commands
which is dependent on the current datarate.
uint8_t CurrentPossiblePayloadSize;
}LoRaMacTxInfo_t;

// LoRaMacQueryTxPossible( uint8_t size, LoRaMacTxInfo_t* txInfo );
(\zephyrproject\modules\lib\loramac-node\src\mac\LoRaMac.h)
and
(\zephyrproject\modules\lib\loramac-node\src\mac\LoRaMac.c)

\brief Queries the LoRaMAC if it is possible to send the next frame with
a given application data payload size. The LoRaMAC takes scheduled
MAC commands into account and reports, when the frame can be send or not.

\param [IN] size - Size of application data payload to be send next

\param [OUT] txInfo - The structure \ref LoRaMacTxInfo_t contains
information about the actual maximum payload possible
( according to the configured datarate or the next
datarate according to ADR ), and the maximum frame
size, taking the scheduled MAC commands into account.

\retval LoRaMacStatus_t Status of the operation. When the parameters are
not valid, the function returns \ref LORAMAC_STATUS_PARAMETER_INVALID.
In case of a length error caused by the application data payload in combination
with the MAC commands, the function returns \ref LORAMAC_STATUS_LENGTH_ERROR.
In this case its recommended to send a frame without application data to flush
the MAC commands. Otherwise the LoRaMAC will prioritize the MAC commands and
if needed it will skip the application data. Please note that if MAC commands do
not fit at all into the payload size on the related datarate, the LoRaMAC will
automatically clip the MAC commands.
In case the query is valid, and the LoRaMAC is able to send the frame,
the function returns \ref LORAMAC_STATUS_OK.

LoRaMacStatus_t LoRaMacQueryTxPossible( uint8_t size, LoRaMacTxInfo_t* txInfo );

[github-actions[bot]]

Hi @ayunumm! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[nordicjm]

you are trying to send 242 bytes of data over LoRa every seconds and wondering why it is failing ??

[ayunumm]

Hi, thank you for your answer.
The 242-byte value shown corresponds to the maximum payload size for the current data rate 5. Specifically, uint8_t *max_next_payload_size (maximum payload for the next transmission) and uint8_t *max_payload_size (maximum payload per transmission at this data rate). These values were obtained using the Zephyr function:

void lorawan_get_payload_sizes(uint8_t *max_next_payload_size, uint8_t *max_payload_size);

My question is not about why the duty cycle limit was reached, but rather: Why does max_next_payload_size still report 242 bytes but not 0, even when the system is duty-cycle restricted and unable to transmit? (The reason I reached the duty cycle limit is because I intentionally set the payload size to 240 bytes in order to test whether this function behaves as expected.)

If this function is not designed to reflect duty cycle constraints, then I’m unclear on what max_next_payload_size actually represents and what its intended purpose is. Is it purely a theoretical value based on data rate, or should it reflect real transmission availability?

[nordicjm]

@JordanYates @martinjaeger for comment

[JordanYates]

lorawan_get_payload_sizes is just a wrapper around the loramac-node LoRaMacQueryTxPossible function.
The documentation isn't super clear, but my understanding is that the function is only concerned with calculating the payload size based on the current datarate, and doesn't take into account any duty cycle limits.

i.e., it will tell you whether your 50 byte payload can ever be sent at the current data rate, just not whether it can be sent right now.

[ayunumm]

Thank you so much.