Overview

A DIY Geochron-style world clock for the Waveshare ESP32-S3-Touch-LCD-7B (1024×600 RGB panel): a live day/night shadow drawn over a real coastline map, in the spirit of the mechanical Geochron's scrolling lamp-lit drum — but equirectangular instead of Mercator, since Mercator distorts badly near the poles and only works on the real device because its map is on a moving drum, not a fixed rectangle.

What it shows

A full-screen map with the terminator recomputed once a minute (soft twilight blend, not a hard edge), an amber subsolar-point marker, an HF/VHF band-conditions panel parsed from hamqsl.com's feed once an hour, and a five-city clock bar with live local time and that city's own sunrise/sunset. The terminator and every sunrise/sunset time run on the same NOAA simplified solar-position algorithm — declination plus the equation of time — computed from the current UTC date/time, no ephemeris data needed.

The display-sync bug

The hardest part wasn't the astronomy, it was a persistent glitch: the panel would visibly slip a few rows out of sync with the framebuffer and stay shifted. Two tuning changes were tried and reverted (full-refresh mode instead of direct-mode, a larger RGB bounce buffer) before the real culprit turned up — the RGB pixel clock. Waveshare's own default is 30MHz; 20MHz fixed the glitch outright but was uncomfortably flickery, so 25MHz and then 28MHz were each tried as a less-flickery compromise. An exhaustive elimination pass — disabling every periodic task one at a time, including a run where the map task did nothing at all — ruled out application-level scheduling as the cause. Back to 20MHz, which is what's actually flashed.

Keeping the render loop honest

Two separate bugs turned out to share the same root cause: a blocking operation running on the same core as LVGL's render task and the RGB panel's vsync interrupt. The DHT11 temperature sensor's read routine disables interrupts for ~5ms to bit-bang its single-wire protocol; the hamqsl.com fetch needs a multi-second TLS handshake. Both were moved into their own dedicated FreeRTOS tasks pinned to core 0, leaving core 1 free for rendering. A separate slow memory leak — repeated timezone-switching calls leaking a few bytes each, adding up to a reboot after 15–25 minutes of uptime — got fixed by caching each city's UTC offset once a minute instead of re-deriving it every second.

Credit where it's due

Hardware bring-up — I2C bus, IO-expander, RGB panel init, SD card, and the LVGL v8 display port for this exact panel — is Waveshare's own example code for this board, reused as-is so the tricky, easy-to-get-wrong parts are the same code Waveshare ships and tests. Everything else (the terminator math, the map renderer, band-conditions parsing, the city-clock panel) is original.

Overview

A remote operating console for a FlexRadio FLEX-3000, built as a companion to PowerSDR. FireWire and PowerSDR stay on the radio PC; a lightweight client anywhere on the network gets a live waterfall/spectrum, VFO/mode/filter controls, audio, and PTT — without full screen/remote-desktop sharing.

Why this exists

The FLEX-3000 requires a real, physically-attached IEEE-1394 FireWire bus, so PowerSDR itself can never run "remotely." What can be remote is the operating position: instead of streaming PowerSDR's whole window as video (RDP/VNC — laggy, breaks audio drivers), this project streams the underlying data — FFT bins, meter readings, CAT state, audio — and renders a native UI on the client. Data frames are kilobytes; video frames are megabytes.

Architecture

A server on the radio PC taps the FFT/meter data, captures RX/TX audio, and relays CAT commands and PTT. A client on the operator PC renders the waterfall from that FFT stream, exposes VFO/mode/filter controls, and handles audio in/out and PTT. Two links, split by need: TCP carries control/CAT (needs to be reliable), UDP carries the FFT stream and audio (needs to be low-latency).

• Shared Protocol definitions used by both server and client
• Server Runs on the radio PC, alongside PowerSDR
• Client Runs on the operator PC, anywhere on the network
• Status Skeleton — interfaces and stub implementations, TODOs marking exactly where PowerSDR-specific integration work needs to happen

Build order

The protocol comes first (everything else depends on it being stable), then the server's FFT source — the one piece that needs real PowerSDR source to finish, though it can be built and tested against an included simulated FFT source until then. The client can be built and tested entirely against that same simulated server, no radio required.

Overview

A three-node antenna rotator controller: two ESP32-C5 sensor nodes read orientation and report it over ESP-NOW to an ESP32-S3-Touch-LCD-5 hub, which drives the rotor via relays and runs the on-screen control UI. One node reports azimuth only (GY-271 compass); the other reports azimuth and elevation (GY-271 plus an MPU6050 for tilt). A first working build with solid structure and logic throughout — not yet compiled or run on real hardware.

Starting from a known-good base

Same approach as GeochronClock: the hub's display bring-up (RGB LCD timing, the CH422G IO-expander, GT911 touch, backlight) is fiddly board-specific init code that's easy to get subtly wrong from a written description, so it starts from Waveshare's own ESP-IDF demo for this exact panel, confirmed working unmodified, before this project's files are merged into it.

Bring-up sequence

The hub flashes first and prints its MAC address over serial; that address gets copied into both sensor nodes so they know where to send ESP-NOW telemetry. All three devices share one hardcoded WiFi channel for ESP-NOW, which has to match across all of them if it's ever changed.

• Sensing GY-271 compass (+ MPU6050 for elevation)
• Link ESP-NOW, node → hub telemetry
• Drive RS485/Modbus relays, bang-bang control loop
• Status First build — untested on hardware

What still needs the bench

Compass hard/soft-iron calibration isn't implemented yet; axis mapping on both the compass heading formula and the tilt-compensation formula depends on physical mounting and will likely need sign flips once real readings are visible; Modbus address/baud and relay-channel assignment need verifying against the actual relay board; and the deadband on the bang-bang control loop needs tuning once real overshoot/hunting behavior is visible. Testing runs bottom-up: each node alone, then the hub with sensors only, then the jog buttons/encoders, and only then the relay board and motors — with an Emergency Stop check before anything else gets trusted.