3.1 About this Volume

This is the reference volume the rest of the series points at: the single table that answers, for a given radio X, which firmware will run on it, which build is current, and where to get it. Everything else in the deep dive is narrative; this is the lookup. It is deliberately dense and deliberately dated, because the one thing a supported-hardware table must never do is quietly go stale and send someone to flash the wrong binary.

The volume also covers the two things a reader needs around the table to use it safely: how to identify which MCU generation a given physical radio actually is (because that, not the model name on the case, decides the firmware), and the flashing tools the “Where to get it” column refers to (k5prog and the browser web-installers). The detailed flashing procedure — offsets, recovery, the bootloader dance — is the sibling Volume 6; this volume is the pairing reference that tells you which firmware to point those tools at.

None of the radios or forks below is a Hack Tools hub tool in its own right, so every reference is a normal external link, not an intra-hub cross-link.

3.2 How to read the table — radio vs MCU vs fork

Three independent facts combine to decide what a given unit can run, and conflating them is the usual mistake:

   Model name   ──┐
   (UV-K5, K6,    │        The MODEL tells you the case and the band plan.
    UV-K1, …)     │        The MCU tells you which binary will run.
                  ├──────▶ The FORK is the firmware project you choose,
   MCU generation │        constrained by the MCU.
   (DP32G030 /    │
    PY32F030 /    │        ⇒ Always resolve MCU first, THEN pick a fork.
    PY32F071)   ──┘

A model name alone is not enough, because the same model (UV-K5) was produced across more than one MCU generation during its life. The authoritative fact for firmware selection is the MCU (§4). The table below is therefore organized by radio, but its load-bearing column is “MCU / generation.”

3.3 Where this firmware runs — supported radios and firmware

Table 1 — 3. Where this firmware runs — supported radios and firmware

Radio	MCU / generation	Firmware fork & latest build	Feature level / notes	Where to get it
UV-K5 (V1)	DP32G030 (V1)	egzumer v0.22 — frozen (last update 2024-01-28)	The most-installed custom firmware on V1. Merges OneOfEleven’s base + fagci’s spectrum analyzer. Mature, complete, stable; no new features coming. The de-facto V1 default.	github.com/egzumer/uv-k5-firmware-custom · web-flasher on the repo / wiki · or k5prog
UV-K5 (V1)	DP32G030 (V1)	F4HWN v4.3 (2025-12-02) — last V1 release	Actively-developed through v4.3, then the V1 line ended (development moved to V3/UV-K1). Polished UI, scanning, S-meter work. Good choice for a V1 owner who prefers a more recent build than frozen egzumer.	github.com/armel/uv-k5-firmware-custom · web-flasher / k5prog
UV-K5 (V1)	DP32G030 (V1)	VUURWERK v1.5.0 (2026-07-04)	A newer V1 option — a more recently-maintained choice than the frozen/ended builds above. Confirm feature set against the repo before flashing.	VUURWERK project repo · web-flasher / k5prog
UV-K5 (V1)	DP32G030 (V1)	fagci (origin) / IJV / 1o11 (OneOfEleven)	Historical / specialist V1 builds: fagci is the reverse-engineering origin and the source of the spectrum analyzer; IJV is feature-heavy; 1o11 is the minimalist base many forks descend from. For experimenters, not first-timers.	github.com/fagci/uv-k5-firmware-fagci-mod · IJV & 1o11 repos
UV-K5 V3	PY32F071 (V3)	F4HWN “Fusion” v5.9.0 (2026-08-14)	The actively-developed line. “Fusion” merges the previously-separate F4HWN editions into one build. Current flash/RAM footprint is near the part’s limits (~92% flash). The V3 default.	github.com/armel/uv-k1-k5v3-firmware-custom · web-flasher / k5prog
UV-K5(8)	PY32F071 (V3-class)	F4HWN “Fusion” v5.9.0 (2026-08-14)	The “(8)” variant on current silicon runs the Fusion line alongside the UV-K5 V3. Verify the exact MCU marking on your unit before flashing.	github.com/armel/uv-k1-k5v3-firmware-custom
UV-K6	DP32G030 (early) or PY32F071 (later)	egzumer / F4HWN v4.3 (if DP32G030) or F4HWN “Fusion” v5.9.0 (if PY32F071)	The UV-K6 shipped across generations; the MCU, not the “K6” name, decides the firmware. Identify the chip first, then pick the matching V1 or V3 build.	egzumer / F4HWN V1 repo or the uv-k1-k5v3 repo — per the MCU
UV-K1	PY32F071 (V3)	F4HWN “Fusion” v5.9.0 (2026-08-14)	Shares the V3 silicon with the UV-K5 V3; the Fusion line explicitly targets it. The current actively-developed path.	github.com/armel/uv-k1-k5v3-firmware-custom · web-flasher / k5prog
UV-5R Plus	varies by batch	Case-dependent — confirm MCU	A UV-K5-family cousin; custom-firmware support depends on the exact board/MCU inside, which varies. Not a clean “flash this” target — identify the MCU and confirm fork support before buying for modding.	Confirm MCU first; then the matching V1 or V3 repo if supported
K5(X8) (Motorola-branded variant)	UV-K5-family silicon (BK4819)	As per its actual MCU — treat as a rebadged UV-K5	A Motorola-branded rebadge of the UV-K5 platform. Mod support follows whatever MCU it actually carries; verify the chip marking rather than trusting the badge.	Identify MCU; use the matching V1 or V3 repo if supported

Note. The dominant pattern is simple once the clutter is cleared: DP32G030 (V1) radios → egzumer (frozen default), F4HWN v4.3, or VUURWERK; PY32F071 (V3) radios and the UV-K1 → F4HWN “Fusion” v5.9.0. The PY32F030 (V2) middle generation has the narrowest support and no clean default — confirm before buying one specifically to mod. The model name is a hint; the MCU marking is the answer.

3.4 Identifying your MCU before you flash

Because the table’s load-bearing column is the MCU, identifying it correctly is the step that prevents a wrong-binary flash. Three methods, most-to-least reliable:

1. Read the chip marking. Open the radio (or consult a teardown photo for your batch) and read the marking on the microcontroller: DP32G030, PY32F030, or PY32F071. This is definitive.
2. Read the stock firmware version string. The stock radio reports a firmware/version identifier; batches and generations correlate with specific stock-version families. Less definitive than the chip marking, but a useful cross-check, and the fork communities maintain mappings.
3. Infer from production era / purchase date — least reliable. V1 is the oldest, V3 the newest, but production overlapped and the USB connector (micro-USB vs USB-C) is a batch marker, not a generation marker. Treat era as a weak hint only.

Warning. Do not pick a firmware from the model name or the purchase date alone. The same “UV-K5” or “UV-K6” exists across MCU generations. The chip marking (method 1) is the only fully reliable identifier, and the one worth the few minutes it takes to open the case before a first flash.

3.5 The flashers — k5prog and the web-installers

The “Where to get it” column refers to two flashing paths; both talk to the radio over its bootloader, which you enter by powering the radio on while holding the PTT (the exact key sequence is in the sibling Volume 6).

• k5prog — a Python command-line flasher (the widely-used sq5bpf/k5prog and community forks). The scriptable, cross-platform path; the choice for automation and for building the flash into a reproducible workflow. Example shape (illustrative — see Volume 6 for the authoritative invocation and offsets):

# Illustrative only — confirm the exact flags/offsets for your fork in Volume 6
python3 k5prog.py -f egzumer_v0.22.bin -YYY   # write firmware over the bootloader

• Browser web-flashers — most active forks publish a Web Serial / WebUSB installer page (reached from the fork’s repo or wiki) that flashes directly from Chrome/Edge with no local toolchain. The low-friction path for a first flash: plug in the programming cable, open the page, pick the build, flash. This is usually the recommended route for newcomers because the page ships the correct build for the generation and removes the chance of a Python/driver misstep.

Both paths require the right programming cable (the Kenwood-style two-pin accessory cable — an acoustic/UART path, not the USB charge port). The flashing procedure, recovery from a failed flash, and the DP32G030 bootloader-masking caution are the sibling Volume 6’s job; this volume only identifies which firmware to flash.

3.6 Reading the status column honestly

The table marks builds “frozen,” “last release,” or “active” deliberately, because the status is as important as the version number:

• Frozen (egzumer v0.22, 2024-01-28). Complete and stable, not abandoned-as-broken. It remains the most-installed and best-documented V1 firmware. “Frozen” means no new features, not “do not use” — for many V1 owners it is still the right first flash.
• Last release (F4HWN v4.3 on V1, 2025-12-02). The V1 F4HWN line ended at v4.3 when development moved to the V3/UV-K1 Fusion line. A V1 owner can still use v4.3; they just will not see new F4HWN features on V1.
• Newer V1 option (VUURWERK v1.5.0, 2026-07-04). A more recently-dated V1 build than the two above; the choice for a V1 owner who specifically wants recent maintenance. Confirm its feature set against the repo.
• Active (F4HWN “Fusion” v5.9.0, 2026-08-14). The live development line, V3/UV-K1 only. This is where ongoing fixes and features land.

The honest summary: the most-installed firmware and the most-actively-developed firmware are on different hardware generations. A V1 buyer gets a mature, frozen (or recently-maintained) path; a V3/UV-K1 buyer gets the live one. Both are good; they are simply different. Dates are current as of 2026-10-17 — re-check the specific repo before flashing, because at least the Fusion line continues to move.

Volume 4 tells the story behind this table: how fagci’s late-2023 reverse engineering produced the fork explosion, what each fork’s philosophy is, and why the ecosystem settled into the frozen-V1 / active-V3 split the table records.

Firmware versions, dates, and repository locations are current as of 2026-10-17 and are drawn from the egzumer, F4HWN (armel/uv-k5-firmware-custom and armel/uv-k1-k5v3-firmware-custom), fagci, and VUURWERK projects. The PY32F030 (V2) generation and the per-model MCU variability (UV-K6, UV-5R Plus, K5(X8)) are community-reported; verify the chip marking on any specific unit before flashing. Flashing procedure and recovery are the sibling Volume 6.