Repository navigation
The boards and radios we do not model yet, and what each one needs #603
Description
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
- Probe the seven never-booted boards. Cheap, and it either shrinks this list
by seven or replaces seven guesses with seven facts. - SX1268, as a band variant of the model we have. Unlocks 15 variants.
Station_G2's ESP-IDF assert.- E-paper, which unblocks the display half of three of the seven.
- 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.
Activity
A13xB0 commentedon Oct 25, 2026
Item 1 done: the seven never-booted boards were probed against v1.17.1, one at a time.
Heltec_E290heltec_tracker_v2Heltec_E213Heltec_Wireless_PaperLilyGo_TBeam_1WStation_G3_ESP32Tbeam_SX1262The two that pass join
EmulationVerifiedin #795. The E290 runs, but its e-paper panel is still not drawn.The four that boot and stay silent share a shape: three are ESP32-S3 boards with e-paper or a 1 W front end. That is the next thing to look at, with the radio stats and the guest PC.
Also found: five of these first failed with "could not reach the firmware catalogue" because the unauthenticated GitHub API allowance (60/h) had run out. The probe now says that, and that
GITHUB_TOKENraises it.boards: probe the seven never-booted boards (#795)