LoRa duty cycle on LoRaWAN_End_Node

[Feanoer]

I'm working on stm32wl55 Nucleo-64.

I have doubts regarding the mechanism by which the duty cycle control is implemented in the project.

I am sending a test LoRa message with a payload of 231 Bytes, using DR5 and SF7 every 10 seconds (whereas a 1% duty cycle should enforce a retransmission approximately every 36 seconds).

What happens is highlighted by the log below:

###### ========== MCPS-Confirm =============
###### U/L FRAME:0042 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
450s717:TX on freq 868100000 Hz at DR 5
450s725:SEND REQUEST
451s109:MAC txDone
451s110:RX_C on freq 869525000 Hz at DR 0
456s086:RX_1 on freq 868100000 Hz at DR 5
456s133:IRQ_RX_TX_TIMEOUT
456s133:MAC rxTimeOut
456s133:RX_C on freq 869525000 Hz at DR 0
457s137:RX_2 on freq 869525000 Hz at DR 0
457s335:IRQ_RX_TX_TIMEOUT
457s335:MAC rxTimeOut
457s335:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0043 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
460s725:TX on freq 868500000 Hz at DR 5
460s733:SEND REQUEST
461s117:MAC txDone
461s118:RX_C on freq 869525000 Hz at DR 0
466s094:RX_1 on freq 868500000 Hz at DR 5
466s141:IRQ_RX_TX_TIMEOUT
466s141:MAC rxTimeOut
466s141:RX_C on freq 869525000 Hz at DR 0
467s145:RX_2 on freq 869525000 Hz at DR 0
467s343:IRQ_RX_TX_TIMEOUT
467s343:MAC rxTimeOut
467s343:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0044 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
470s733:TX on freq 868500000 Hz at DR 5
470s741:SEND REQUEST
471s125:MAC txDone
471s125:RX_C on freq 869525000 Hz at DR 0
476s102:RX_1 on freq 868500000 Hz at DR 5
476s149:IRQ_RX_TX_TIMEOUT
476s149:MAC rxTimeOut
476s149:RX_C on freq 869525000 Hz at DR 0
477s153:RX_2 on freq 869525000 Hz at DR 0
477s351:IRQ_RX_TX_TIMEOUT
477s351:MAC rxTimeOut
477s351:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0045 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
480s741:TX on freq 868100000 Hz at DR 5
480s749:SEND REQUEST
481s132:MAC txDone
481s133:RX_C on freq 869525000 Hz at DR 0
486s110:RX_1 on freq 868100000 Hz at DR 5
486s157:IRQ_RX_TX_TIMEOUT
486s157:MAC rxTimeOut
486s157:RX_C on freq 869525000 Hz at DR 0
487s161:RX_2 on freq 869525000 Hz at DR 0
487s359:IRQ_RX_TX_TIMEOUT
487s359:MAC rxTimeOut
487s359:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0046 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
490s749:TX on freq 868300000 Hz at DR 5
490s756:SEND REQUEST
491s140:MAC txDone
491s141:RX_C on freq 869525000 Hz at DR 0
496s118:RX_1 on freq 868300000 Hz at DR 5
496s165:IRQ_RX_TX_TIMEOUT
496s165:MAC rxTimeOut
496s165:RX_C on freq 869525000 Hz at DR 0
497s168:RX_2 on freq 869525000 Hz at DR 0
497s367:IRQ_RX_TX_TIMEOUT
497s367:MAC rxTimeOut
497s367:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0047 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
500s756:Next Tx in : ~16 second(s)
510s756:Next Tx in : ~6 second(s)
520s756:TX on freq 868100000 Hz at DR 5
520s764:SEND REQUEST
521s148:MAC txDone
521s149:RX_C on freq 869525000 Hz at DR 0
526s125:RX_1 on freq 868100000 Hz at DR 5
526s172:IRQ_RX_TX_TIMEOUT
526s172:MAC rxTimeOut
526s172:RX_C on freq 869525000 Hz at DR 0
527s176:RX_2 on freq 869525000 Hz at DR 0
527s375:IRQ_RX_TX_TIMEOUT
527s375:MAC rxTimeOut
527s375:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0048 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
530s764:Next Tx in : ~25 second(s)
540s764:Next Tx in : ~15 second(s)
550s764:Next Tx in : ~5 second(s)
560s764:TX on freq 868300000 Hz at DR 5
560s772:SEND REQUEST
561s156:MAC txDone
561s157:RX_C on freq 869525000 Hz at DR 0
566s133:RX_1 on freq 868300000 Hz at DR 5
566s180:IRQ_RX_TX_TIMEOUT
566s180:MAC rxTimeOut
566s180:RX_C on freq 869525000 Hz at DR 0
567s184:RX_2 on freq 869525000 Hz at DR 0
567s382:IRQ_RX_TX_TIMEOUT
567s382:MAC rxTimeOut
567s382:RX_C on freq 869525000 Hz at DR 0

###### ========== MCPS-Confirm =============
###### U/L FRAME:0049 | PORT:10 | DR:5 | PWR:7 | MSG TYPE:UNCONFIRMED
570s772:Next Tx in : ~23 second(s)
580s772:Next Tx in : ~13 second(s)
590s772:Next Tx in : ~3 second(s)
600s772:TX on freq 868100000 Hz at DR 5
600s780:SEND REQUEST
601s164:MAC txDone
601s165:RX_C on freq 869525000 Hz at DR 0
606s141:RX_1 on freq 868100000 Hz at DR 5
606s188:IRQ_RX_TX_TIMEOUT
606s188:MAC rxTimeOut
606s188:RX_C on freq 869525000 Hz at DR 0
607s192:RX_2 on freq 869525000 Hz at DR 0
607s390:IRQ_RX_TX_TIMEOUT
607s390:MAC rxTimeOut
607s390:RX_C on freq 869525000 Hz at DR 0

the data is actually sent every 10 seconds for a long period of time (about 500 seconds) until it is limited by the duty cycle as indicated by the "Next Tx in" prints. I am wondering how the control works in the code? When LmHandlerSend returns  LORAMAC_HANDLER_DUTYCYCLE_RESTRICTED? Is there a time window within which the number of transmissions is evaluated, and if they are too many, they are then limited?

[STTwo-32 · Accepted solution]

Hello @Feanoer 

The duty cycle control works by monitoring the time on air for each transmission and ensuring that the cumulative on-air time does not exceed the allowed duty cycle limit within the defined time period. When the limit is reached, the stack enforces a delay before allowing further transmissions.

Best Regards.

STTwo-32