Setting Trials

A repeater can test its own settings on live traffic. For one setting it runs the current value (A) and one alternative (B) in alternating blocks, scores each with the packets it handled, and keeps the better one. Each setting is tested alone, so a result can be traced to a single change.

Run one

On a repeater, from the CLI screen or the beebo-cli channel:

settings routing.tuning.trial.enabled on
> on

That is all. monitor tuning trial shows where it stands. To run only some of the switches, name them: monitor tuning trial start lna cad (or all). Turning a trial on also sets what it needs on the node:

• It enables the monitor and the capture kinds a trial writes (tuning, events, radio changes), and turns packet capture off so that a long run does not fill the ring.
• If the transmit power is under 16 dBm it posts a warning. Trial results at a power that underdrives the amplifier are not worth much. Fix it with settings radio.txpower 18.
• If the node hears too little traffic it posts trial waiting for traffic and starts by itself when traffic arrives.

Stop at any time with monitor tuning trial stop. A reboot stops a trial as well, because the trial settings are not saved. A winner that was already decided stays.

What gets tested

The default profile, main, tests four settings, each against one alternative:

Setting	A (current)	B	Why it is in
LNA (fem.rxgain)	as stored	on	Sensitivity against tolerance to interference: site dependent.
CAD (radio.cad)	as stored	on	Channel-activity detection before sending.
TX delay (routing.txdelay)	as stored	1.0	Spread of retransmissions, to avoid collisions.
Retry (routing.retry)	as stored	one retry at coding rate 4/5	Whether a retry rescues forwards that got no echo.

A setting whose alternative already equals the stored value is skipped. The exhaustive profile tests all twelve settings with their full lists, which takes much longer:

settings routing.tuning.trial.profile exhaustive
> exhaustive

A profile change is lost at a reboot, which returns the node to main. The twelve switches and their values are listed in the Trial Reference.

How long it takes

The node sizes each trial to the traffic it counts, so a busy node decides quickly and a quiet one takes a day or more per setting. The start line says what to expect:

beebo-mr: trial cad start profile=main a=0 b=1 blocks=260 block=493s

Here: 260 blocks of 493 seconds, 36 hours at most for that setting, fewer if the evidence settles earlier.

Results

Result	Meaning
keep_a	B was no better. The current value stays.
adopt_b	B was clearly better. The node switched to it, and keeps it across reboots.
inconclusive, undecided	Not enough evidence. The current value stays.
skipped_same	B equals the current value, so there was nothing to compare.
skipped_no_control	The node cannot control that setting (for example the LNA on a board without LNA control), so there was nothing to compare.
skipped_underpowered	The traffic is too low for the schedule to decide inside the 72 hour cap. The trial is skipped instead of running to inconclusive.
alive_a, alive_b	One side heard almost nothing against the other. The side that hears wins at once (see the dead-side check in the Trial Reference).
aborted_changed	The setting was changed by hand, or the trial was disabled, while it ran. The setting is restored.
aborted_guardrail	The packet pool guardrail tripped. A is kept and the sequence goes on.
aborted_idle	The channel was too quiet to decide. A is kept, the switch stays pending and runs again an hour later.

The result line carries the score gain of B over A and its standard error. To read the records (per-block scores, confidence, noise), pull them and analyze them from the command line:

$ beebo monitor pull
$ beebo analyze tuning trial

The options, the report columns and the statistics are in the Trial Reference.

Companion role

Trials run in repeater role only. A companion answers ERR: needs role 'repeater', node is 'companion'.