Use RX-only radio recovery and feed the repeater reboot watchdog after MeshCore parsing. Default to 24 hours, apply temporary watchdog and advert intervals in RAM, and report temporary durations as days, hours, and minutes. Add regression coverage and an ESP-NOW bridge setup guide.
Integrate ExpressLRS TX module support and its stacked ESP32 heap changes.
Use the approved Linkflow calibration (17-30 dBm), preserve the PA drive
and output path after radio recovery, and keep LoRa OTA enabled.
Preserve stored ACLs and filters on allocation failure, release owned
client/filter buffers, service heap OTA contexts on Companions, release
self-serving workspaces after TempRadio, and reset staged-resume state
when a context is released. Keep manual staging and active operations
alive. Account for all moved allocations in the runtime RAM gate.
Validation: 1,393 native cases; radio-power, heap-context, ACL persistence,
shared-queue transfer, display/inbox, radio receive, and memory regressions.
Firmware builds passed for Linkflow, Heltec V2 Companion, T-Beam MQTT
repeater, Heltec V4 R8 MQTT repeater, RAK4631 repeater, and Indicator Full.
Physical verification awaits access to the currently offline lab Pi.
Default to retained history with a separate pending count, and add persistent display.inbox CLI modes for history, pending, and unread. Preserve browsing while clients are connected and show the active USB or Bluetooth connection.
Fixes#5
Persist separate display modes and timeouts in seconds for battery and USB power, expose four controls in WebConfig and CLI, and apply one shared policy across display-equipped roles.
Detect R8 external power from a USB host or calibrated battery voltage above 4.21 V, with cached sampling and hysteresis. Add policy, persistence, browser, and R8 power-detection regression coverage.
Accept the upstream empty-prefix neighbor.remove command after whitespace normalization while preserving invalid-key checks. Cover repeater and room-server removal paths with regression tests.
Fixes#8
Hardware captures show that a median and lower quartile can follow the interferer while the 12.5th percentile retains the quiet floor. Use that estimate with existing weighting and bounded rise recovery. Wait for settling after every RX re-arm and allow thirty seconds for a complete idle-sample block.
Add captured-sample, low-tail limitation, and real CLI setter regressions. Preserve RXPS intent when parsing an off command with trailing whitespace. All 162 native cases and 24 Python regressions pass.
Port the measured RXPS model without changing Cascade wire preambles or automatically enabling experimental levels. Use a spaced weighted median with bounded calibration windows, preserve packet ownership across CAD, and check actual SX126x receive mode before recovery.
Preserve Cascade sleep and radio fixes, integrate the new sensor and board profiles, and correct BSEC script inheritance and the MKE UART pin conflict. Native regressions, production-method/SPI harnesses, and ESP32, nRF52, and STM32 builds pass. Hardware comparison and fault-injection validation are recorded privately.
List limited public-key prefixes, reasons, and wait times in bounded pages, with full-key details for targeted clearing. Queries preserve quotas and recovery timers.
Validated with 71 native tests, Full repeater and room-server builds, and a 909.500 MHz RF test covering 10 forwarded adverts, 2 blocked adverts, and forwarding after targeted clear.
Use measured text rows for companion and repeater layouts, retain the V4 6px footer, and add overlap and navigation regressions. Correct the MQTT logging sleep documentation contract test.
The variant carried a "classic ESP32 DRAM strip": MAX_CLIENTS cut from 32 to
2, the flood rule engine and group moderation compiled out, and the filter,
scope and moderation tables cut to a single slot each. All of it existed to
squeeze fixed .bss tables into classic ESP32's ~124 KiB static DRAM window.
Those tables now live on the heap, so the strip buys nothing. Removing it also
clears a real trap: with two client slots, once both held a protected manager
(admin, region manager or filter manager) putClient() could no longer allocate,
and every further admin login was refused with no reply to the operator.
Static DRAM with the full feature set restored:
70,764 / 124,580 occupied, 53,816 free (8,192 required)
The SX127x has two output pins and they accept different power ranges:
RFO takes -4 to 15 dBm, PA_BOOST 2 to 17. RadioLib picks RFO on its own
below 2 dBm, but above that it has no way to know which pin a board
actually uses, so it defaults to PA_BOOST.
A board wired to RFO_HF whose levels fall in the overlap therefore comes
out of the wrong pin with no error anywhere. ExpressLRS layouts flag this
as "radio_rfo_hf"; the Radiomaster Bandit is one, with radio levels of
[2, 6, 9, 10] sitting squarely in the range both paths accept.
force_rfo passes RadioLib's forceRfo through for both the fixed drive level
and the per-step table. std_init()'s begin() always configures PA_BOOST, so
beginPowerControl() is what moves an RFO board over; nothing transmits in
between.
Not every external-PA board parks its radio at a fixed drive level. Where
the amplifier is driven somewhere other than its floor, the radio's own
output steps with the requested power as well, and the board describes that
with a second table paired to the first. ExpressLRS layouts call this
"power_values2"; it is independent of dual-band operation, and appears on
single-band modules such as the Radiomaster Bandit.
An optional radio_dbm array supplies one radio output level per entry in the
level table. When present the fixed drive level is unused, and each power
change sets the radio before moving the amplifier so the PA is never asked
to pass a level the radio has already exceeded.
Values go to the SX1276 on the PA_BOOST path. A board wired to RFO_HF would
need RadioLib's useRfo argument plumbed through, which this does not do.
An ExpressLRS 900 MHz transmitter module: ESP32-D0WDQ6, 4 MB flash, SX1276
driving an external PA through a DAC gain input on GPIO26.
Pin values come from the ExpressLRS hardware layout for this target
(Unified_ESP32_900_TX). The board brings out only RX_EN, so RadioLib's
single-pin RF switch handling covers it. Note GPIO12 is both RX_EN and the
MTDI flash-voltage strapping pin, so it must stay low through reset.
Verified on hardware: boots, radio initialises, TX power changes take
effect and are rejected outside the configured range, and the node repeats
flood traffic.
Uses dual_ota_1536k.csv, and 115200 for upload because the CH340 on this
board corrupts transfers above 230400.
ExpressLRS transmitter modules share a common shape: powered from the
handset bay or USB rather than a battery, a fan over the amplifier, and an
ESP8285 "backpack" on a second UART that MeshCore has no use for.
ELRSTxBoard handles those from optional defines (PIN_FAN_EN,
PIN_BACKPACK_EN, PIN_BACKPACK_BOOT, MANUFACTURER_NAME) so a variant only
has to supply pin numbers. It also returns DIO0 from getIRQGpio(), since
the ESP32Board default is the SX126x pin.
Some SX1276 boards do not drive the antenna from the radio. They feed an
external power amplifier whose gain is set by an analog control voltage on
the PA's gain input (APC/APC1/APC2/VAPC depending on the module), driven
from an MCU DAC. The radio sits at a fixed drive level and all power
control happens on that pin, so setOutputPower() alone does not describe
what the board can do.
DacPaSX1276Wrapper overrides applyCachedTxPower() and translates the
requested dBm, measured at the antenna, into a gain-control code using a
per-board calibration table.
The table defines the legal range, so out-of-range requests are refused
rather than saturated at the nearest entry. An optional max_dbm argument
caps the board below its top entry for thermal or regulatory headroom, and
can only ever reduce the ceiling. The gain write goes through a virtual so
a PA driven by PWM or an external DAC can reuse the rest.
Move OTA_HEAP_CONTEXT from two hand-edited envs to a pre-script gated on
build.mcu == "esp32", so every classic ESP32 image gets it and none can drift.
S2/S3/C-series and nRF52 keep the .bss singleton: they have no equivalent
static-DRAM ceiling, so there a guaranteed-present workspace is the better
trade for what is ultimately a recovery path. It has to be a build flag rather
than a header default, because OTA_HEAP_CONTEXT must hold the same value in
every translation unit that sees OtaContext.h - OtaContext.cpp included - and a
header test on CONFIG_IDF_TARGET_ESP32 would depend on include order relative
to sdkconfig.h. The script defers to OTA_SHARED_COMPANION_QUEUE where a Full
Companion recipe already owns the storage.
Fix a gap this exposes in the roles that now use it. Only CLI entry points
acquire the context, so once it was released, a repeater with the temporary
radio profile up would no longer serve or announce its own firmware - LoRa OTA
would look enabled and silently do nothing. ota_service_temp_radio_context()
holds the workspace for exactly the temp-radio window and hands it back
outside it, which is where the saving was coming from anyway. Wired into the
repeater, room server and sensor loops; the Companion keeps its own
acquire-on-host-demand policy, since its context is borrowed from the offline
message queue and must not be taken speculatively.
Static DRAM, classic ESP32 (bytes occupied of a 124,580 region):
Heltec_v2_repeater 108,332 -> 70,732
Heltec_v2_room_server 83,716 -> 68,300
Heltec_v2_companion_radio_ble 123,236 -> 107,772 (was failing on main)
Tbeam_SX1262_repeater 86,932 -> 71,468
Tbeam_SX1262_repeater_observer_mqtt 121,132 -> 83,532 (was failing)
OtaContext owns serve_buf, serve_self_leaves and serve_self_proof as raw
malloc'd pointers, and nothing freed them on teardown: self-serve only frees
them when it re-allocates, and reset_session() does not touch them. That was
harmless while the context was a permanent .bss singleton, but both dynamic
storage modes destroy it between operations - OTA_HEAP_CONTEXT deletes it,
and the Companion's borrowed queue runs ~OtaContext() in place. A self-serving
node reaches release with both self-serve buffers populated, so every
acquire/release cycle leaked them.
Give OtaContext a destructor that releases what it owns, and delete the copy
operations so the raw pointers cannot be double-freed.
Classic ESP32 links into a dram0_0_seg of only 124,580 bytes: memory.ld
carves the BT controller's 0xdb5c (56,156) reservation off the 0x2c200
window before the application gets any. Three large objects dominated what
was left, and Tbeam_SX1262_repeater_observer_mqtt overran the build's 8 KiB
static reserve by 4,744 bytes.
Heap-allocate them instead, each with a defined behaviour when the
allocation fails:
- OtaContext: generalize the Companion's borrowed-storage path behind
OTA_DYNAMIC_CONTEXT and add OTA_HEAP_CONTEXT, which allocates the context
on first use and frees it once no transfer, apply or folder link needs it.
A repeater is idle nearly all the time, so the workspace is usually absent.
Exhaustion is reported to the caller and the operation declines.
- ClientACL: the client table becomes a pointer with a live capacity;
capacity 0 refuses new clients rather than writing through a null table.
- MyMesh flood packet filters: likewise, with flood_packet_filter_slots as
the live bound for every rule loop. At capacity 0 the node forwards
unfiltered, and both save paths refuse to write so a stored ruleset is
never replaced by an empty file.
Also override the Arduino SDK's weak btInUse() in simple_repeater so
initArduino() releases the BT controller memory to the heap. That grows the
runtime heap these tables now come from; it cannot recover the same
reservation from the linker's static window.
Static DRAM, classic ESP32:
Heltec_v2_repeater 108,332 -> 70,732
Tbeam_SX1262_repeater_observer_mqtt 121,132 -> 83,532 (was failing)
mikecarper