Project
ESP32 Radio Control Head
An evolving CYD-based touchscreen control-head project for FLRig status, presets, and non-destructive radio-control experiments.
Evidence and limits
SeedEarly but useful material; direction, details, and conclusions may still change.
Current state
Board bring-up and architecture notes exist for the CYD display, touch, SD, and FLRig path, but complete V1 operation is not established. Next: inventory boards/cables, then reproduce one narrow display-touch-FLRig slice.
Observed
- Display backgrounds rendered correctly only after enabling `tft.invertDisplay(true)` in the known-good CYD setup.
- Landscape touch operation required swapping touch axes after the display was rotated.
- Touch stopped responding after SD access unless the touch SPI setup was restored.
Measured
- Recorded touch calibration ranges are X 280 to 3700 and Y 450 to 3690.
Not measured or uncertain
- Complete end-to-end V1 behavior has not been established yet.
- Final enclosure integration, long-term reliability, and degraded-mode handling have not been validated.
- PTT and transmit control are intentionally outside V1 scope.
This project is a configurable touchscreen radio control head built around the ESP32-2432S028 / CYD board. The goal is a small bench-friendly interface that can show radio state, run approved presets, and send limited non-destructive commands through FLRig.
The project is still early, but it is no longer just an abstract idea. Board bring-up notes now identify several known-good configuration choices and a few fragile areas that need to be preserved.
Project snapshot
| Field | Current state |
|---|---|
| Stage | Board bring-up and architecture validation |
| Target hardware | ESP32-2432S028 / CYD |
| Radio interface | FLRig over XML-RPC |
| Verified so far | Display bring-up, landscape touch mapping, display inversion, and SD/touch SPI behavior |
| Whole-system status | Complete V1 end-to-end operation is not yet established |
| Current decision | Preserve FLRig as source of truth and keep V1 non-destructive with no PTT |
| Next physical action | Inventory available CYD boards, SD cards, USB cables, and power options |
| Next engineering slice | Reproduce the known-good board setup, then prove one narrow FLRig read/display/control path |
Problem and intended use
The intended role is a compact control surface for common radio-adjacent actions at the bench or operating desk. It should make a few repeated operations easier without trying to replace the radio, the logging computer, FLRig, DigiPi, or a full Linux workstation.
V1 is aimed at:
- showing frequency, mode, and basic radio state from FLRig
- running a small set of approved band, mode, or preset actions
- keeping network and preset configuration available through a browser interface while advanced configuration stays on SD card files
- logging useful local events for later debugging
- degrading clearly when Wi-Fi, SD, or FLRig is unavailable
What has been verified so far
| Area | Verified result | Practical consequence |
|---|---|---|
| Build target | PlatformIO target esp32dev with the Arduino framework is the recorded target | Keep the first public build path aligned with that environment |
| Display | ILI9341_2_DRIVER worked correctly, USE_HSPI_PORT is used for the TFT, rotation 3 is the preferred landscape orientation, and black backgrounds required tft.invertDisplay(true) | Preserve the display driver, HSPI choice, inversion, and orientation assumptions when reproducing the setup |
| Touch | Touch is handled manually; after display rotation, landscape operation required swapping touch axes | Treat touch transforms as board/project-specific instead of assuming the display rotation also rotates touch coordinates |
| Touch calibration | Recorded touch ranges are X 280 to 3700 and Y 450 to 3690 | Keep these as starting calibration values, not universal CYD constants |
| SD and touch | Touch and SD share the VSPI peripheral; after SD access, touch SPI must be restored or touch stops responding | Storage access must hand control back to touch cleanly |
| FLRig protocol | FLRig integration uses XML-RPC POST; recorded method names include rig.get_vfo, rig.get_mode, rig.set_frequency, and rig.set_mode | Validate real XML-RPC responses instead of treating a raw TCP connection as success |
| UI behavior | Notes favor changed-region redraws, menu rows over dense button grids, and resetting touch state on release | Keep the UI simple and avoid full-screen redraw churn |
These are board-bring-up and architecture facts, not proof that the whole V1 system is finished.
V1 architecture and stable decisions
FLRig is the source of truth for frequency, mode, and radio state. The ESP32 requests and displays FLRig state, then sends approved commands that stay non-destructive. It does not independently model the radio.
| Owner | Responsibility |
|---|---|
| FLRig | Radio connection, current frequency, current mode, and authoritative radio state |
| ESP32/CYD | Touchscreen control surface, status display, preset actions, local UI state, and approved commands over XML-RPC |
| Browser UI | Network and preset configuration |
| SD card | Advanced configuration, JSON-defined plugins, and logs |
| Flash | Validated backup configuration copied from a valid SD configuration and used when SD configuration is unavailable |
Stable V1 decisions:
- The touchscreen home screen remains the permanent operational surface.
- Menus and dialogs appear as overlays instead of replacing the home screen.
- Valid SD configuration takes priority and is copied to flash as the backup configuration.
- Plugins are data-driven JSON action definitions.
- Plugins are not browser-editable in V1.
- Plugins cannot execute arbitrary code or arbitrary or unrestricted FLRig commands/RPC.
- The hardware target remains the CYD board in a desktop enclosure.
V1 boundaries and exclusions
These exclusions are scope control, not defects:
- no PTT or transmit control in V1
- no destructive radio actions
- no arbitrary or unrestricted FLRig commands/RPC
- no onscreen keyboard
- no rotary encoder support
- no audio subsystem
- no OTA or SD-card firmware update system
- no goal to replace a Linux computer, DigiPi, or full station-control environment
The first version should prove a narrow, dependable workflow before adding broader control features.
Current implementation plan
The next software slice should stay deliberately small:
1. Reproduce the known-good display, inversion, rotation, touch, and SD/touch SPI behavior. 2. Read frequency and mode from FLRig using real XML-RPC calls. 3. Display those values on the home screen without full redraws. 4. Send one approved non-destructive command, such as a preset or mode command. 5. Log enough local state to debug connection, SD, touch, and FLRig failures.
Planned V1 features such as browser configuration for network and presets, SD-to-flash backup configuration, logging, and degraded-mode behavior remain targets until they are implemented and checked.
Fragile areas and lessons already learned
The notes call out a few areas that should not be casually changed:
- touch-axis transforms
- SPI switching between SD and touch
- display inversion
- rotation assumptions
- FLRig XML-RPC behavior
The right cadence for this project is small change, compile, upload, validate, then continue.
Next checkpoint
First physical action:
- Inventory the available CYD boards, SD cards, USB cables, and power options.
First engineering slice after inventory:
- Reproduce the known-good display and touch setup, then prove one narrow end-to-end FLRig path, such as reading frequency and mode and issuing one approved non-destructive preset or mode command.
PTT and transmit control stay outside this checkpoint.
Open questions
- What is the smallest useful first preset or mode action?
- Which radio should be the first repeatable FLRig integration target?
- How much status detail belongs on the home screen before it becomes clutter?
- What should the device show when FLRig, Wi-Fi, or SD configuration is unavailable?
- Which logs are actually useful for debugging without turning the device into a general computer?
Future work
Later work can expand SD-based configuration, plugin definitions, and degraded-mode behavior after the narrow display-touch-FLRig path is real. Enclosure fit should wait until the board, cable, SD, and power inventory is confirmed.
Feedback
Found a mistake or have feedback?
Desert Radio Labs is a learning project. Corrections, better test methods, shared results, and thoughtful suggestions are welcome.
Email: feedback@desertradiolabs.com