FDE in Practice — VLSC Project Methodology

Overview

The Evolution Chain

Three projects, one FDE pipeline. MRRC: 15 cycles (Mar–Jun 2026). SunMRRC: 40+ commits in 13 days (Jun 21–Jul 3), V1.0 in 4 days. SunsdrMobile: single-commit V1.0 (Jul 1), zero server changes. Each project's Product phase becomes the next project's Echo baseline.

Part 1

MRRC — 15 FDE Cycles as Foundation

Each cycle = Echo (discover) → Delta (prototype) → Product (abstract). Every abstraction becomes a reusable asset for the next cycle — and for future projects.

From raw fork to production system

MRRC started as a fork of F4HTB, a Python-based WebSDR transceiver control. The upstream was Linux-only, hardcoded for a single radio, and had no mobile support. FDE cycle #1 asked: "What does the user actually need?" — cross-platform operation, mobile access, and multi-radio support.

Each cycle produced at least one reusable abstraction: PyAudio cross-platform audio (V2.0), AudioWorklet low-latency pipeline (V3.0), PTT pre-warm reliability framework (V4.0), ATR-1000 standalone proxy (V4.5), WDSP Python wrapper (V4.9), Glassmorphism design system (V5.0), RagChew TX audio presets (V5.1), MemoryChannelManager (V5.5), LearningBuffer (V5.6).

By V5.6.5, 16 reusable assets formed a complete platform. The next project wouldn't start from zero — it would start from leverage.

MRRC Leverage Metrics

Total cycles15

Commits280+

Design docs60+

Reusable assets16

Cycle 1 duration~4 weeks

Cycle 15 duration~1 week

Speed gain4×

Key abstractionsPyAudio, AudioWorklet, WDSP, PTT-FW, ATR-proxy, MemoryChannelMgr

Phase	Cycles	Key Event	Leverage Created
Foundation	1–3	WebSocket + cross-platform audio + mobile UI	Audio pipeline, mobile framework
Soak	Gap	14 months daily operation — accumulating real pain points	Real-world usage data
Core Systems	4–6	PTT reliability, ATR-1000 proxy, WDSP NR2	PTT framework, ATR proxy, WDSP wrapper
Polish	7–12	Ansible deploy, UI modernization, audio presets, network monitor, FT8 bridge	Design system, TX presets, NetMonitor
Stability	13–15	Memory channels, ATR stability, EFHW research	MemoryChannelMgr, LearningBuffer

Part 2

SunMRRC — Reverse Engineering a Black Box

The SunSDR2 DX is a Software Defined Radio with no documented protocol, no open API, and no Hamlib support. Protocol reverse-engineering happened pre-git. From first commit (June 21) to production V1.0 (June 24): 4 days. To SDD V3.7 (July 3): 13 days.

Different hardware, different architecture

Traditional HF radios expose a serial CAT interface (frequency, mode, PTT) via Hamlib/rigctld. The SunSDR2 DX has none of that. It streams raw IQ samples over UDP on port 50002, and accepts proprietary binary commands on port 50001. There is no rigctld, no CAT, no documented protocol.

Echo phase: Deployed at the radio site. Captured UDP packets with Wireshark. Reverse-engineered the IQ frame format (24-bit interleaved I/Q, fixed sample rates). Decoded the 0x0017 DRIVE command, the 0x1F00 telemetry packet (34 bytes), and the 0xFFFD TX IQ stream. Built a Python UDP client that could at least talk to the radio.

Delta phase: FastAPI server with 5 WebSocket endpoints (/WSCTRX, /WSaudioRX, /WSaudioTX, /WSspectrum, /WSATR1000). Server-side IQ demodulation via numpy/scipy. DDC + fractional resampler + overlap-save Hilbert SSB modulator. Dual-codec Opus/PCM tagged transport. Per-band DRIVE power control.

Product phase: Generalized into a server/client architecture. The web frontend and SunsdrMobile iOS app both connect to the same server. Leverage from MRRC: PTT safety model (ACK retry × 3, watchdog, touch-move release), WDSP integration pattern, multi-instance architecture, Glassmorphism design tokens.

Reverse Engineering Stats

Unknown protocol surface100%

UDP capture sessions (pre-git)40+

Decoded command types12

Git commits (Jun 21–Jul 3)40+

WebSocket endpoints5

First commit → V1.04 days

First commit → SDD V3.713 days

MRRC assets reused8

Key leveragePTT safety, WDSP, multi-instance, AudioWorklet RX pipeline

SunMRRC Development Timeline (Git-Verified)

13 days from first commit to SDD V3.7. Protocol reverse-engineering (40+ Wireshark sessions, 12 command types decoded) happened before the initial commit — the first commit already contained PROTOCOL.md (22 sections) and a working TX modulation pipeline.

Date	Key Commits	Echo → Delta → Product	Assets Created
Pre-git	—	Echo: 40+ Wireshark captures at radio site. Reverse-engineered IQ frame format (24-bit interleaved), 12 command types, 30-packet boot sequence, UDP control protocol. Delta: Python UDP client (sunsdr_direct.py) capable of booting device, setting frequency, receiving IQ stream.	sunsdr_direct.py, PROTOCOL.md (22 sections, 1,800+ lines)
Jun 21	`38cb85e` Initial commit `5996a23` PROTOCOL.md `697789b` TX modulation + memory channels	Delta: FastAPI server, 5× WebSocket endpoints, IQ DSP pipeline (numpy/scipy), Hilbert SSB modulator, memory channel API. Product: First commit already bundled protocol docs, TX pipeline, tune mode, and REST API — a complete working baseline. 8 MRRC assets reused (PTT safety, WDSP, multi-instance, Glassmorphism).	server.py, dsp.py, 5× WS endpoints, REST API, mobile UI
Jun 22–23	`8ba105e` TX chain fixes `1217165` DRIVE power control `b761b48` Sample rate selector	Delta: Real mic SSB audio, LSB/USB mode switching, click removal. Device DRIVE (0x0017) per-band power with band_power.json persistence. Dynamic STREAM_CTRL for 39/78/156/312 kHz sample rates.	DRIVE power system, per-band power UI, sample rate control
Jun 24	`433194c` Dual-codec + telemetry `6b1bc2b` V1.0 release `fcfafd3` Website	Product: Tagged dual-codec audio (Opus/PCM), SWR telemetry decode, SunMRRC V1.0 production release. Project website + SDD docs + deploy script created same day. V1.0 in 4 days from first commit.	Dual-codec transport, telemetry decode, website, SDD V3.0-3.3
Jun 25	`225e1e0` Full-scale IQ `587e580` TUNE scale	Delta: TX IQ peak corrected to 1.0 (full 24-bit scale, matching ExpertSDR3). Telemetry field map verified (off30=watts, off16=volts, off18=temp). TUNE carrier power capped for PA safety.	Corrected TX gain staging, telemetry field verification
Jun 28	`9346074` RX 48kHz pipeline `4f5a84d` WDSP IQ-level `c7185f3` WDSP UI panel `dae415b` AGC panel	Delta: RX audio pipeline upgrade to 48kHz, WFM hi-fi mode, cubic resampling. WDSP moved to IQ-level (NR2/ANF/SNB before demod). Full WDSP settings panel + AGC control panel with persistence. TX audio quality fixes (anti-alias LPF, jitter buffer, DC blocker).	48kHz RX pipeline, WDSP IQ processing, WDSP UI, AGC panel, TX audio chain
Jun 29–30	`b1f4076` SAB ring + COEP `9bcccd7` 300Hz HPF `4673422` SDD V3.5 PPTX	Delta: Removed broken WDSP TX C-chain (Python Hilbert is sole SSB path). SAB ring buffer for zero-main-thread TX audio. COEP credentialless for Safari SharedArrayBuffer. 300Hz HPF for +15% PA headroom. Product: SDD V3.5-3.6 (17 ADs, complete component model), V3.5 architecture PPTX.	SAB ring buffer, COEP headers, 300Hz HPF, SDD V3.5-3.6, architecture PPTX
Jul 3	`67ce1a3` Spectrum accuracy `0254f81` SDD V3.7 `a748bc2` UI redesign	Product: Exact sample rate lookup (39062/78125/156250/312500), FFT pixel alignment (xScale=W/n), multi-client state sync. UI redesign + WDSP NR2 musical-noise reduction. SDD V3.7: all 15 chapters verified against live code. Comprehensive docs update.	Spectrum accuracy fix, SDD V3.7, UI redesign, final docs

Key FDE Insights from SunMRRC

1

Reverse-engineering IS Echo

40+ Wireshark sessions at the radio site pre-git. The initial commit already contained a complete PROTOCOL.md (22 sections) and working protocol module — the Echo phase produced the foundational asset before any server code was written.

2

8 MRRC assets reused — PTT, WDSP, multi-instance, Glassmorphism

PTT safety (ACK×3, watchdog), WDSP integration pattern, multi-instance architecture, Glassmorphism design tokens all carried forward. SunMRRC inherited these rather than re-solving them.

3

Protocol-as-contract enabled SunsdrMobile

The WebSocket cmd:val protocol, tagged dual-codec transport, and 512-bin spectrum format became the stable contract. SunsdrMobile spoke it with zero server changes.

4

V1.0 in 4 days, not 3 months

Git shows first commit (Jun 21) → V1.0 release (Jun 24) = 4 days. The reverse-engineering was pre-git; once the protocol was understood, the server/DSP/TX came together in a single intense burst. SDD was written concurrently, not after.

Part 3

SunsdrMobile — Native iOS, Single-Shot V1.0

With SunMRRC's WebSocket protocol as the stable contract, the entire iOS app shipped in a single V1.0 commit (July 1). Zero protocol redesign. Zero server changes. Pure Apple frameworks.

From web to native — the FDE way

Echo phase: The SunMRRC web frontend worked, but mobile users wanted native performance: smooth 60fps waterfall, haptic PTT feedback, Keychain-secured auto-login, and system-level audio integration. The web could do many things, but not those things well.

Delta phase: SwiftUI app, zero third-party dependencies. 4× URLSessionWebSocketTask connections to the existing SunMRRC server. AVAudioEngine for low-latency playback and microphone capture. CGImage/UIKit for waterfall rendering (512×100 pixel buffer, 5-frame accumulation, 10fps throttle). Keychain for credential storage.

Product phase: Reusable component architecture: SpectrumView (waterfall + frequency scale), SMeterView (real-time dB meter), GainSlider (AF/RF/SQL touch sliders), FavoritesGrid (3×3 channel memory), DSPPanel (NR2/AGC/NB/ANF toggles), PTTButton (96pt touch target with auto-release).

Leverage from SunMRRC: The WebSocket protocol was the contract. No negotiation, no redesign — the iOS app speaks the same cmd:val protocol, receives the same tagged PCM/Opus audio, renders the same 512-bin spectrum. The server didn't change at all.

iOS Build Stats

Git commits4

V1.0 releaseJul 1 (initial commit)

UI overhaulJul 4 (17 files, +FFTProcessor)

3rd-party dependencies0

WebSocket connections4

Reusable components10+

SunMRRC assets reused6

Server changes needed0

Key leverageWS protocol, audio codec tags, DSP panel mapping, PTT safety model

SunsdrMobile Development Timeline (Git-Verified)

4 commits total across 2 days. V1.0 shipped as the initial commit (Jul 1), followed by a significant UI overhaul (Jul 4: 17 files, new FFTProcessor, S-meter fix, dot sliders). The key FDE metric: SunMRRC server needed zero changes to support the native iOS client.

Date	Commit	What Shipped	FDE Cycle
Jul 1	`2314c7c` V1.0 release	Complete native iOS app in a single commit. SwiftUI, zero third-party dependencies. 4× URLSessionWebSocketTask (WSCTRX, WSaudioRX, WSaudioTX, WSspectrum). AVAudioEngine for low-latency playback + mic capture. CGImage/UIKit waterfall (512×100 pixel buffer, 5-frame accumulation, 10fps throttle). Keychain credential storage. 10+ reusable components: SpectrumView, SMeterView, GainSlider, FavoritesGrid (3×3), DSPPanel (NR2/AGC/NB/ANF), PTTButton (96pt touch target + auto-release), LoginView (Keychain + WSS), SettingsView, AudioCodecPicker, BandPowerPanel. 6 SunMRRC protocol assets inherited — zero server changes.	Echo → Delta → Product in a single burst. Echo: web frontend UX gap (no native 60fps waterfall, haptics, Keychain). Delta: pure Apple frameworks, 4× WSS, AVAudioEngine. Product: 10+ reusable components for future iOS HAM apps.
Jul 1	`3e8b1f7` README + architecture	Project README with architecture overview, component map, and setup instructions.	Documentation as Product output.
Jul 4	`d460131` UI overhaul	17 files changed. UI layout overhaul: unified chips, dot sliders, S-meter fix, connection status indicator. New FFTProcessor (93-line Swift file for spectrum analysis). Colors.swift (design tokens). Major refactors: DSPPanelView (374→simplified), MainRXView (462→restructured), WaterfallView (135→optimized). RadioState model extended with connection tracking.	Second FDE cycle — Echo: real-world UI feedback. Delta: design token system + FFT module extraction. Product: simplified component architecture, reusable Colors/FFTProcessor modules.
Jul 4	`f93955e` Website + SVG	Bilingual promotional website (EN/CN) with inline SVG architecture diagrams and UI phone mockup. Deployed to /sunsdrmobile/. Follows MRRC/SunMRRC octen.css design system.	Website as Product artifact — deploy pattern reused from SunMRRC.

Key FDE Insights from SunsdrMobile

1

Single-commit V1.0 is the ultimate FDE proof

The entire app shipped in one commit. This isn't because the app is simple — it's because SunMRRC's protocol was a stable contract. Zero server-side negotiation, zero protocol redesign. The 6 inherited assets (WS protocol, codec tags, DSP commands, PTT safety, spectrum format, power API) eliminated months of work.

2

Zero dependencies = zero friction

No CocoaPods, no SPM, no third-party libraries. Pure Apple frameworks: SwiftUI, AVAudioEngine, URLSession, Security/Keychain, CGImage. Builds instantly, no version conflicts, no supply-chain risk.

3

Every SunMRRC Product asset paid off here

The WebSocket cmd:val protocol, tagged dual-codec, DSP panel mapping, PTT safety model, spectrum format, per-band power API — all designed and stabilized during SunMRRC's 13-day git history — were inherited without modification. Each prior project's Product phase paid for this one's Delta phase.

4

FDE leverage is measured in server changes: 0

The key metric isn't lines of code or development time — it's that the SunMRRC server required zero changes to support a completely new native iOS client. Protocol stability is worth more than elegant code.

Part 4

The Harness Chain

How SDD locks down requirements at three levels: Business Harness defines WHAT, Technical Harness defines HOW, Product Harness defines the DELIVERABLE. Each FDE cycle feeds this chain.

Business Harness

Defines WHAT — the problem to solve and why it matters

SDD Ch2: Business direction — who is the user, what is the market gap
SDD Ch4: System context — external systems, interfaces, constraints
SDD Ch5: Non-functional requirements — latency, reliability, security, platform
SDD Ch6: Use case model — concrete user scenarios driving each cycle
SDD Ch13: Feasibility — can we actually build this with available resources
Echo phase feeds this harness. Each cycle starts here.

Technical Harness

Defines HOW — the architecture and implementation approach

SDD Ch7: Subject area model — domain entities and relationships
SDD Ch8: Architecture decisions (ADs) — why we chose X over Y
SDD Ch9: Architecture overview — system topology, data flow
SDD Ch10: Service model — API contracts, WebSocket protocols
SDD Ch11: Component model — module boundaries, responsibilities
SDD Ch12: Operational model — deployment, monitoring, backup
Delta phase feeds this harness. Prototyping validates ADs.

Product Harness

Defines the DELIVERABLE — what actually ships and why it's reusable

SDD Ch1: Executive summary — what we built, for whom, what value
SDD Ch3: Project definition — scope, deliverables, acceptance criteria
SDD Ch14: Version history — what changed, when, and why
Abstraction catalog: Gravel Roads → Highways — reusable module inventory
Leverage dashboard: Cumulative reusable assets, cycle speed trend
Product phase feeds this harness. Abstraction makes it reusable.

The critical insight: Don't let documentation drive development — let development drive documentation. After each FDE phase, the output updates the harness. Business Harness captures what Echo discovered. Technical Harness captures what Delta validated. Product Harness captures what Product abstracted. The harness is not a plan — it's a record of what worked.

Harness Reuse Across Projects

SDD Chapter	MRRC	→ SunMRRC	→ SunsdrMobile	Reuse Type
Ch4 System Context	HF rig via Hamlib	SDR via UDP IQ stream	Server via WSS	Template — same structure, different systems
Ch5 NFRs	<100ms TX/RX switch	<50ms WS latency	60fps waterfall	Evolved — tighter each project
Ch8 Arch Decisions	12 ADs (audio, PTT, DSP)	+5 ADs (IQ demod, codec)	+2 ADs (Keychain, CGImage)	Extended — prior ADs carry forward
Ch10 Service Model	REST + 1 WS	5 WS endpoints	Same 5 WS — zero changes	Inherited — server is the contract
Ch11 Component Model	Python backend only	+ FastAPI layer	+ SwiftUI components	Layered — each project adds a layer

Part 5

The FDE Blueprint for New Projects

A repeatable playbook derived from going MRRC → SunMRRC → SunsdrMobile. This is how you build the next thing fast.

What this blueprint produced

Project	Git History	Starting Leverage	First Commit → V1.0	Server Changes	Key Enabler
MRRC	Mar 6–Jun 19, 2026 (15 cycles)	0 (F4HTB fork)	Pre-git (cycles 1–3 before git)	—	F4HTB upstream evaluation
SunMRRC	Jun 21–Jul 3, 2026 (40+ commits)	8 MRRC assets	4 days	—	Pre-git Wireshark RE + MRRC PTT/WDSP reuse
SunsdrMobile	Jul 1–4, 2026 (3 commits)	6 SunMRRC protocol assets	Single commit (V1.0 = initial commit)	0	SunMRRC WebSocket protocol as stable contract
MRRC cycles 1–3 (V1.0→V3.0, Oct 2024–Dec 2024) predate git tracking. The 15-cycle log in Appendix D covers the full timeline. SunMRRC protocol reverse-engineering was pre-git; the initial commit already contained PROTOCOL.md (22 sections) and a working TX pipeline. SunsdrMobile's single-commit V1.0 demonstrates the ultimate FDE outcome: protocol stability → zero server changes.

Appendix A

What is Forward Deployed Engineering?

The theoretical foundation — moved to appendix so the practice stands on its own.

FDE = Echo + Delta + Product

Demand Discovery → Rapid Prototyping → Abstraction & Generalization

Echo

"What does the user really need?"

Embedded in user scenarios — deploy to the field
Define valuable demos — 1 per cycle, concrete and shippable
Manage client relationships — understand the real pain
~20% of cycle time. Output: a validated demo definition

Delta

"What's the fastest thing that works?"

Rapid prototyping — code can be rough but must be functional
Deliver within timeline — ship the demo, get feedback
Iterate based on real feedback — not speculation
~55% of cycle time. Output: a working prototype that validates the demo

Product

"How to serve the next 10 customers?"

Abstract field solutions into reusable modules
Write architecture documentation — your future self needs it
Turn gravel roads into highways — reduce marginal cost to zero
~25% of cycle time. Output: reusable assets + updated SDD

FDE is not consulting. Consulting delivers a one-time solution and leaves. FDE is a product exploration process — each engagement builds permanent assets that reduce the cost of every future engagement.

Appendix B

8 FDE Principles (Distilled from 3 Projects)

1

Start from the field, not from the product

Every cycle is driven by real user scenarios — never "I want to add this feature." The 14-month MRRC Gap Period proved that real usage is the best Echo.

2

Demo-driven validation

Define 1 concrete demo per cycle. Ship it. The demo creates desire — the strongest motivation to deliver.

3

Timely abstraction — not too early, never too late

Wait until 2+ similar use cases succeed before abstracting. But never skip the Product phase. Delta code is consumable; Product output is an asset.

4

Documentation as output, not plan

Update SDD chapters after each FDE phase. The harness records what worked — it's not a speculative blueprint. Your 6-month-future self is the primary audience.

5

Protocol stability is the ultimate leverage

SunMRRC's WebSocket protocol was the contract that enabled SunsdrMobile to be built in 4 weeks with zero server changes. Stable interfaces are worth more than elegant code.

6

Operations is Echo — don't skip the soak time

MRRC's 14-month operational period accumulated real pain points that drove explosive innovation. Daily usage generates better requirements than any planning meeting.

7

5 iterations, then pivot

If a solution hasn't stabilized after 5 iterations, the technical approach is probably wrong. ATR-1000 found the right architecture on iteration 5. Don't polish the wrong approach.

8

Leverage compounds across projects

MRRC's 16 assets reduced SunMRRC's build time by ~40%. SunMRRC's protocol contract reduced SunsdrMobile's build time by ~60%. Each project accelerates the next. Never start from zero.

Appendix C

Common FDE Pitfalls

Requirement Bloat (Echo)

Defined 10 demos with enormous scope

Pick 1 demo per cycle. Ship it. Then do the next.

Fake Echo

Imagined requirements without field presence

Spend at least 1 week in the actual usage scenario before defining requirements.

Premature Optimization (Delta)

Full error handling + logging + config in prototype #1

Prototype #1 validates only the riskiest assumption. Polish later.

Premature Abstraction (Product)

Writing a generic framework before scenario #1 is validated

Wait until at least 2 similar scenarios succeed before abstracting.

Skipping the Product Phase

Delta code shipped directly without generalization

Reserve at least 20% of every cycle for abstraction and documentation.

Starting from Zero

New project, blank repo, no leverage inventory

Always audit existing assets first. SunMRRC reused 8 MRRC modules. SunsdrMobile reused 14. Your leverage is your unfair advantage.

Appendix D

Complete MRRC FDE Cycle Log (15 Cycles)

#	Cycle	Date	Version	Echo Input	Delta Challenge	Product Output
1	Foundation	2024-10	V1.0	F4HTB upstream evaluation	WebSocket + Tornado integration	AD-001/002/003
2	Architecture	2024-11	V2.0	Linux-only, high latency	PyAudio cross-platform + AudioWorklet	audio_interface.py
3	Mobile	2024-12	V3.0	Desktop UI unusable on phones	iOS Safari AudioContext	mobile_modern.html
—	14-month operational gap — daily usage accumulating real pain points (the best Echo)
4	Latency	2026-03	V4.0	PTT 3s delay	Pre-warm frames + count timeout	PTT reliability framework
5	ATR-1000	2026-03	V4.3–4.5	No power/SWR display	5 iterations → proxy architecture	atr1000_proxy.py
6	DSP	2026-03	V4.6–4.9	Noise + harsh audio	WDSP library integration	wdsp_wrapper.py
7	Deploy	2026-04	V5.1.x	Manual 7-step deployment	SSH idempotency	Ansible playbook
8	UI	2026-04	V5.0	Outdated UI, emoji inconsistency	Cross-platform Unicode icons	Glassmorphism design system
9	Audio	2026-05	V5.1	Harsh TX audio	Safari setValueAtTime fix	RagChew audio preset system
10	Perf	2026-05	V5.2	RX inter-frame gaps	Multi-node scheduled playback	audio_rx.js rewrite
11	Network	2026-05	V5.3	No network visibility	Real-time bandwidth/latency display	Network monitoring
12	FT8	2026-05	V5.4	FT8 method mismatch	Python–JS method alignment	FT8 WebSocket stabilization
13	Memory	2026-06	V5.5	Cumbersome channel workflow	Service-oriented batch DOM updates	MemoryChannelManager
14	Stability	2026-06	V5.6.0–4	False SWR corrupting tuner	Stable window + dedup	LearningBuffer
15	EFHW	2026-06	V5.6.5	EFHW design documentation	Static site + deep research	EFHW knowledge base

Appendix E

Gravel Road → Highway Catalog

Every field hack that became a reusable asset — across all three projects

Gravel Road (Delta hack)	Abstraction	Highway (Product asset)	Project
ALSA Linux-only audio	PyAudio cross-platform	audio_interface.py	MRRC
ScriptProcessor main-thread blocking	AudioWorklet thread	Low-latency audio architecture	MRRC
Direct PTT sleep-wait (3s delay)	Pre-warm + count-timeout	PTT reliability framework	MRRC → SunMRRC
ATR-1000 crashing main process	Standalone proxy + dynamic polling	atr1000_proxy.py	MRRC
Raw libwdsp C calls	Python wrapper	wdsp_wrapper.py	MRRC → SunMRRC
Unknown UDP IQ protocol	Wireshark capture + reverse-engineering	sunsdr_direct.py (IQ decode + TX mod)	SunMRRC
Hardcoded audio codec	Tagged dual-codec transport	Opus/PCM tagged binary stream	SunMRRC
Per-band power hardcoded	DRIVE command + json persistence	band_power.json	SunMRRC
Web Audio API waterfall	CGImage/UIKit waterfall	SpectrumView (512-bin, 60fps)	SunsdrMobile
Browser PTT button	96pt haptic touch target	PTTButton with auto-release	SunsdrMobile
Manual server login	Keychain secured auto-login	CredentialManager	SunsdrMobile
Single-instance hardcoded	Isolated config per instance	Multi-instance architecture	MRRC → SunMRRC
WSJT-X/JTDX FT8 integration	WebSocket bridge + auto-sequencer	FT8 Ultron Console	MRRC

One MethodologyThree Products