Duty cycle default moet de ETSI sub-band van de ingestelde frequentie volgen #4

Probleem

De uitgeleverde default is airtime_factor = 1.0, wat neerkomt op 50% duty cycle. get dutycycle rapporteert dat ook zo. De default frequentie is -D LORA_FREQ=869.618 (platformio.ini:29), die in de 869.4 tot 869.65 MHz sub-band valt. ETSI EN 300 220-2 begrenst die sub-band op 10%.

De default staat dus vijf keer hoger dan wat op de eigen default frequentie is toegestaan. Elke EU-operator moet dit met de hand per node aanpassen, en de waarde is niet vindbaar tenzij je al weet dat af over duty cycle gaat.

Upstream ligt hiervoor meshcore-dev#3351 open, met een enkele build-constante MAX_DUTY_CYCLE (default 10). Dat getal klopt voor 869.618, maar niet voor de rest van de band: 868.5 mag 1%, 869.0 mag 0.1%, en een US of ANZ build kent de limiet helemaal niet. Een enkele constante kan die spreiding niet uitdrukken.

Voorstel

De limiet afleiden uit de ingestelde frequentie in plaats van uit een build-constante.

Nieuw src/helpers/DutyCycleLimits.h / .cpp met twee vrije functies:

float getMaxDutyCyclePercent(float freq_mhz);   // 100.0 = geen limiet
float dutyCycleToAirtimeFactor(float percent);  // (100/dc) - 1

De tabel geldt alleen voor 863.0 tot 870.0 MHz, daarbuiten is het resultaat 100 en verandert er niets:

Dit dekt ook de land-presets binnen de EU. Een preset die alleen in SF verschilt, zoals NL op SF7, zit op dezelfde sub-band als de algemene EU-preset en krijgt dus dezelfde limiet. SF, BW en CR raken de regelgeving niet, alleen de frequentie.

Nieuwe pref uint8_t dutycycle_auto, default 1, in src/helpers/CommonCLI.h en examples/companion_radio/NodePrefs.h, serializer-key dc_auto:

• set dutycycle <n> en set af <n> zetten hem op 0, de handmatige waarde blijft dan leidend
• set dutycycle auto zet hem terug op 1
• get dutycycle rapporteert de effectieve waarde en of die auto of handmatig is

De vijf getAirtimeBudgetFactor() overrides (companion_radio, simple_repeater, simple_room_server, simple_secure_chat, simple_sensor) geven bij dutycycle_auto de uit _prefs.freq afgeleide factor terug, anders _prefs.airtime_factor. Dispatcher::updateTxBudget() evalueert die functie bij elke aanroep opnieuw (src/Dispatcher.cpp:42), dus de limiet volgt de frequentie meteen na set freq of set radio, zonder herstart en zonder wijziging in Dispatcher.

Gedragsverandering

dutycycle_auto staat ook aan na migratie van een bestaande prefs-file. Een node die vandaag op 869.618 met de default 50% draait, zakt na de update naar 10%. Dat is het doel van de wijziging, maar het is een stille verandering voor bestaande nodes. Wie bewust hoger wil zitten zet dat met set dutycycle <n> terug, en die keuze blijft dan staan.

Buiten scope

applyTempRadioParams (src/helpers/CommonCLI.cpp:251) zet een tijdelijke frequentie zonder _prefs.freq aan te raken. Tijdens tempradio blijft de limiet dus die van de opgeslagen frequentie. Ik laat dat hier liggen, het is een aparte wijziging.

Testen

getMaxDutyCyclePercent is een pure functie zonder radio-afhankelijkheid en krijgt een unit test in test/: grenswaarden per sub-band, de gaten, en frequenties buiten 863 tot 870. De rest is compile-coverage via de build matrix, want [env:native] compileert Dispatcher.cpp niet.