Confituurke 8acb68415d feat(sensecap-indicator): SX1262 behind the TCA9535 via a RadioLib HAL
The SX1262's NSS, RESET, BUSY and DIO1 sit on the TCA9535 (P0.0..P0.3)
while SCK/MISO/MOSI are real GPIOs. IndicatorRadioHal derives from
ArduinoHal, keeps hardware FSPI at 4 MHz and maps the virtual pins
0x40..0x43 onto expander transfers; every other pin goes straight to
the Arduino pin and interrupt functions, as ArduinoHal does. The
meshcomod core is used as is: CustomSX1262 and its wrapper run
unchanged on top of the HAL.

DIO1 has no GPIO edge. The expander's open-drain /INT on GPIO42 has an
IRAM ISR that only notifies a dispatch task, because the read needs
I2C and the bus mutex. That task reads both input bytes under the bus
lock: the TCA9535 releases /INT only when the port that changed is
read, and several port-1 inputs float, so a port-0-only read could
leave GPIO42 low for good. Every port-0 byte feeds a small edge
detector (Dio1Edge) through the expander's port-0 observer, which
calls the callback RadioLib attached to DIO1 once per rise. That
callback is the core's setFlag, so TX-done and RX-done reach the core
exactly as they would from a DIO1 interrupt.

A BUSY poll is a port-0 read as well, and it clears /INT. Sampling DIO1
in those reads means a rise that lands while RadioLib waits on BUSY
fires the callback from that read instead of being lost; the dispatch
task's next read sees the level already high and does not fire again.
The task also re-reads every 50 ms, so a rise whose /INT was missed
still fires the callback, at most 50 ms late. MESH_RADIO_DIO1_POLLED is
not set: polling the IRQ register would add an SPI transfer, and with
it expander writes for NSS, on every pass of the receive path.

Floating port-1 inputs can keep /INT toggling, each toggle an I2C read
at high priority. The task counts ISR wakes and timeouts and logs them
for each of the first six 10 s windows, then only above 500 wakes/s
and at most once a minute, so the idle wake rate is visible at
bring-up without flooding the console later.

TCXO or crystal comes from the radio strap read at boot: the env's
SX126X_DIO3_TCXO_VOLTAGE calls indicatorTcxoVoltage(), which returns
2.4 V for the TCXO radio and 0 for the crystal one. radio_init() starts
the radio with the strap's setting and, if that fails, with the other
one, because std_init only falls back from TCXO to 0 V and a TCXO board
whose strap misread as crystal would never start otherwise. main.cpp's
one retry runs both again. The log says which voltage was requested and
which one the radio came up with.

The board reports GPIO42 (indicator::kExpanderIntGpio, shared with the
HAL) as its IRQ line and never light-sleeps: the inherited ESP32Board
versions would treat the virtual DIO1 pin as a GPIO, and /INT is active
low while the light-sleep wake source is high-level.

test_indicator_dio1 covers the virtual-pin routing and the
once-per-rise rule across dispatch and BUSY reads; run-host-tests.sh
gets its include path.

Signed-off-by: Confituurke <9595028+Confituurke@users.noreply.github.com>
2026-10-17 22:39:29 +02:00
2026-08-23 20:32:26 -04:00
2026-08-23 20:32:26 -04:00

WADAMESH

A real touchscreen UI for your mesh radio. · open source · GPL-3.0

Touch-UI MeshCore companion-radio firmware for the LilyGo T-Deck / T-Deck Plus, Heltec V4 + TFT and other boards (ESP32-S3).

An LVGL touch UI (map, chat, contacts, channels, settings) split out of meshcomod. The app depends on a MeshCore fork via PlatformIO lib_deps.

Boards

See DEVICES.md for the full support matrix, install paths and per-board status.

  • LilyGo T-Deck / T-Deck Plus: env LilyGo_TDeck_companion_radio_touch (stable)
  • Heltec V4 + TFT + CHSC6x touch: env heltec_v4_tft_companion_radio_usb_tcp_touch (stable)
  • Tanmatsu (ESP32-P4): built from tanmatsu/ (ESP-IDF), ships via the Tanmatsu app store; sideload guide for running your own build
  • Elecrow ThinkNode M9: env ThinkNode_M9_companion_radio_touch (beta); keyboard & d-pad guide
  • RAK WisMesh Tap V2 (RAK3312): env rak_tap_v2_companion_radio_touch (beta)
  • LilyGo T-Lora Pager: envs tlora_pager_lr1121_companion_radio_touch / tlora_pager_sx1262_companion_radio_touch (beta); keyboard shortcuts
  • Heltec V4-R8 + Expansion Kit V2: env heltec_v4_r8_tft_companion_radio_usb_tcp_touch (beta)
  • LilyGo T-Display P4: built from tdisplay_p4/ (ESP-IDF); AMOLED + SX1262 by default, with WADA_P4_LCD=1 for TFT-LCD and WADA_P4_LR2021=1 for LR2021 (beta)
  • Elecrow CrowPanel Advanced 10.1 (ESP32-P4): built from crowpanel_p4_101/ (ESP-IDF), one image per board revision with WADA_CP_REV=1.0|1.1|1.2 (experimental, not yet tested on hardware; requires an SX1262 in the wireless slot)
  • Attaky Mesh Series: env attaky_mesh_series_companion_radio_touch (beta)
  • Elecrow CrowPanel Advance 3.5: env crowpanel_35_companion_radio_touch (beta, hardware validation pending; requires an SX1262 in the expansion slot)
  • Elecrow CrowPanel Advance 5.0: env crowpanel_50_companion_radio_touch (beta, hardware validation pending; requires an SX1262 in the wireless slot and the DIP switch set to it)

Architecture

This repo holds only the app: the companion_radio glue, the ui-touch LVGL UI, each board's glue/variants, and platformio.ini. The MeshCore core is not vendored here: it's pulled as a library via lib_deps from the ALLFATHER-BV/meshcomod monorepo (the same repo as the non-touch firmware), pinned by a lean source-only core-* git tag. The touch-app files this repo owns (TouchPrefsStore, WifiRuntimeStore, the transports, …) are dropped from the lib via -DMC_VENDORED_TOUCH_APP so they aren't compiled twice. The build is byte-identical to the original in-tree meshcomod firmware.

Lua apps use the on-device SDK described in LUA_APPS.md. For WAV/MP3 playback, including a ready-to-sideload transport test app and exact SD and internal-storage paths, see AUDIO_PLAYBACK_TESTING.md. Region discovery, known-region management, and per-channel flood scopes are described in REGIONS.md.

Offline map tiles

Builds with a microSD card expose a Transfer app for authenticated browser uploads over the local Wi-Fi network. WadaMesh accepts unpacked 256x256 PNG XYZ tiles in a z/x/y.png directory tree.

To create a compatible pack with QGIS:

  1. Add a map source whose licence and service terms explicitly permit offline or bulk use. A self-hosted source is also suitable. Do not bulk-download from tile.openstreetmap.org: the official OSM tile policy prohibits offline downloads from that community service.
  2. Frame only the area needed in the QGIS map canvas. Tile counts quadruple at every added zoom level, so a small region and a practical range such as zoom 8 through 16 are preferable to exporting an entire country at zoom 19.
  3. Open Processing Toolbox → Raster tools → Generate XYZ tiles (Directory).
  4. Use the map-canvas extent, choose minimum and maximum zooms within 3–19, select PNG, set tile width and height to 256, leave Use inverted tile Y axis (TMS conventions) disabled, and select an output directory.
  5. Confirm the output contains paths such as 12/2048/1362.png. If obtaining an existing pack instead, extract it first and confirm it has the same XYZ directory layout and that its provider permits offline use and redistribution.

To upload the pack:

  1. Connect the device and the browser to the same Wi-Fi network.
  2. Open Transfer from the device's app drawer, visit the displayed URL, and enter the six-digit session code.
  3. Choose Offline OSM map (/tiles), select the generated output folder, and start the upload. The browser ignores unrelated files and uploads valid tiles sequentially while preserving their coordinates.
  4. Existing tiles are skipped by default, allowing an interrupted upload to be resumed. Enable Replace existing map tiles when intentionally refreshing a pack.
  5. Close Transfer after completion. In Map options, disable Topographic map and enable Tiles from SD card. Disable Wi-Fi to verify that the uploaded area renders offline.

Individual PNG tiles must be no larger than 256 KB. Keep the map provider's required attribution and licence information with any pack you distribute.

Build

PlatformIO pulls the core fork and all libraries automatically:

pio run -e heltec_v4_tft_companion_radio_usb_tcp_touch   # Heltec V4 TFT
pio run -e LilyGo_TDeck_companion_radio_touch            # LilyGo T-Deck
pio run -e crowpanel_35_companion_radio_touch             # CrowPanel Advance 3.5
pio run -e crowpanel_50_companion_radio_touch             # CrowPanel Advance 5.0
# or just `pio run` to build the configured default environments

Flash with the NVS-preserving 4-component chain (bootloader / partitions / boot_app0 / firmware at 0x0 / 0x8000 / 0xe000 / 0x10000) so saved Wi-Fi credentials survive, not a merged image, which 0xFF-pads and wipes NVS.

Contributing

Contributions are welcome: see CONTRIBUTING.md. One topic per PR; inbound contributions are accepted under the project's GPL-3.0 license.

License

GPL-3.0-or-later: see LICENSE. wadamesh is copyleft: anyone who distributes a build or a fork must also make their source available under the GPL. This keeps the UI open and concentrates community effort instead of fragmenting it into closed forks.

wadamesh incorporates and depends on MeshCore (MIT, © Scott Powell / rippleradios.com) and other third-party components; see NOTICE for the full list and their licenses. MeshCore-derived files keep their MIT notices; the combined work is distributed under the GPL (MIT is GPL-compatible). The MeshCore fork that wadamesh builds against stays MIT on purpose, so its Wi-Fi/BLE hooks remain upstreamable to MeshCore.

S
Description
Форк wadamesh с улучшениями для пользователей из России
Readme GPL-3.0
55 MiB
0 Stars 1 Watchers 0 Forks
2026-10-22 19:22:41 +00:00
Languages
C 48.3%
C++ 41.2%
Lua 3.4%
HTML 2.9%
Python 2%
Other 2.1%