A second SetFemState sent while the first was held for a TX got an
immediate TxBusy, which reached the host before the first request's
reply. With no request IDs, the host could not tell which Set failed.
FEM requests now go through a small ordered queue (Set, Get and their
error replies). Sets still wait for TxDone to be queued and apply
once. Each reply is kept until it can be queued. Capability checks
happen in order at processing time. Only an overflow (more than 4
waiting) replies TxBusy immediately.
Boards own their FEM control through handleCommand() ("get/set
radio.fem.rxgain|txgain"). Use that instead of a parallel set of FEM
virtuals on MainBoard, so any board that implements the commands works
in KISS with no extra code.
- Remove the six FEM virtuals from MainBoard and the board overrides.
- KissModem talks to the board in one adapter. A gain counts as
controllable only if "get" replies exactly "> on" or "> off". "set"
is checked by reading the state back, never by its reply wording.
- SetFemState always replies with the read-back state once the
requested bits pass the capability check.
- Guard the boards' prefs writes against a NULL store. KISS attaches
no prefs, so "set radio.fem.*" would dereference NULL.
- Wio Tracker L1 1W TX gain is exposed again, matching its CLI.
Add SetRxBoostedGain (0x20) / GetRxBoostedGain (0x21, reply 0xA1) and
capability bit 3, the KISS equivalent of the radio.rxgain CLI setting.
It is separate from FEM RX gain; a board may support either or both.
- Support is declared by the driver via a new
RadioLibWrapper::supportsRxBoostedGain() (SX1262, SX1268, LLCC68,
LR1110, LR1121, LR2021), so nothing is written to the radio at boot.
- The set is refused with TxBusy during TX or while host output is
backed up. Otherwise any completed RX packet is delivered first,
because some drivers (LR2021) drop to standby to apply the gain.
- The reply always carries the state read back from the radio.
Driver fixes found along the way, which also affect the radio.rxgain
CLI in regular firmware:
- CustomLR2021 never updated its cached gain state, so the getter
always reported off. It now tracks the applied level per RX path
and rolls RadioLib's cached level back if a write fails.
- CustomLR1110/LR1121 cached the requested state even when the write
failed.
- lr11x0ResetAGC only reapplied the gain when RX_BOOSTED_GAIN was
defined, so a runtime setting was lost on the next AGC reset.
- Wio Tracker L1 1W no longer advertises TX gain control: its setter
drives LORA_PWR_EN, the shared LDO for the SX1262 and the PA, so
"gain off" would power down the radio.
- A SetFemState that arrives mid-TX is now applied after TxDone is
queued, so its reply follows TxDone.
- SetFemState replies (immediate or deferred) are retained until they
fit in the host output queue instead of being dropped, so a change
that took effect is always acknowledged.
- GetFemState replies queue behind an outstanding SetFemState reply;
a further SetFemState returns TxBusy until it clears.
Add SetHardware sub-commands so a host can probe and configure
per-board RF front-end settings:
- GetCapabilities (0x1B): uint32 feature bits (AGC, FEM RX, FEM TX)
- Set/GetAgcResetInterval (0x1C/0x1D): 0-1020 s, 4 s resolution,
0 disables; default stays 30 s
- Set/GetFemState (0x1E/0x1F): apply/value masks for FEM RX (LNA)
and TX (PA) gain; all-or-nothing, Unsupported (0x08) if any
requested bit is not controllable on this board
The AGC scheduler moves from main.cpp into KissModem so it is
configurable and unit-tested. FEM changes that arrive mid-TX are
deferred until the packet ends, since board setters drive FEM pins
directly.
MainBoard gains virtual FEM hooks (canControl/set/is for LNA and PA
gain). Boards that already implemented these methods privately now
expose them as overrides: Heltec V4, V4 R8, T096, Tracker V2,
Station G3 and Wio Tracker L1 1W.
KISS_FIRMWARE_VERSION bumped to 2.
Drop BLE_TX_POWER=0 from the companion envs so they use the default of
4 dBm, like most other variants. The lower power was carried over from
the original Base Duo PR and real-world range is better at the default.
- rename the board class and files to MuziBaseBoard
- uppercase the build flags (MUZI_BASE, MUZI_BASE_SUPERIO)
- name the superIO envs muzi_base_{duo,uno}_superIO_companion_radio_ble so
build.sh picks them up
- set MAX_CONTACTS to 350 like the other variants
- move the pin setup from initVariant() into MuziBaseBoard::begin()
The major rev from 19.x to 20.x breaks Radiolab, so pin it for now. This should fix the failing wio-e5-mini_repeater builds.
ltoa is removed upstream, so it was replaced with snprintf. The p[] buffer is always 16 bytes. Copy/paste for why claude thinks this is fine below, but also if this is broken it wouldn't be new.
```
exp2 in [23, 30] (int_part = mantissa << (exp2 - 23)): this is where int_part can reach its true max, up to 2,147,483,520 — 10 digits. That's what the snprintf bound of 11 (10 digits + NUL) is sized for. But in this branch frac_part is never assigned anything other than its initial 0, so only *p++ = '0' runs for the fraction — 1 char, not 7.
exp2 in [0, 22] (int_part = mantissa >> (23 - exp2)): this is the only branch where frac_part can also be nonzero and enter the 7-digit loop. Here int_part < 2^23 by construction, so it's capped at 7 digits, never 10.
```
Today if a user builds firmware with an incorrect WiFi SSID or password,
they get a generic `WiFi disconnected.` error message.
Extend logging to descirbe the reason that WiFi was disconnected.
I gathered the updated logs for the 3 scenarios below.
```
WiFi: Attempting manual WiFi reconnect...
WiFi: WiFi disconnected (reason=ASSOC_LEAVE). Flagging for reconnect...
WiFi: WiFi disconnected (reason=4WAY_HANDSHAKE_TIMEOUT). Flagging for reconnect...
WiFi: WiFi disconnected (reason=4WAY_HANDSHAKE_TIMEOUT). Flagging for reconnect...
WiFi: WiFi disconnected (reason=4WAY_HANDSHAKE_TIMEOUT). Flagging for reconnect...
```
```
WiFi: WiFi disconnected (reason=NO_AP_FOUND). Flagging for reconnect...
```
```
WiFi: WiFi connected successfully!
WiFi: Got connection
```
agessaman