The boards and radios we do not model yet, and what each one needs

[A13xB0]

A standing inventory of the gap between what MeshCore publishes and what this
simulator can run, so that "not supported" is always a specific reason with a
specific next step rather than a shrug.

Written because the board designer plan needs it: every dropdown in that feature
has to say why an option is unavailable, and the reasons below are what it
will say. EmulatableBoards() already answers this at runtime — this issue is
the version a person can read and work from.

Where we stand

Board profiles in the catalogue	25
Of those, emulated and verified booting	16
Of those, blocked	9
Variants MeshCore publishes	87
Radio families MeshCore builds	6
Radio families we model	1

The nine blocked boards

Straight out of EmulatableBoards(), so this table and the application cannot
drift.

Board	MCU	Radio	Wiring	Why it is blocked
Heltec_E213	ESP32-S3	SX1262	QEMU	wiring recorded but never booted
Heltec_E290	ESP32-S3	SX1262	QEMU	wiring recorded but never booted
Heltec_Wireless_Paper	ESP32-S3	SX1262	QEMU	wiring recorded but never booted
LilyGo_TBeam_1W	ESP32-S3	SX1262	QEMU	wiring recorded but never booted
Station_G3_ESP32	ESP32-S3	SX1262	QEMU	wiring recorded but never booted
Tbeam_SX1262	ESP32	SX1262	QEMU	wiring recorded but never booted
heltec_tracker_v2	ESP32-S3	SX1262	QEMU	wiring recorded but never booted
Station_G2	ESP32-S3	SX1262	none	boots, then asserts inside ESP-IDF startup
Heltec_v2	ESP32	SX1276	none	radio not modelled

Three groups, three different pieces of work.

1. Seven boards that have never been through the probe

These have wiring recorded and nothing wrong with them that anybody knows of.
They are blocked because nobody has watched them boot, which is the bar
EmulationVerified holds — the published image builds, boots, brings its radio
up, transmits unprompted and hears a neighbour.

This is the cheapest work on the page and the least interesting: run
board.probe against each, one at a time (the full fixture on emulated boards
takes the machine down), and either add it to EmulationVerified or replace its
line here with what actually failed.

Three of them — Heltec_E213, Heltec_E290, Heltec_Wireless_Paper — carry
e-paper panels, and none of the three declares a Screen at all. Even once
they boot, their display will read as a board nobody has transcribed. E-paper
needs its own model: a different refresh contract from an LCD, and a partial
update that is visible as a real artefact rather than something to smooth over.

2. One board that fails for a reason we understand and have not fixed

Station_G2 boots and asserts inside ESP-IDF's own startup, before MeshCore
runs. The same assert fires on two different boards, one of which has no PSRAM,
so it is not the PSRAM. It wants the treatment that found the S3 boot loop and
the DIO1 chain: print the cause register first, find the guest PC, and fix what
the log names rather than what looks likely.

3. Five radio families, of which we model one

Radio	Variants using it	State here
SX1262	83	modelled — virtual-sx1262, one library behind QEMU, Renode and a native node
SX1268	15	not modelled
LR1110	6	not modelled
SX1276	4	not modelled — Heltec_v2 is blocked on exactly this
STM32WLx	4	not modelled, and not an MCU we emulate either
LR2021	2	not modelled

SX1268 is the one to do first, and it is much less work than the number
suggests. It is an SX1262 for a different band — the same command set, the
same status byte, the same buffer. In virtual-sx1262 it is close to a
parameter rather than a second model, and it unlocks 15 variants.

LR1110 is a real second model, with a different command protocol, and it
brings GNSS and Wi-Fi scanning that nothing here has an opinion about yet.

SX1276 is a genuinely different part — an SX127x, register-mapped rather
than command-based. One board here needs it and four variants use it, so it
buys the least per unit of work of the three, but it is the one with a board in
the catalogue already waiting on it.

Whatever the part, the shape is settled and should not be re-litigated: one
MIT library, three callers. A second implementation that has to agree with
the first forever will not, and the first time they drift, every comparison
between two backends measures our own code instead of MeshCore's. See
docs/adr and the virtual-sx1262 repository.

The other 62 variants

MeshCore publishes 87; we profile 25. The remainder split by MCU family:

Family	Variants	Can we emulate the family?
esp32_base	40	yes (QEMU, our fork)
nrf52_base	36	yes (Renode, our peripherals)
stm32_base	4	no machine
rp2040_base	4	no machine
esp32c6_base	3	no machine (RISC-V, not Xtensa)

So most of the missing boards are transcription, not modelling: an
esp32_base or nrf52_base board on an SX1262 needs a profile written from its
own variant and a probe run, and nothing else. That is the same job the five
nRF52 panels were in #598, and the rules are in CLAUDE.md — work from the
manufacturer's own pinout, cross-check the firmware variant, cite the source in
the profile.

The eleven on STM32, RP2040 and ESP32-C6 are a different matter: each family
needs a machine before any board on it can run, which is far larger than the
rest of this issue put together. They remain perfectly good profile boards —
coverage, link budgets, planning and energy all work on a board whose firmware
never boots — and the board designer plan is built around saying exactly that
rather than refusing them.

Suggested order

1. Probe the seven never-booted boards. Cheap, and it either shrinks this list
   by seven or replaces seven guesses with seven facts.
2. SX1268, as a band variant of the model we have. Unlocks 15 variants.
3. Station_G2's ESP-IDF assert.
4. E-paper, which unblocks the display half of three of the seven.
5. LR1110, as the first genuinely second radio model.

Nothing here is a blocker for the board designer: that feature is designed to
offer every one of these as a profile board and say plainly what will not run.