could this be considered a violation of DutyCycle regulations in Zephyr LoRaWAN?

[ayunumm]

Hi everyone,

I'm currently working with LoRaWAN on Zephyr, using Semtech's LoRaMac-Node as the underlying stack. I have a question regarding DutyCycle behavior:

It seems that the DutyCycle's max credits (TimeCredits) are reset every time I rebuild or monitor the device using the west command. In this case, if the device hits a DutyCycle restriction and I perform a rejoin without waiting for the required delay, could this be considered a violation of DutyCycle regulations (in EU868)?

Also, assuming I'm using DR5 and sending 4-byte application payload in EU868, what would be the best way to keep the system running continuously for hours or even days without triggering DutyCycle restrictions? Is there a recommended strategy for staying below the DutyCycle threshold over long periods?

Additionally, I'm interested in displaying DutyCycle-related metrics at the application layer—not just the remaining wait time or consumed time, but the amount of data already transmitted and the estimated amount of data that can still be sent within the current DutyCycle window. Is there a recommended way to implement this in Zephyr, or any insight into how this could be tracked or calculated?

Thanks in advance for your help!

[nordicjm]

It seems that the DutyCycle's max credits (TimeCredits) are reset every time I rebuild or monitor the device using the west command. In this case, if the device hits a DutyCycle restriction and I perform a rejoin without waiting for the required delay, could this be considered a violation of DutyCycle regulations (in EU868)?

Yes it would be, but there is a difference between duty cycle on a single local test device which, presumably, connects to a gateway in the same building, both of which can have the transmit powers limited to low levels vs deployment of a firmware on devices scattered across an area.

Also, assuming I'm using DR5 and sending 4-byte application payload in EU868, what would be the best way to keep the system running continuously for hours or even days without triggering DutyCycle restrictions? Is there a recommended strategy for staying below the DutyCycle threshold over long periods?

You know how much data you are sending, so you can work out the transmit time, then plan your transmission times based around that, it likely should be no faster than once every 10 minutes.