4.1 About this Volume

Volume 3 is the lookup table; this volume is the story and the judgment behind it. It traces how a $30 radio acquired one of the most active open-firmware ecosystems in hobby RF — starting from a single reverse-engineering effort in late 2023 — and then characterizes each fork worth considering: its philosophy, its headline features, and who it is for. The goal is to let a reader choose a fork on purpose rather than by folklore, and to understand why the ecosystem settled into the particular shape Volume 3 records: a mature-but-frozen default on the old hardware and a single actively-developed line on the new.

This is a firmware-ecosystem history, which is reference material — the impersonal voice is correct throughout. The hands-on act of building one of these forks from source is the sibling Volume 7; the signature feature those forks share, the spectrum analyzer, gets its own treatment in Volume 5.

4.2 The origin — fagci and the late-2023 reverse engineering

Before late 2023 the UV-K5 was just another cheap handheld. What changed everything was fagci’s reverse engineering of the BK4819 register map and the radio’s firmware, published as an open modification. Two things made it consequential. First, it demonstrated that the radio’s capabilities were almost entirely a matter of software policy — the BK4819 could do vastly more than the stock firmware allowed, and now the register sequences to prove it were public. Second, and most memorably, fagci shipped a spectrum analyzer: by stepping the chip’s synthesizer across a span and reading the RSSI register at each step, a $30 voice radio could draw a live picture of a band on its little LCD. That single demo — “it has a spectrum analyzer now” — is what turned a niche into a movement.

Once the register map was open and a compelling demo existed, the barrier to entry collapsed. The radio uses an ordinary ARM Cortex-M0+ MCU and an ordinary GNU toolchain; anyone who could build C could fork the firmware and add a feature. The result was a rapid proliferation of forks through 2024, each scratching a different itch — more features, a cleaner UI, a minimalist base, better scanning — all descending in one way or another from fagci’s work and the early community base.

Note. Quansheng did not fight the modding community, and the community generally reads that as pragmatic: the mods demonstrably sell more radios. The absence of legal pushback is part of why the ecosystem stayed healthy and public rather than going underground — a contrast worth keeping in mind against platforms where the vendor is hostile to modification.

4.3 The fork tree — who descended from whom

The lineage matters because it explains why the forks feel related and why features migrate between them.

        fagci (late 2023)
        reverse-engineered BK4819 + the spectrum analyzer
                 │
                 ▼
        OneOfEleven / 1o11
        a clean, minimalist firmware base
                 │
                 ├───────────────► egzumer
                 │                 = 1o11 base + fagci spectrum analyzer,
                 │                   merged into a polished daily-driver
                 │                   (V1 / DP32G030) — FROZEN at v0.22
                 │                        │
                 │                        ▼
                 │                 F4HWN (armel)
                 │                 forked from egzumer; UI/scan refinements
                 │                   ├─ V1 line: armel/uv-k5-firmware-custom
                 │                   │   (ends at v4.3, 2025-12-02)
                 │                   └─ V3/UV-K1 "Fusion" line:
                 │                       armel/uv-k1-k5v3-firmware-custom
                 │                       (active, v5.9.0, 2026-08-14)
                 │                            │
                 │                            ▼
                 │                     (further forks, e.g. VE3XLT,
                 │                      regional/feature variants)
                 │
                 ├───────────────► IJV — feature-heavy, experimental
                 │
                 └───────────────► VUURWERK — a newer V1-targeted build
                                   (v1.5.0, 2026-07-04)

The important reading of this tree: egzumer is the confluence point. It took the minimalist 1o11 base and fused fagci’s spectrum analyzer into one coherent, polished firmware, and that became the thing most V1 owners actually run. F4HWN then forked egzumer and refined it further, and when the new V3/UV-K1 silicon arrived F4HWN was the project that carried the ecosystem forward onto it. Features flow down and sideways through this tree, which is why, for example, “the fagci spectrum analyzer” appears in egzumer, F4HWN, and their descendants alike.

4.4 The active forks, each in its own words

fagci — the origin. The reverse-engineering mod that started it all and the home of the original spectrum analyzer. Historically important and still a reference point, but not the daily-driver choice today — its role was to prove what was possible and open the register map. Repo: fagci/uv-k5-firmware-fagci-mod.

OneOfEleven / 1o11 — the minimalist base. A clean, deliberately restrained firmware that prioritized correctness and a tidy codebase over feature count. Its significance is as the base that egzumer built on; a reader will rarely choose it directly today, but much of the ecosystem’s DNA is 1o11’s.

egzumer — the V1 daily-driver default. The practical winner on V1: 1o11’s base plus fagci’s analyzer, merged and polished into the firmware most V1 owners run. Headline features: wide RX, AM, the fagci spectrum analyzer (reached with F + 5), a well-organized UI, flexible channels and scan lists, and broad CHIRP support. Its defining current trait is that it is frozen at v0.22 (last update 2024-01-28) — complete and stable, but no longer developed. For a V1 radio it remains the recommended first flash. Repo: egzumer/uv-k5-firmware-custom.

F4HWN “Fusion” — the active line. armel’s fork of egzumer, and the project that now carries active development. On V1 it ran through v4.3 (2025-12-02) and then ended; development moved to the V3/UV-K1 “Fusion” line (v5.9.0, 2026-08-14), which merges the previously-separate F4HWN editions into a single build. Philosophy: an opinionated, well-presented refinement of egzumer with ongoing maintenance, attentive to the S-meter, scanning behaviour, and UI polish. On current silicon it is the default. Repos: armel/uv-k5-firmware-custom (V1, ≤v4.3) and armel/uv-k1-k5v3-firmware-custom (V3/UV-K1, v5.9.0).

VUURWERK — a newer V1 option. A more recently-dated V1-targeted build (v1.5.0, 2026-07-04), relevant to a V1 owner who wants recent maintenance rather than frozen egzumer or the ended F4HWN v4.3 line. Confirm its exact feature set against its repo before committing.

IJV — feature-heavy / experimental. A fork known for packing in features — the choice for someone who wants maximum capability and is comfortable with a busier, more experimental build. Not the first flash for someone who wants “it just works,” but a destination for tinkerers.

4.5 The feature-comparison table

The comparison below is at the ecosystem level — exact feature availability shifts with version, so treat it as the shape of the landscape rather than a datasheet.

Table 1 — 5. The feature-comparison table

Feature / trait	egzumer v0.22	F4HWN “Fusion” v5.9.0	VUURWERK v1.5.0	IJV
Target generation	V1 (DP32G030)	V3 / UV-K1 (PY32F071)	V1 (DP32G030)	V1 (mainly)
Development status	Frozen (2024-01-28)	Active (2026-08-14)	Newer V1 (2026-07-04)	Intermittent
Spectrum analyzer (fagci)	Yes (F + 5)	Yes	Yes	Yes
AM receive	Yes	Yes	Yes	Yes
SSB receive (crude)	Yes	Yes	Varies	Yes
Wide RX (18–1300 MHz, gaps)	Yes	Yes	Yes	Yes
Frequency counter	Yes	Yes	Yes	Yes
UI polish	High	Highest	Good	Busy / dense
Feature breadth	Broad	Broad + refined	Broad	Broadest / experimental
CHIRP module	Yes	Yes	Verify	Varies
Best for	V1 “it just works”	V3/UV-K1 daily-driver	recent-maintenance V1	maximal tinkering

Two cells deserve emphasis. The spectrum analyzer row is “yes” across the board because it descends from the same fagci code — the forks differ in UI around it, not in whether they have it. And the development-status row is the real decision driver: it is not that one fork is more capable than another so much as that they target different silicon at different maintenance tempos.

4.6 The frozen-V1 / active-V3 split, explained

The single most important structural fact about this ecosystem is counterintuitive: the most-installed firmware (egzumer, V1) is frozen, while the actively-developed firmware (F4HWN Fusion, V3) runs on the newer, smaller installed base. How did it end up this way?

   2023 ──────────────── 2024 ──────────────── 2025 ──────────────── 2026
    │                     │                      │                     │
 fagci RE         egzumer v0.22           F4HWN V1 line           F4HWN "Fusion"
 (BK4819 opened)  FROZEN 2024-01-28       ends at v4.3            v5.9.0 on V3/UV-K1
    │             (becomes the de-facto    (2025-12-02)           2026-08-14 (ACTIVE)
    │              V1 default and stays)        │                      ▲
    │                     │                     │   dev moves to new   │
 V1 (DP32G030) ───────────┴─────────────────────┴── silicon ──────────┘
 hardware era             │                                   V3 (PY32F071) + UV-K1
                          └── VUURWERK v1.5.0 (2026-07-04) keeps a V1 build fresh

The mechanism is straightforward once laid out. egzumer reached a mature, feature-complete state early (v0.22) and its author stopped there — on V1 there was little left to add, and a frozen-but-complete firmware is a perfectly good end state. Meanwhile Quansheng moved production to new MCUs (PY32F071, V3) and introduced the UV-K1. New silicon needs new firmware builds — the old binaries cannot run on it (Volume 2 §5) — and F4HWN is the project that did that porting and continued active development there. So development naturally followed the new hardware, leaving the large old installed base served by a frozen default.

The practical upshot for a buyer, restated: a V1 radio is an excellent, mature, well-documented platform whose best firmware will not change under you (egzumer v0.22, with VUURWERK and F4HWN v4.3 as recent-maintenance alternatives). A V3 or UV-K1 radio is on the live development line (F4HWN Fusion v5.9.0) and will keep gaining fixes and features. Neither is a mistake; they are different ownership trajectories, and knowing which you are buying into is the point.

4.7 Choosing a fork — a short rubric

• Have a V1 (DP32G030) and want “it just works”? egzumer v0.22. Frozen, mature, best-documented.
• Have a V1 and want recent maintenance? VUURWERK v1.5.0, or F4HWN v4.3 (the last V1 F4HWN).
• Have a V3 or UV-K1 (PY32F071)? F4HWN “Fusion” v5.9.0 — the active line, and effectively the only well-supported choice on that silicon.
• Want maximum features and enjoy tinkering? IJV, or build your own from source (sibling Volume 7).
• Just want to understand the origins / the register map? fagci — read it as the reference, flash it only to experiment.

In every case the rubric is downstream of the MCU: resolve the generation first (Volume 3 §4), and the fork choice is nearly made for you.

4.8 Licensing and the health of the ecosystem

The forks carry open-source licenses — the heritage runs through GPL-flavoured community code, and the V3/UV-K1 “Fusion” line is distributed under the Apache-2.0 license. The practical consequence of open licensing is exactly what the fork tree shows: features and fixes move freely between projects, a newcomer can read and build any of them, and no single maintainer’s disappearance kills the platform. That openness, combined with Quansheng’s hands-off posture toward modders, is why a $30 radio sustained years of active development across a changing hardware base.

The one health caveat worth stating is the version-churn point from Volume 1: this is volunteer, hobby development, and maintenance tempo varies by project and by hardware generation. “Active” and “frozen” are states a project can move between, and the dates in this series (current as of 2026-10-17) are the right way to read any claim. Before flashing, check the live repo for the generation in hand.

Volume 5 turns from the ecosystem to the single feature that defined it: the spectrum analyzer and the receive unlocks — how the BK4819 is driven to sweep a band, what the waterfall actually shows, and where the honest line sits between this $30 triage tool and a real SDR.

Fork names, lineage, versions, and dates are drawn from the fagci, OneOfEleven/1o11, egzumer, F4HWN (armel), and VUURWERK projects as of 2026-10-17. The lineage tree reflects the forks’ own documented heritage (fagci → 1o11 → egzumer → F4HWN). Version-specific claims are dated; verify against the live repository for the relevant MCU generation before flashing.