UV-K1 and UV-K5 V3 get a second open firmware lineage

Three forks deep, ported to a different microcontroller

The lineage is the first thing to understand about this firmware. The repository is a fork of the F4HWN custom firmware, which was itself a fork of the Egzumer custom firmware. The F4HWN work extended what had been done for the UV-K5 V1, and this repository adapts it to the newer UV-K1 and UV-K5 V3 built around the PY32F071 MCU, where the V1 used the DP32G030.

That means the codebase is the result of repeated porting rather than a fresh implementation. The attribution is explicit: the work is by @muzkr and @armel jointly, with a large thank you to DualTachyon, who released the very first open source firmware for the UV-K5 V1 and made the rest possible.

The licence is Apache 2.0, carrying forward the original copyright of DualTachyon. The project asks that forks stay open source, and gives four reasons: it aligns with the intent of the licence, supports the amateur radio and embedded development community, avoids fragmentation, and lets others study, audit and improve the firmware. The appeal to ham spirit is spelled out as sharing knowledge and experimenting together rather than closing things off or claiming them as your own.

The last push was on 2026-10-20 and releases v6.2.0, v6.1.0 and v6.0.0 landed in October, September and October 2026 respectively, so this is actively worked software rather than an abandoned port.

The warning at the top of the page is the honest part

Before the feature list, the documentation carries a warning in a callout box, and it is blunt enough to quote rather than paraphrase.

It says the firmware has no real brain, please use your own, and that you should use it at your own risk entirely. There is absolutely no guarantee that it will work in any way, shape or form on your radio, and it may even brick the radio, in which case you would need to buy another radio. It ends with anyway, have fun. The French version of the same warning says the same thing.

The theme is that this is firmware from the community, for the community, without the safety net of a manufacturer behind it. On a radio costing real money, that is not a rhetorical caution. It is the actual risk profile.

Two procedural warnings sit alongside it, and both are actions rather than statements. The CHIRP note says that, as with many other firmwares, you need a dedicated driver, and that the matching CHIRP driver is now bundled with each release so you can download firmware and driver together from the releases page. The calibration caution recommends backing up your calibration data with UV Studio immediately after flashing, describing it as a good habit to adopt.

That calibration backup is the detail to take seriously. Calibration data is per radio and per band, and losing it is not recoverable without the original unit, so the ordering of the instructions matters: flash, then immediately dump the calibration, before anything else.

Fusion is the base edition and the others trade features for stability

The firmware is published as a family of editions, and the naming has a specific logic.

Fusion is the generic reference edition for the UV-K1 and UV-K5 V3. It is intended for everyday use and is the base inherited by the specialized editions. It includes Fagci's spectrum analyzer, broadcast FM radio and VOX, UV Studio with integrated K5Viewer screen mirroring, screenshots and remote keyboard control, advanced RX audio profiles and an Audio Scope, automatic RX and TX activity logging with RF Log, Full Watch across VFO A, VFO B and up to two priority channels, and multiboot with one protected Main backup and four user firmware slots. It also carries independent Multiconfig banks, switchable at runtime through `SetCfg`.

The specialized presets extend Fusion. Transfer adds AirCopy and BEAM wireless channel transfer. FieldOps adds first-responder controls, Fox Hunt and Morse Beacon support.

Labs is the one to read the warnings about. It is the experimental edition, carrying the broad feature selection of the others plus the overlay-apps platform, where apps are loaded from external Flash and run in a 4 KiB RAM overlay. The documentation calls it the newest and least settled work and says to expect rough edges. It is explicitly not a strict superset: features may be exchanged between releases to preserve stability and memory headroom.

That last sentence is the real constraint on this hardware. The MCU has enough flash for a lot of features and not enough for all of them at once, so the editions are a way of packaging choices rather than a ladder of increasing capability.

The Docker image is a self-contained ARM toolchain

Building the firmware needs a cross-compiler and CMake, and the repository ships a Dockerfile that assembles the whole environment. The base image is a Python devcontainer image on bookworm:

FROM mcr.microsoft.com/devcontainers/python:3.10-bookworm

From there the image installs the base build tools, with build-essential, cmake, ninja-build, python3, curl, xz-utils and ca-certificates, and removes the apt lists afterwards to keep the layer small.

The interesting part is the ARM GNU toolchain install, which is written to work with or without BuildKit. It takes the toolchain version as an argument, defaulting to 13.3.rel1, and derives the host architecture from TARGETARCH when that is provided and from uname -m otherwise, mapping amd64 and x86_64 to x86_64 and arm64 and aarch64 to aarch64, with x86_64 as the fallback for anything else. It then downloads the matching arm-none-eabi tarball from the Arm Keil developer site, extracts it, and moves the directory to /opt/toolchain, with the toolchain's bin directory prepended to PATH.

That fallback chain matters in practice, because a host running an Arm Mac would otherwise need the architecture passed in explicitly. The build then happens in /src.

The repository root shows the rest of the build setup: CMakeLists.txt and CMakePresets.json for the CMake side, compile-firmware.sh, compile-app.sh and compile-with-docker.sh as the entry points, and a Dockerfile plus Dockerfile-ms and Dockerfile-slim for variant builds. The source is split into App/, Core/, Drivers/ and Middlewares/, with cmake/, tools/ and images/ alongside.

Flashing goes through UV Studio and CHIRP

The table of contents lists both a manual and a flashing section, and the flashing path is UV Studio, which is the same tool the README recommends for backing up calibration data.

The separate UV Studio project at armel.github.io/uvstudio is what makes the workflow coherent. The same application that flashes the firmware also dumps and restores the calibration data, and the documentation links the calibration dump page directly. That is why the caution to back up calibration immediately after flashing is practical advice rather than a generic warning: you already have the tool open.

The K5Viewer part of UV Studio adds screen mirroring, screenshots and remote keyboard control over the radio's own data link. For the UV-K5 V3 that means the radio's screen can be viewed and driven from a computer, which is a substantial capability on a handheld with a small display.

CHIRP is the separate matter. The documentation explains that, as with many other firmwares, a dedicated CHIRP driver is required, and that the matching driver is now bundled with every release of this repository so the firmware and the driver can be downloaded together from the releases page. Bundling the driver with the release removes a version mismatch that would otherwise show up as a radio that CHIRP can see but cannot talk to properly.

The pairing of UV Studio for flashing and calibration with CHIRP for programming channels is a workflow, not a preference, and the releases are the place where both pieces are kept in step.

What a community firmware can and cannot promise you

It is worth being clear about the difference between this firmware and the factory firmware, because the README is explicit about it in the warning and the licence request.

What you get is feature depth. A spectrum analyzer on a handheld radio, an Audio Scope for looking at receive audio, RF Log for automatic activity logging, Full Watch across two VFOs plus priority channels, multiboot with four user slots, and screen mirroring with remote keyboard control. Those are tools that would not appear on a factory release, and the audience for them is people doing real radio work, from contest operators to fox hunters.

What you do not get is a support path. There is no manufacturer behind this build, the warning says plainly that it may not work and may brick the radio, and the same honesty extends to the feature set, where Labs is labelled experimental with rough edges and where editions are allowed to drop features from each other to preserve memory headroom.

The comparison with the factory firmware is therefore the comparison between a device that is supported and a device that is merely capable. If your priority is reliability, the stock firmware on a radio you rely on is the safer choice. If your priority is what the hardware can do, this is a remarkably deep firmware for a handheld, developed by people who clearly enjoy pushing the limits of the platform, and the Apache 2.0 licence and the open development model mean you can read exactly how any of it works.

Editorial conclusion

Adopt this firmware if you own a UV-K1 or UV-K5 V3 and want features the stock radio does not have, since the port carries a spectrum analyzer, screen mirroring and multiboot firmware slots that the factory firmware lacks. Skip it if your radio is the older UV-K5 V1, because that platform is served by a different branch of the same lineage, and read the warning before you start, since the authors state it may brick the radio. Verify first that your model is the K1 or the K5 V3 with the PY32F071 chip, back up your calibration data with UV Studio before flashing, and confirm the CHIRP driver bundled with the release matches the version you are running.

Frequently asked questions

Official sources

1. armel/uv-k1-k5v3-firmware-custom on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases