The Beken BK4819 RF SoC, the three MCU generations and why their firmware is incompatible, the display, battery and USB, the SMA-F antenna, and the stock-firmware band and TX limits

2.1 About this Volume

This volume opens the hood. The custom-firmware story in the rest of the series is only possible because of specific silicon choices Quansheng made — chiefly the decision to build a mass-market handheld around the Beken BK4819, a software-defined narrowband RF SoC with a large, reprogrammable register map, driven by a small ARM Cortex-M0+ microcontroller. This volume describes that hardware: what the BK4819 is and what the firmware can make it do, the three distinct microcontrollers across the radio’s production life and the concrete reason a firmware binary built for one will not run on another, and the supporting hardware — display, battery, USB, antenna — that sets the practical limits.

The reader should come away understanding two things precisely: why the UV-K5 is hackable at all (the BK4819’s programmability), and why the ecosystem is fragmented into firmware-incompatible generations (the MCU changes). Those two facts drive every practical decision in Volumes 3–5. Radio operation — how to actually work a band once the radio is modded — is the peer Scanners project’s territory and is not repeated here.

2.2 Block diagram — how the radio is wired

                   Quansheng UV-K5 — functional blocks

      ┌─────────────┐        SPI/GPIO        ┌─────────────────────┐
      │   MCU       │◀──────────────────────▶│   BK4819            │
      │ Cortex-M0+  │  register reads/writes  │   RF SoC            │
      │ (DP32G030 / │                         │ (RX/TX narrowband,  │
      │  PY32F030 / │        ┌───────────────▶│  FM/AM/SSB demod,   │
      │  PY32F071)  │        │                │  RSSI, tone/DTMF)   │
      └──────┬──────┘        │                └──────┬──────┬───────┘
             │               │                       │      │
     ┌───────┴──────┐   ┌────┴─────┐          ┌───────┘      └───────┐
     │ Monochrome   │   │ Keypad   │          │                      │
     │ LCD (top)    │   │ + PTT    │     ┌─────┴─────┐          ┌─────┴─────┐
     └──────────────┘   └──────────┘     │ RX front- │          │ TX PA +   │
                                         │ end filt. │          │ LPF       │
     ┌──────────────┐   ┌──────────┐     └─────┬─────┘          └─────┬─────┘
     │ 1600 mAh LiPo│   │ USB-C or │           └──────────┬───────────┘
     │ + charge mgmt│   │ micro-USB│                      │
     └──────────────┘   │ (charge/ │                 ┌────┴────┐
                        │  flash)  │                 │ SMA-F   │
                        └──────────┘                 │ antenna │
                                                     └─────────┘

The architecture is the key to the hack: the MCU holds no RF intelligence of its own. It is a controller that pokes the BK4819’s registers over SPI and reads results back. Every demodulator, every bit of tuning, every RSSI measurement lives in the BK4819. The stock firmware is simply one particular, conservative sequence of register writes; a custom firmware is a different, more adventurous sequence. That is the whole reverse-engineering project in one sentence — figure out the register map, and you control the radio.

2.3 The Beken BK4819 — the RF SoC the whole hack rests on

The BK4819 is a highly-integrated narrowband transceiver SoC: a single chip that handles the RF and IF chain, demodulation, and audio for a conventional two-way radio. It is a superheterodyne design with a programmable synthesizer, which is the detail that makes it tunable far outside the UV-K5’s advertised bands. Its headline traits:

Wide synthesizer range. The on-chip PLL/VCO can be programmed across roughly 18 MHz to 1300 MHz, which is why custom firmware can tune so widely. This is a synthesizer capability, not a promise of sensitivity at every point in that range.
A hard baseband gap. Reception in roughly the 630–840 MHz region is unavailable — a limitation in the BK4819’s own baseband/IF that software cannot work around. Any claim of “continuous 18–1300 MHz” is wrong on this point; the gap is real and in the silicon.
Multiple demodulators. FM (narrowband and wide), and the hooks to do AM and a DSP-assisted SSB. The stock firmware exposes only FM; the custom firmware drives the AM and SSB paths.
Rich instrumentation registers. RSSI, a built-in frequency-measurement capability, tone/CTCSS/DCS and DTMF handling, squelch — all readable and controllable from the MCU over SPI. The RSSI and frequency-read registers are exactly what the spectrum analyzer and frequency-counter mods exploit (Volume 5).
Narrowband by nature. The receiver’s instantaneous bandwidth is narrow — appropriate for a voice channel, measured in low tens of kHz. This is the single most important fact for understanding the analyzer’s limits: there is no wide instantaneous capture, so the “spectrum” view is built by stepping the narrow receiver across a span and plotting RSSI at each step.

Tip. Hold onto the phrase “narrowband superheterodyne with a programmable PLL.” It explains both the magic (tune anywhere the synthesizer reaches) and the limits (you only ever hear a narrow slice at a time, and the front-end filtering is fixed for the ham bands). Everything the custom firmware does is a creative re-use of a chip built to be a voice radio.

2.4 What the custom firmware unlocks on the BK4819

The stock firmware uses a small, safe subset of the BK4819’s registers. The reverse-engineering effort mapped the rest, and the custom firmware uses them. Concretely:

Table 1 — The stock firmware uses a small, safe subset of the BK4819's registers. The reverse-engineering effort mapped the rest, and the custom firmware uses them. Concretely

Unlock	BK4819 mechanism the firmware drives
Wide RX tuning	Program the PLL across its full 18–1300 MHz range (minus the 630–840 MHz baseband gap) instead of only the ham segments
AM receive	Select the AM demodulator path and set appropriate front-end gains (LNA / mixer / PGA)
SSB receive	Use the AM/IF path plus firmware DSP to approximate single-sideband — crude but listenable
Spectrum sweep	Step the PLL across a span, read the RSSI register at each step, plot the result — the analyzer (Volume 5)
Frequency counter	Use the chip’s frequency-measurement register to read a strong nearby carrier
Tone / squelch tricks	Drive the CTCSS/DCS/DTMF and squelch registers for scanning and tone-scan features
Wider TX tuning	Program the PLL to key up outside the ham bands (legally gated — see §9 and Volume 10)

The pattern is consistent: no new hardware, just the MCU issuing register writes the factory firmware never issued. This is also why the unlocks are bounded by physics — the firmware cannot give the chip an instantaneous bandwidth it does not have, cannot cross the 630–840 MHz baseband gap, and cannot make the fixed RX front-end filtering sensitive on bands it was not cut for.

2.5 The three MCU generations — and why their firmware is incompatible

The BK4819 is constant across the whole UV-K5 family. The microcontroller is not, and that is the source of the ecosystem’s fragmentation. Over the radio’s production life Quansheng shipped three different MCUs:

V1 — DP32G030. The original. An ARM Cortex-M0+-class part. The entire reverse-engineering effort and the mature forks (egzumer, the V1 F4HWN line, VUURWERK) were built on it.
V2 — PY32F030. A mid-production change to a Puya PY32-series Cortex-M0+ part (community-reported). A transitional generation with the narrowest fork support.
V3 — PY32F071. The current generation, a larger Puya PY32 part, shared with the UV-K1. The actively-developed F4HWN “Fusion” line targets it.

Why is the firmware not portable across them? Because a bare-metal firmware image is tied to the exact MCU it was compiled for, in several ways at once:

   Why a V1 binary will not run on a V3 (and vice versa)

   ┌────────────────────────────────────────────────────────┐
   │ 1. Different CPU peripherals & memory map                │
   │    DP32G030, PY32F030, PY32F071 have different register   │
   │    addresses for clocks, GPIO, SPI, timers, flash ctrl.  │
   │                                                          │
   │ 2. Different flash / RAM sizes & layout                  │
   │    The linker places code/data at addresses that only    │
   │    exist on the target part.                             │
   │                                                          │
   │ 3. Different bootloader                                  │
   │    Each generation's factory bootloader speaks its own   │
   │    flashing protocol / expects its own image format.     │
   │                                                          │
   │ 4. Flash masking / protection (notably on DP32G030)      │
   │    the bootloader region is masked off; flashing outside  │
   │    the documented method risks losing the bootloader.    │
   └────────────────────────────────────────────────────────┘
   ⇒ A firmware binary is MCU-generation-specific. Full stop.

In short: it is not that the forks chose not to be cross-compatible — a binary compiled against one Cortex-M0+ part’s peripheral map, memory layout, and bootloader simply cannot execute on a different part. This is ordinary bare-metal reality, but it is the single most consequential practical fact for a UV-K5 buyer, so it is worth stating without hedging: identify your MCU first; it dictates which firmware you can run. The reliable identification is the chip marking on the board, cross-checked against the version string the stock radio reports.

Warning. The DP32G030 (V1) uses flash masking to protect the bootloader. Flashing by any method other than the documented, fork-sanctioned one risks bricking the radio by destroying the bootloader. The sibling Volume 6 covers the safe flashing procedures; the rule here is: use the fork’s own flasher or web-installer, not an improvised approach.

2.6 The generations comparison table

Table 2 — 6. The generations comparison table

	V1	V2	V3
MCU	DP32G030	PY32F030	PY32F071
CPU class	ARM Cortex-M0+	ARM Cortex-M0+	ARM Cortex-M0+
Also used in	UV-K5, UV-K5(8), UV-K6 (early)	mid-run UV-K5 / UV-K6	UV-K5 V3, UV-K1
RF SoC	BK4819	BK4819	BK4819
Installed base	Largest	Transitional	Current / growing
Lead firmware	egzumer v0.22 (frozen), F4HWN v4.3, VUURWERK v1.5.0	narrow — confirm support	F4HWN “Fusion” v5.9.0 (active)
Flash masking caveat	Yes (bootloader protection)	—	—
Buying note	Excellent, mature, but frozen path	Awkward middle — verify fork support	Actively-developed path

The table makes the ownership split concrete: the largest, best-documented installed base (V1) is served by a frozen default (egzumer), while the active development (Fusion) is on the newest generation (V3/UV-K1). Neither is wrong to buy; they are different experiences. The full per-radio pairing — including the UV-5R Plus and the Motorola-branded “K5(X8)” — is the mandatory table in Volume 3.

2.7 Display, controls, battery, and USB

The non-RF hardware is modest and sets some practical ceilings worth knowing before expecting too much of the firmware mods.

Display. A small monochrome LCD at the top of the radio. It is the canvas for the spectrum analyzer and waterfall, which is why those views are coarse: there are only so many pixels, and the refresh is slow. Do not expect an SDR-grade waterfall on it (Volume 5).
Controls. A standard numeric keypad plus side keys and PTT. The custom firmware overloads key combinations heavily (e.g. the egzumer analyzer is reached with F then 5), so the learning curve is largely about memorizing key sequences.
Battery. A 1600 mAh LiPo pack. Adequate for a few hours of mixed RX/TX; a spare pack is the standard field-day accessory. Spectrum sweeping and constant scanning are more power-hungry than idle monitoring.
USB and charging. Production batches differ: newer batches charge over USB-C, older batches over micro-USB. The USB port is for charging and (with the right cable and tool) is not the flashing interface — flashing happens over the radio’s own serial/programming path via the bootloader, driven by k5prog or a web-flasher (sibling Volume 6). The USB-C-versus-micro-USB split is a batch marker, not a generation marker; it does not by itself tell you the MCU.

Note. Do not conflate the USB-C-vs-micro-USB batch distinction with the V1/V2/V3 firmware generations. They correlate loosely with production era but are independent facts: the connector tells you nothing reliable about which MCU is inside. Always identify the MCU by the chip marking, not by the charge port.

2.8 The SMA-F antenna and the front-end reality

The UV-K5 uses an SMA-F (female) antenna connector on the radio body — meaning the antenna carries the male pin. The stock rubber-duck antenna is cut for the 2 m / 70 cm ham bands and is mediocre even there; a better whip (a Nagoya NA-771, or NA-701 for compactness) is the standard upgrade for any serious listening.

But the antenna is only half the front-end story, and the more important half for the hacker is fixed in the hardware: the radio’s RX front-end filtering is designed for the ham bands. The custom firmware can tune the BK4819’s synthesizer to, say, 100 MHz airband or 900 MHz, but the signal still has to pass through input filtering optimized for VHF/UHF ham use. The practical result is that wide-RX sensitivity falls off — sometimes sharply — outside the design bands. “Tunes there” is not “hears well there.” A better antenna helps on bands it is cut for; it cannot undo fixed front-end filtering. This is the physical reason the honesty ledger in Volume 1 insists the UV-K5 is not a substitute for an SDR with a flat, wideband front end.

2.9 Stock-firmware band and TX limits

Out of the box, the stock firmware is deliberately conservative:

Table 3 — Out of the box, the stock firmware is deliberately conservative

Parameter	Stock firmware
RX coverage	~50–600 MHz (region-dependent)
Demodulation	FM / WFM only
TX bands	144 MHz (2 m) and 430 MHz (70 cm), region-limited
TX out of ham bands	Blocked
Spectrum / counter	Absent

These limits are software policy, not hardware limits — which is exactly why custom firmware can lift them. The custom firmware exposes the BK4819’s full tuning range for RX and can also remove the TX band restriction. Removing the TX restriction does not grant legal authority to use it. The chip will key up out of band, but that is illegal in nearly every jurisdiction, can interfere with safety-critical services, and drives a PA and antenna not matched for the frequency. The correct default posture is receive-only outside one’s licensed bands, and transmit only within them under the applicable rules.

Warning — RF-legal (brief; depth in Volume 10). Wide RX unlock is legal to listen with in most places (local laws on what you may monitor vary). TX unlock is a different matter entirely: transmitting outside your license and the band’s rules is unlawful. This series keeps the rule to one line here — unlock RX freely, treat TX as license- and region-gated — and leaves the full legal treatment to the sibling Volume 10 and the hub’s legal/ethics note.

2.10 What this means for the hacker

Three takeaways carry into the rest of the series. First, the UV-K5 is hackable because the intelligence lives in a reprogrammable RF SoC and the MCU is just a register-poking controller — reverse-engineer the BK4819 register map and the radio is yours. Second, the hardware fragments the ecosystem: three MCU generations (DP32G030, PY32F030, PY32F071), firmware-incompatible by the plain reality of bare-metal builds, so the first question for any owner is always “which MCU?” Third, the mods are bounded by physics the firmware cannot rewrite — the narrow instantaneous bandwidth, the 630–840 MHz baseband gap, and the fixed ham-band front-end filtering — which is why the spectrum mode is triage and not instrumentation.

With the hardware understood, Volume 3 lays out the mandatory supported-hardware table: every radio in the family paired with the firmware forks that run on it, with build dates, frozen-versus-active status, and where to get each. Volume 4 then tells the story of how the forks came to be, and Volume 5 takes apart the signature analyzer mod in detail.

Hardware facts in this volume are drawn from the fagci/egzumer/F4HWN repositories and community documentation of the BK4819 register map and the MCU generations, as of 2026-10-17. The 630–840 MHz baseband gap and the 18–1300 MHz synthesizer range are community-documented BK4819 behaviours; the PY32F030 (V2) identification is community-reported. Radio operation is deferred to the peer Scanners project.

Quansheng UV-K5 Volume 2 — The Hardware