Airtime default is not compliant with EU radio duty cycle regulation

[j0uni]

The default Airtime setting "1" is not compliant with EU duty cycle requirement which says duty cycle can be max 10%. The default value gives 50% duty cycle.

We need to manually configure these to all repeaters being installed, but it would be much nicer if this could be done in the repeater setup process. Also many might not understand this legal requirement.

Perhaps add new preset by splitting EU/UK Narrow to EU Narrow or UK Narrow. Then in EU Narrow it would command the af to 9 which is 10% duty cycle? @liamcottle

Perhaps also update the CLI documentation to describe the "af" setting - what it means actually as duty cycle?

[weebl2000]

Perhaps also update the CLI documentation to describe the "af" setting - what it means actually as duty cycle?

See PR #1961 - it will deprecate AF in favor of get/set dutcycle command.

[j0uni]

@weebl2000 cool, but dunno if it is a good idea to deprecate the af command?

I made a PR for documentation update regarding this already #2048

[j0uni]

Documentation is now updated.

However I see this as important thing to take into account - now the defaults are illegal in EU.

[j0uni]

It seems the default will be 50% in 1.15 which is not legal in EU. 517f2f1

@liamcottle please separate the EU settings to own group at the mobile app and when user selects those, set duty cycle to 10% to be compliant. Otherwise MeshCore can get bad reputation in EU.

[bartass4x]

I think it will be nice to see a chUtil parameter in % in RPT status.

[Blergo]

Perhaps add new preset by splitting EU/UK Narrow to EU Narrow or UK Narrow. Then in EU Narrow it would command the af to 9 which is 10% duty cycle?

The limit is 10% in UK also so it would not be needed to split the preset?

[j0uni]

The lack of response from the project owners is concerning on this issue.

I mean, this is not big task to do. And on the other hand that MeshCore being basically illegal in EU/UK by defaults should be high priority thing to fix.

[liamcottle]

@j0uni

The lack of response from the project owners is concerning on this issue.

I mean, this is not big task to do. And on the other hand that MeshCore being basically illegal in EU/UK by defaults should be high priority thing to fix.

Duty cycle for companions is not supported in the app at this time. It will be added in a future update.

The radio presets did not include anything related to duty cycle because at the time the app presets were implemented, the firmware used something called airtime factor, which was severely more restrictive than duty cycle should be.

MeshCore being basically illegal in EU/UK by default

As far as I'm aware, the firmware not having the restriction in place by default shouldn't mean it's illegal by default. It would however be illegal for users in those regions to exceed the limit when transmitting.

It's unlikely that a user would exceed the legal duty cycle limits (afaik at 10% it's 6 minutes per hour) unless they were intentionally being abusive or spammy to the network.

However, now that we have a better duty cycle implementation that was added in #1297 I'll look to add duty cycle to the radio presets and implement setting this in the app.

[github-actions]

This issue is stale because it has been open for 60 days with no activity. Remove the stale label or add a comment if this issue is still relevant, otherwise this issue will automatically close in 7 days.

[efiten]

Still relevant. Opened #3351 against dev for the default itself.

One detail that I think sharpens the case, since the discussion above centred on whether users would realistically exceed the limit: the default frequency and the default duty cycle are inconsistent with each other in the same build. platformio.ini:29 ships -D LORA_FREQ=869.618, which sits in the 869.4 to 869.65 MHz sub-band. Under ETSI EN 300 220-2 V3.2.1 that sub-band is capped at 10%. The EU868 limits per sub-band are 0.1% (863-865), 1% (865-868), 1% (868-868.6), 0.1% (868.7-869.2), 10% (869.4-869.65) and 1% (869.7-870); table and standard reference here: https://www.actility.com/understanding-duty-cycle-lorawan/

So the default is 5x the limit that applies to the frequency the firmware itself defaults to. That holds regardless of how much traffic a node actually carries, which is why I think it is worth fixing as a default rather than leaving it to per-node configuration.

The PR keeps it to one constant. MAX_DUTY_CYCLE (percent, default 10) in Dispatcher.h, converted to an airtime factor with the same formula set dutycycle already uses, applied to the five node types that hardcoded 1.0 and to the Dispatcher base class fallback which also returned 1.0. Regions without a duty cycle limit can build with -D MAX_DUTY_CYCLE=100. Nothing about the stored preference or the CLI commands changes, and existing nodes keep their configured value.

Two things I ran into while reading the code that are separate from the default, noted in the PR and not addressed there:

• Dispatcher::updateTxBudget() is a token bucket that starts full with a ceiling of one full window's allowance, so a worst-case hour can carry the full bucket plus a window of refill, roughly 2x the configured duty cycle. ETSI measures over a one hour observation period.
• The constrain(airtime_factor, 0, 9.0f) sanitisation only runs in loadPrefsInt(), the legacy /com_prefs loader. The /prefs.json path does not clamp.

Happy to split either into its own issue if that is preferred.