Implement token bucket duty cycle enforcement

[ViezeVingertjes]

Replaces per-transmission delay with a rolling window token bucket for better regulatory compliance.
Sets default to 10% duty cycle (airtime factor 9.0), the highest common legal limit worldwide(?)

Resolves #817.

[ViezeVingertjes]

We had a discussion in the Dutch community today. Some people didn't care much, others wanted a proper implementation. I'm neutral either way (not even sure if I enabled it myself). Perhaps this could start a broader discussion to decide it once and for all.

[LitBomb]

how does this work for USA where there is no duty cycle limit?

[ViezeVingertjes]

how does this work for USA where there is no duty cycle limit?

The same as it is currently, airtime factor already limits it to the same amount, just less reliable. So both now and with this method, they would need to disable it. (set af 0)

[LitBomb]

whatever the change is, it should not limit duty cycle at any percentage for regions that don't have duty cycle limit.

[ViezeVingertjes]

whatever the change is, it should not limit duty cycle at any percentage for regions that don't have duty cycle limit.

Its probably higher than the current cap you guys have. But a valid point for another issue on if and what the default should be. Perhaps it should be set with the region or something.

[4np]

There is race potential here. Are we sure this is always called from an Arduino single loop context? Or can this also be called by timers, callbacks or interrupts?

[ViezeVingertjes]

Good catch on thinking about thread safety! However, this is not a concern in this case. The updateTxBudget() method is only called from within the Dispatcher::loop() context, which is always executed from the Arduino single-threaded loop() function.

[recrof]

@ViezeVingertjes I welcome proper implemetation of hourly duty cycle for europe, but this needs to be set to 0 by default. we don't want US, AU, NZ and other countries be limited to 10% by default.

[ViezeVingertjes]

@ViezeVingertjes I welcome proper implementation of hourly duty cycle for Europe, but this needs to be set to 0 by default. we don't want US, AU, NZ and other countries be limited to 10% by default.

Hmm, but default AF was 1.0 right? So i feel 10% would reflect the original 'duty cycle' more than 0%?
But disabled would be fine with me too though: eec5ef0

In practice it should already transmit more than with the original AF, so if anything, it shouldn't be less after this change.

[recrof]

Hmm, but default AF was 1.0 right? So i feel 10% would reflect the original 'duty cycle' more than 0%? But disabled would be fine with me too though: eec5ef0

yes, you are right. AF=0 can be dangerous.. AF=1 is optimal, sorry for that.

[ViezeVingertjes]

Hmm, but default AF was 1.0 right? So i feel 10% would reflect the original 'duty cycle' more than 0%? But disabled would be fine with me too though: eec5ef0

yes, you are right. AF=0 can be dangerous.. AF=1 is optimal, sorry for that.

Haha check! thought maybe my thought train was wrong, reverted it -> 1b959a9

[recrof]

Haha check! thought maybe my thought train was wrong, reverted it -> 1b959a9

you reverted it to 9 tho? we need it at 1

[ViezeVingertjes]

Haha check! thought maybe my thought train was wrong, reverted it -> 1b959a9

you reverted it to 9 tho? we need it at 1

Yes; i went off from numbers i saw on my repeaters which maxed out on 9%, but there are more things at play on there. Updated it to 1.0 and cleaned up the commits. a43b0e5

[fschrempf]

@ViezeVingertjes You can simply drop the last two commits, right? First you change it from 1 to 9 and then back from 9 to 1. Except for the simple_secure_chat which was at 2 for some reason at might want to be aligned with the others.

[ViezeVingertjes]

@ViezeVingertjes You can simply drop the last two commits, right? First you change it from 1 to 9 and then back from 9 to 1. Except for the simple_secure_chat which was at 2 for some reason at might want to be aligned with the others.

Done.

[LitBomb]

how does a user know when they exceed the air time factor limit? just a failed send on the radio? any return error code to the clients so the clients can put up error messages to let the users know?