Baofeng DM-1801 Pro hardware

An HR_C7000 radio: the DM-32UV's SoC and RF chip family with a monochrome display and a different pin map. This page records what the DM-1801 Pro does and where it differs from hardware-dm32.md, which is the reference for register names and the pin-index scheme. RadioFoundry first ran on a radio on 2026-10-15. A value marked (measured) was checked on a radio running RadioFoundry, (unverified) is not confirmed on a radio or in a datasheet, and (?) is not determined. Unmarked values come from the radio's observed operation.

1. What is the same as the DM-32UV, and what is not

2. SoC and boot

3. Pin map

Index = GPIO pin index (0-31 PTA, 32-63 PTB, 64-95 PTC). "Boot" is the level the radio drives at start-up.

3.1 Pins

Not found: the flashlight pin, USB. The programming cable's plug switches the internal speaker off in hardware: with it in, the amplifier on and the speaker source selected, the speaker is silent (measured).

Speaker paths (measured):

With the squelch closed the FD6818 outputs noise, so PTB15 stays low then: switching it high at the end of a beep let a burst of static through. The amplifier (PTA16) turns off before PTB15 changes.

3.2 Display bus

Chip select PTC3 low for each byte, clock PTC4 low then high per bit, data PTC8 set while the clock is low, data/command PTC6, reset PTC2. Bits go out MSB first.

4. Peripherals and IO mux

I2C2 0x14080000 carries the SoC's real-time clock (8.2). SPI1 0x140B0000 has an SD card driver that the firmware never starts (8.3). SPI3 0x14150000 makes an 8-byte identity read (6.3). UART1-3 are never used: no GPS and no UART Bluetooth.

5. RF chip

5.1 Bus

Three-wire serial, bit-banged: clock PTA7, data PTA8, chip select PTA30. A frame is CS low, an 8-bit address (bit 7 set for a read), 16 data bits MSB first, CS high. The radio's wait per half clock is five passes of a short busy loop, well under a microsecond at the 168 MHz core clock, so with the GPIO calls a frame takes some tens of microseconds (unverified; an earlier reading took the loop for 5 microseconds). RadioFoundry clocks it at 1 us per half clock, still slower than the radio; the per-burst switch (5.6) needs the speed.

5.2 Frequency and band

• Unit 10 Hz, 32 bits: register 0x39 = high 16 bits, 0x38 = low 16 bits. 446.000 MHz = 0x02A88AC0. No offset.
• Ranges: 136-174 MHz and 400-470 MHz, plus an air band window of 108-136 MHz on the same chip, which RadioFoundry receives in AM (rx_am, airband-and-broadcast.md 3).
• VHF / UHF split at 200 MHz. The channel set-up keeps two band bits, one for the RX and one for the TX frequency, each set above 200 MHz. The RX bit picks the RX path pin and the squelch rows; the TX bit picks the TX path pin and the PA, modulation and register 0x40 rows (6.4).
• No band-word table: register 0x1A is never written; register 0x40 is 0x3480 plus a calibration byte: 0x70 at power-on, and on FM transmit a byte interpolated from the calibration page (6.4).
• Bandwidth register 0x43: 0x3048 for DMR and for 12.5 kHz FM, 0x3028 for 25 kHz FM. The radio's channel set-up picks 0x3048 for a digital channel, and for an analog one by the channel's Narrow / Wide bit (Narrow 0x3048, Wide 0x3028). Its bandwidth table also holds 0x2028 and 0x205C, but nothing selects them.

5.3 Register tables

Power-on, in order: 0x00=8000, 0x00=0000, 0x37=9D1F, 0x13=03DF, 0x12=03DB, 0x11=033A, 0x10=0318, 0x14=0210, 0x19=1041, 0x1C=0422, 0x1D=2AAB, 0x1E=4C58, 0x1F=165A, 0x25=6DBA, 0x28=0A40, 0x29=AA00, 0x2A=6600, 0x2C=0022, 0x2F=9890, 0x3A=9A7C, 0x3E=94C6, 0x3F=07FE, 0x40=34F0, 0x46=6050, 0x48=B386, 0x49=2A32, 0x4A=5430, 0x4D=A015, 0x4F=2A28, 0x53=2028, 0x73=6681, 0x77=88EF, 0x7B=73DC, 0x7E=303E, 0x4C=E520, 0x4E=1F10, 0x36=003F; then the sixteen-entry register 0x09 table of the DM-32UV (006F, 106B, 2067, 3062 ... F09F); then 0x21=06D8, 0x24=8C7E.

Analog FM mode: 0x47=6042, 0x7E=302E, 0x2B=C000 (and 0x32=0244 on the way back to receive). DMR mode: 0x47=0140, 0x48=B2F5, 0x7E=B03F, 0x2B=0700, 0x28=0A40. Tone signalling: 0x70=00E0, 0x72=3065, 0x58=00C1, 0x5A=85CF, 0x5B=AB45, 0x5C=5665.

On this radio the analog word 0x47=6042 leaves the FD6818's audio output off. RadioFoundry writes 0x47=0140 in FM as well, which gives receive audio on the speaker path (measured).

5.4 State sequences

• RX: 0x37=9D1F, 0x30=0200, 0x30=BFF1. TX: 0x37=9D1F, 0x52=028F, 0x30=0200, 0x30=C1FE. Always through idle (0x30=0000) between the two. The DM-32UV goes straight to the final word.

• Receiver battery save: sleep is 0x30=0000, then 0x37 = 9D17 (DMR) or 9D00 (FM), RX path off; wake is 0x37=9D1F, 0x30=BFF1 straight from idle, RX path on.

• DMR per-burst handlers. The RF TX and RF RX interrupts only clear their flag and wake a task. In a digital channel that task runs the burst start on an RF TX interrupt and the burst end on an RF RX interrupt while a burst is on; a second path runs the burst end when the transmission stops. These two are the only callers of the sequences below, and there is no PA timer: the PA ramps inside the burst start.

  Burst start (RF TX interrupt)	Burst end (RF RX interrupt)
  1. RX path off	1. wait 1.6 ms
  2. wait 1.2 / 1.0 / 0.8 ms at High / Middle / Low power	2. PA ramp down (below)
  3. 0x38 / 0x39 = TX frequency, 0x30 = 0000, 0x47 bits 11:8 cleared (0x0140 becomes 0x0040), 0x37 = 9D1F, 0x52 = 028F, 0x30 = 0200, 0x30 = C1FE, 0x50 = 3B18	3. wait 0.3 ms
  4. wait 1.0 ms	4. TX path off
  5. TX path on	5. wait 0.7 ms
  6. PA ramp up (below)	6. 0x30 = 0000, 0x38 / 0x39 = RX frequency, 0x32 = 0244, 0x37 = 9D1F, 0x30 = 0200, 0x30 = BFF1, 0x47 = 0140, 0x3F = 0000
  	7. RX path on, wait 0.05 ms

  • The waits are counts of a busy loop of about 167 cycles, so microseconds at 168 MHz (the counts are exact, the time follows from the clock). The FD6818 frames in step 3 and step 6 add a few hundred microseconds at the radio's bus speed (5.1, unverified).
  • PA ramp: DAC B = round(drive x t / 248) x 16 for each t of a fixed 40-entry table (1, 2, 2, 4, 8, 10 ... 228, 238, 248), then the drive itself. Down, the entries 21 to 2 in reverse, then 0, so the drive first steps to 70/248 of its value. No wait between steps; each costs a software floating-point calculation.
  • 0x43 isn't written per burst, and the RX path is on between bursts. The RX frequency and 0x32 are written at every burst end, also on a simplex channel. Every DMR receive set-up writes 0x3F = 0000 and 0x47 = 0140, so in DMR the radio keeps 0x3F at 0, not the power-on 07FE. RadioFoundry does the same retune on a split channel only (fd6818_dmr_burst_at; hardware-dm32.md 8.5).
  • RF_CONTROL (modem-hrc7000.md) is only ever ORed, never written whole. A simplex channel with flag bit 5 of channel byte 0x0D ORs in an RF TX lead of 0x1A (2.6 ms) and sets RF_MODE b11 (dual receive channels); any other channel, simplex or repeater, ORs in 0x15 (2.1 ms) and clears RF_MODE b11. Both OR in an RF RX lead of 0x12 (1.8 ms). The register's reset value isn't known, so neither is the lead the radio ends up with; after both kinds of channel it is 0x1F (3.1 ms), the DM-32UV's value (unverified). What the 0x0D bit selects is not known (?).
  • Timing that follows (unverified): the drive starts to ramp about 2 ms after the RF TX interrupt and is at the top near the burst start. The receiver is back about 3 ms after the RF RX interrupt: with a 1.8 ms RX lead, about 1 ms into the slot after ours.

• FM key-up (not per burst): RX path off; FD6818 0x3F = 0000, 0x59 = 0028, 0x70 = 0000, 0x58 = 0000, 0x24 = 0000; TX path on; the sub-audio set-up; register 0x40 (6.4); the TX frequency and state writes of step 3 above; then the 40-step ramp, without the waits. FM key-down isn't traced. None of these writes depends on the band. RadioFoundry doesn't write the five words before the TX path, and FM transmit works without them on UHF. Earlier versions of this page gave the DMR per-burst order as the radio's general "Enter TX / Leave TX"; RadioFoundry's FM tx() still follows that order with 1 ms waits, and FM transmit works with it.

• RSSI register 0x67, low 9 bits: dBm = value / 2 - 160 (FD6818 programming guide; 0x2C = 0x0022 sets 2 dB of external LNA gain). Status reads 0x0C, 0x68-0x6A. CTCSS register 0x51 with a calibration byte (6.4: 0x201 for CTCSS, 0x202 for DCS); the tone frequency scale (register 0x07) isn't decoded. RadioFoundry sends the tone with the modem's generator and detects it with the FD6818 (fd6818_set_rx_tone, result in 0x0C), as on the DM-32UV: the modem's detector has no input while the FD6818 plays FM to the speaker.

5.5 Paths and PA

TX path select: PTA31 + PTB7. RX path select: PTA28 + PTB8. Each is a complementary pair chosen by its band bit (5.2): above 200 MHz the PTB pin high and the PTA pin low, below the reverse; both low = off. So PTA high = VHF side, PTB high = UHF side. RadioFoundry receives on both bands (a VHF weather station, UHF DMR) and transmits on UHF with this (measured). Separate TX and RX band outputs, unlike the DM-32UV's PA selects and LNA supplies. PA drive is DAC channel B (12 bit, the calibration byte times 16), ramped in 40 steps.

VHF transmit. What differs for a TX frequency at or below 200 MHz:

The TX band bit has no other reader except the factory test mode's frequency stepping. The FD6818 sequences, the per-burst handlers (5.4), the bandwidth word and the sub-audio bytes (0x201 / 0x202) are the same on both bands. On the HR_C7000 side the code examined writes FM_BANDWIDTH once (0x5F) and FM_DEV_COEF once at start-up (0x33500), and no SUBVOICE_COEF write with a band test was found (?). So the per-band modulation byte is the only VHF deviation value: on the radio examined the VHF bytes are about three times the UHF ones, which keeps f x byte about the same on both bands, as the DM-32UV's K / f model assumes (hardware-dm32.md 11.3). RadioFoundry uses the UHF tone deviations on VHF too (modem-hrc7000.md 8.3, unverified).

Transmitter safe state (board_rf_safe, crash-log.md 8), at every fault, reset and stub entry and first in main(): the TX path selects (0x1F, 0x27) low, DAC B (the PA drive) 0 and powered down; on the fault and reset paths also the modem's FM_PTT and LAYER2_TXRX_CTRL 0. The FD6818 keeps its state until the next start.

5.6 DMR

The modem is the HR_C7000's, so the slot engine, the interrupt glue and the PCM audio are the DM-32UV's, shared (platform/hrc7000/dmr_glue.c, audio_pcm.c). The board supplies three hooks (radio_dm1801pro.c):

• Per-burst RF switch (the RF TX interrupt): RX path off, FD6818 0x52 = 028F and 0x30 = C1FE straight from RX, register 0x50 = 3B18, TX path on; after the burst (the engine's first slot tick 20 ms or more after the RF TX interrupt) the drive goes to 0, the TX path goes off, 0x30 = BFF1 straight from TX, and the RX path comes back on. The FD6818 never passes through idle (0x30 = 0000, 0200) per burst: through idle the receiver came back about 400 Hz off for the first inbound burst after each of ours, which lost most of a call in SFR mode (section 10). 0x37 and 0x43 keep their values from the RX / TX sequences and the DMR mode set. Against the radio's own handlers (5.4) this skips idle and the frequency, 0x47, 0x32 and 0x3F writes (0x3F stays 0 from the DMR mode set), has none of the waits, steps the drive instead of ramping it, and ends the burst on a slot tick instead of the RF RX interrupt. The switch to TX takes 0.46-0.48 ms and back to RX 0.17-0.21 ms with interrupts off (1 us bus, 5.1; with the earlier 5 us bus about 1.07 and 0.40 ms). The DMR mode set ends with 0x3F = 0000, the radio's DMR receive value.
• RF TX interrupt 2.0 ms ahead (hrc7000_t.rf_tx_lead = 20, RF_CONTROL b13:8), not the DM-32UV's 3.1 ms. The inbound burst's payload ends about 2.5 ms before ours starts (the guard times of both slots), so with 3.1 ms the switch cut off the end of the inbound burst before each of ours (unverified). In SFR mode a header clipped that way failed its RS check, and the radio then lost the whole first voice superframe after it, with the reception itself clean (bit errors 0, PHASE_OUT centered): 5 of 5 calls with the last header flagged lost superframe 1, 7 of 7 with it clean kept it (BENCH 2026-10-19, interrupt trace of PR 38). With 2.0 ms the inbound headers decode clean while keyed. The PA timer runs from the burst, not from this interrupt, so the drive keeps its place against the burst (next item). With the 2.0 ms lead the SFR repeat test (tests/hil/test_hotspot_sfr.py) passed 10 of 10 runs, 25-26 bursts repeated each, and test_dmr_tx_off_air passed: ramps up 0.33 ms, down 0.29 ms, slot spacing 60.00 ms, no AMBE bit corrected in 162 frames (BENCH 2026-10-19).
• PA key: the TX path switches on and off with each burst. With it on for the whole transmission, a hotspot (keyed while it listens) received nothing (2026-10-16). Per burst, test_dmr_tx_off_air passes: ramps up 1.44 ms, down 0.31 ms, slot spacing 60.00 ms. The DAC B drive is set 28 ms after each burst is armed (the DM-32UV's "DMR PA" delay), in one write. That puts it 1.0 ms before to 0.1 ms after the burst start, 1.0-2.1 ms after the RF TX interrupt (2.1-3.2 ms with the earlier 3.1 ms lead, section 12), about where the radio's own ramp starts (5.4, unverified), so the delay stays.
• Keyed but idle: a DMR tx() leaves the FD6818 and the RX path in receive until the first burst. The hotspot keeps the radio keyed while it listens, and with the FD6818 in TX from tx() it heard nothing (checked on the bench).
• Voice: the radio's own codec, carved from a program flash read into the slot at 0x030E8000 and run by the shared host platform/hrc7000/vocoder.c (codec-dm1801pro.md 4). Without the slot, DMR runs without voice. On the bench, a voice call decoded by the SDR bench's modem had 1 corrected bit in 162 AMBE frames. Encode takes about 12 ms of each 20 ms frame and decode about 3 ms, so the radio's idle load has to stay low.

Voice-access slot polarity: this board kept the driver's old default of HRC7000_RX_NEXT_SLOT_XOR = 1 and played every DMR call silent (2026-10-22, bench speech: voice.rx_peak 6 with 1, 32768 with 0), every other counter clean. The board config sets 0 now, the driver's default (gotchas.md 14.16, modem-hrc7000.md 5.3).

5.7 FD6818 register fields

From the FD6818 programming guide (DS) unless tagged. The guide's own addresses differ: it calls the state word REG_03H, and its offset calibration register is REG_04H. The radios write the state word at 0x30, so the guide's address map doesn't carry over one to one, and where REG_04H sits on these radios isn't known (?).

What follows for this radio:

• RX word BFF1 has the RX chain, the AF DAC and the RX DSP on. TX word C1FE turns the RX chain and the AF DAC off. Every return through idle (0000) restarts both and starts a VCO calibration (b15 edge). The guide's "TX with sidetone" is C3FE (b9 set).
• 0x73 = 6681: AFC on, range about 550 Hz. The guide gives no registers for PLL loop bandwidth, charge pump or VCO band.
• 0x7E = B03F (DMR): both DC filters on at 15 Hz. The guide documents the bandwidth field only for the TX filter; that it sets the RX filter too is I. The guide's own DMR set-up uses 341E (240 Hz) with b7 set, and 0x73 = 569A (AFC off).
• Offset calibration (REG_04H b9:8) takes 50 ms with the RX chain on.
• The FD6818's audio output drives the HR_C7000's AF ADC P input, and DAC C biases its N input (modem-hrc7000.md 2.1). That is why receive is sensitive to DAC C on this radio (datasheet for the inputs, unverified for the link).
• The DM-32UV writes only the state word and 0x43 per burst, and its 0x37 is 1F1F / 1F0F in DMR receive against 9D1F here. 0x37 is the only FD6818 word in the burst sequence that differs between the two; its bits aren't documented (?).

6. Flash

6.1 Data flash (16 MB, SPI0)

RadioFoundry writes only at 0x700000 and above (inside the recordings area, empty on a radio that hasn't recorded). The settings ring, journal and codeplug images sit where the DM-32UV has them (hardware-dm32.md 10.1), without a calibration copy.

6.2 Program flash (1 MB, execute in place)

Boot loader at 0x1000, application at 0x0C000 and up. The application doesn't erase or program the program flash. The loader speaks the DM-32UV's update protocol (hardware-dm32.md 13.2), which was traced against it:

What the loader does with the data:

So the loader never sees a file header: the host sends the bare application. The vendor's update file for this radio is not available. The DM-32UV's vendor files have the same header and nothing else: the ID at 0, 0xFF to 0xFC, END at 0xFD, then the application from flash 0x0300C000, whose first words match this radio's (as for the DM-32UV files).

Such a file can be made from a RadioFoundry image with tools/serial_loader.py --model dm1801pro IMAGE --wrap FILE, and tools/serial_loader.py --model dm1801pro takes it and strips the header. Whether the vendor's updater accepts such a file is not known (?). tools/serial_loader.py --model dm1801pro writes a raw image through this protocol: about ten flashes on 2026-10-15, no refused block, erase about 12.6 s (measured). The loader at 0x1000 is never written.

Flashing with RadioFoundry. The release package is one range from 0x0300C000 (application only, no codec; it refuses the slot at 0x030E8000 and any image that reaches it). rfoundry flashes it over the programming cable by one of two routes (release.md). Through the stub, only the image's sectors are written, so the codec slot stays. Through the bootloader above, the loader erases the whole application area, so the slot is rewritten from a program flash read of this radio (--stock). A first install through update mode needs that read once. A whole rfoundry run on either route has not been done on a radio.

6.3 Identity read

SPI3 (mode 1) clocks eight bytes out; the caller mixes them into a value. The DM-32UV reads the same block. Probably an identity or integrity check.

6.4 Calibration

Where. Region 0 is addressed by logical sector. The radio reads the last byte of every physical sector 1 to 0xC8 into a table and takes the first physical sector whose tag equals the logical number. Calibration is logical sector 2; this is the DM-32UV's rule (hardware-dm32.md 11.1). On the radio examined that page is physical 0x7C000. Other pages tagged 0 (0x2000, 0x3000, 0xB000, 0xF000) hold the same structure with the untuned values; they aren't the ones the radio reads.

Layout (offsets in the 4 KB page; the field offsets match the DM-32UV's, hardware-dm32.md 11.2). Every multi-byte value is little endian. "RX points" and "TX points" are the five frequencies of the 0x300 / 0x328 and 0x314 / 0x33C lists.

The radio's firmware reads nothing else from the page in the code examined: 0x10-0x15, 0x1F-0x26, 0x30-0x3E, 0x4F-0x63, 0x78-0x7D, 0xA0-0xA5, 0xAE-0xCB, 0xF4-0x107 and 0x200 have no reader (?). Some of them hold five-byte rows like the tables above, so they may be read by code not reached here, or be left from another model.

Against the untuned copies at 0x2000 and 0x3000, the radio examined differs only in the TX center, the two sets of modulation points, the UHF PA drive and one VHF high-power byte. The squelch rows, register 0x40 bytes, sub-audio bytes, thresholds and point lists are the untuned values.

How the radio uses them (its own firmware, K unless marked):

The 0x300 and 0x328 lists are therefore the receive points: the squelch uses them, and the radio's factory test mode tunes its items below 50 at the TX points and those from 50 up at the RX points. The two lists hold the same frequencies on the radio examined.

RadioFoundry reads the PA drive, the modulation and the register 0x40 bytes the radio's way: the band by the TX frequency, the clamp to the band limits, the segment at the TX points and the truncated interpolation (bf_cal_tx_byte). DAC B is the byte x 16, RF_MOD_BIAS_CTRL low half the byte x 0x0101, and FM transmit writes 0x40 = 0x3480 + byte; receive puts the power-on 0x34F0 back. Until 2026-10-16 RadioFoundry used the DM-32UV's lookups: the PA drive between even steps from 400 and 136 MHz (VHF point 2 at 155.0 MHz instead of 155.5), within 16 DAC counts of the radio on UHF and 32 on VHF, and the modulation by K / f (hardware-dm32.md 11.3), within 1 of the radio's byte on UHF and 3 on VHF (computed from the radio examined).

What still differs: RadioFoundry doesn't apply the FM factor (x1.8 Wide, x0.9 Narrow) to the modulation byte, since its FM deviations were set on the bench without it (section 10); it uses TX center + 384 (0x01F0 on the radio examined) for the high half instead of 0x27; and register 0x51 uses the DM-32UV's gain byte 0x45. None of these has shown on the bench.

The power level is one value for the three arrays: 0 = low (0x40 / 0xD0), 1 = middle (0x45 / 0xD5), 2 = high (0x4A / 0xDA, also used for 3). The radio's menu shows the setting as High / Low / Middle and stores 2 / 0 / 1, and the drive bytes rise with the level in every segment. RadioFoundry's L / M / H use the same arrays and the same lookup.

L / M / H on air. At 461.4625 MHz (between the 452.5 and 470 MHz points) the radio examined gets a middle drive 1.40 times the low drive and a high drive 1.46 times the middle, in DAC counts. The bench run used RadioFoundry's older lookup, within 9 counts of the radio's own; the lookup is now the radio's. The drive steps are about even, so the 0.4 dB between L and M against 4.4 dB between M and H on the SDR bench (section 10) doesn't come from the calibration or from RadioFoundry's lookup. It points at the PA's response to the drive voltage, or at the measurement. Diagnostics lines pa 145, pa 435 and pa tx show L / M / H as DAC counts (pa tx at the last TX frequency) and pa <kHz>k dac the drive the last transmission used, so a wattmeter reading can be set against them.

6.5 The codec in the program flash

The radio's own firmware carries the DM-32UV's 049 codec (codec-dm32.md), rebuilt with the data tables 0x48 bytes higher. It is located in the full program flash image (sha256 072ece15...9f29e42a). RadioFoundry runs it from the codec slot (codec-dm1801pro.md section 4).

codec-dm1801pro.md has the call analysis. The codec entry points are the 049 offsets from the code start (decode +0x0000, encode +0x0260, and the rest of the table in codec-dm32.md). Hosting it needs the tables at 0x18000EF0, or the 82 pointers moved back by 0x48 as on the DM-32UV. How it is called (state blocks, flags words) and the codec's frame path to the C7000 are not traced.

7. Display

128 x 64 pixels, page addressed: page command 0xB0 + n, column address 4 (so the controller has 132 columns and the visible ones start at 4), 128 data bytes per page, 8 pages. The controller part isn't identified; ST7567 and UC1701 share this command set. RadioFoundry sends the common ST7567 initialization (bias 1/9, regulator ratio 4, volume 0x20, power control all on). Upright needs the segment outputs reversed (0xA1) and the common outputs normal (0xC0), with the column offset 4 (measured). The picture is readable with these values; contrast and bias are not tuned further. Controller part unverified.

8. Other devices

8.1 Authentication chip (I2C 0x7A)

Bit-banged I2C. A start-up flag picks the pins: PTA5 / PTA6 (the value used; the IO mux puts them on GPIO) or PTA7 / PTA8 (never chosen). Frames are the 8-bit address 0x7A (write) or 0x7B (read), a register, then the data.

The check runs after the codec block's set-up and from routines around the codec, among them two task loops (their role is unverified). The code sits inside the codec's RAM block, in the range the DM-32UV notes list as code that the codec never calls (codec-dm32.md).

The part is inferred (unverified): the same pins carry the ALPU-MP copy-protection chip on the DM-32UV (hardware-dm32.md 14), and the traffic is a challenge and response. No marking was read. RadioFoundry never talks to it, and DMR voice works with the radio's own codec (5.6), so RadioFoundry's codec host doesn't need it (measured).

8.2 Real-time clock (I2C2)

The SoC's I2C2 at 0x14080000, set up as on the DM-32UV (hardware-dm32.md 3.3): CON 0x65, INTR_MASK 0x40, SCL counts for 400 kHz, FIFO thresholds 6. Address 0x70.

The board has a 32.768 kHz crystal and a 3 V backup cell for the clock, so it keeps time through power-off (owner, board inspection, 2026-10-22).

RadioFoundry doesn't use the clock yet.

8.3 SD card (SPI1)

SPI1 at 0x140B0000, chip select 1 of the controller, clock divider 16 (a routine for divider 2 has no caller). The driver speaks SD in SPI mode:

Nothing calls the start-up, the identity reads or the write path. The only reachable use is a block read from one programming-cable command (D), which without the start-up reads with byte addressing. The firmware also holds "NO SD CARD" screen strings. So the code is shared with a model that has a card, and this radio has none (unverified, no slot was looked for). RadioFoundry doesn't use SPI1.

9. Keys, battery, power

9.1 Keys

The matrix strobes PTB18-PTB22 low one at a time and the inputs PTB3-PTB6 are read (low = closed): 20 positions. The radio's panel has MENU, BACK, a four-way direction pad, VFO/MR, A/B, 0-9, * and # (20 keys), plus PTT, SK1, SK2 and a top SOS button. Read off the radio one key at a time (measured):

Direct inputs: PTB11 PTT, PTB12 SOS, PTB26 SK1 (upper side key), PTB27 SK2 (lower side key).

PTB11 (PTT) is also the programming cable's host-to-radio serial line, as on the DM-32UV (hardware-dm32.md 6.2): every 0 bit the host sends pulls it low. Before the fix, two low key scans passed the debounce and made 13 short DMR keyups during a debug link soak and one during an MMDVM network call (2026-10-16). The key scan now counts a low PTT pin as pressed only after 50 ms without a good byte from the host, held low that way for 20 ms (drivers/input/sharedptt, gotchas 16.2); diagnostics line 0 counts the ignored lows (ptt ign). On the radio (measured): 30 s of debug link polling gave ptt ign 20, and the two hotspot network cases another 14, with no PTT press.

9.2 Battery

ADC channel 2, averaged. The radio scales it with the calibration halfword at 0x0E (6.4): volts x 100 = counts x 100 / (value x 10 / 75), and shows bars at 8.99, 7.99, 7.50, 6.99, 6.49, 6.31 and 5.81 V; the halfword at 0x0C (6.30 V) sets a second low-battery flag. On one radio, switched on, the channel read 856 counts while a DMM read 8.306 V across the pack (2026-10-16), so RadioFoundry uses 103 counts per volt (the DM-32UV's divider gives 82; measured). That radio's calibration page gives 104 counts per volt (value 780), which agrees.

9.3 Interrupts and timers

One timer gives the 10 ms main-loop tick; the GPIO banks, UART0 and the modem (PCM read and write, system, TX and RX slots, RF TX and RX) have vectors as on the DM-32UV. The I2C, SPI, ADC and DAC blocks are polled.

9.4 Power, backlight, LEDs

PTA17 is the power latch, PTB9 the power key (polarity unverified; RadioFoundry takes the level at start-up as "on"). The backlight is on PTA15. PTA15 is also the SoC's PWM0 output (as on the DM-32UV), so RadioFoundry dims it with PWM0 for the brightness setting (unverified until seen on the radio). LEDs: PTB0 green, PTB1 red (measured). The panel's top LED is red while transmitting, green while receiving and orange flashing while scanning.

10. Open items

• VHF transmit on air. The code follows the radio's (5.5, "VHF transmit"), but no VHF transmission has been checked. To check: the carrier on frequency at L / M / H (the pa 145 line gives the drive), CTCSS, DCS and the 1750 Hz tone deviation against the UHF values (the tone deviations are the UHF ones, unverified), and a DMR burst decoded on VHF.

• The power levels on air: on the SDR bench L and M are only 0.4 dB apart and H is 4.4 dB above M (2026-10-16, 461.4625 MHz, the drive from the 0x40 / 0x45 / 0x4A arrays). The drive itself steps evenly (6.4, "L / M / H on air"), so the cause is the PA or the measurement. The SDR's levels are relative and the radio is in its near field, so this wants a wattmeter, read against the pa tx diagnostics line.

• The display controller part and its contrast.

• FM transmit deviation at 12.5 kHz. The TX limiter is 5 there, scaled from the 25 kHz results (section 12); not measured. Speech deviation at both bandwidths with the new limiter needs a cable-out session. The radio itself writes FM_DEV_COEF only once, 0x33500 at start-up (limiter 3, TX coefficient 0), and FM_BANDWIDTH = 0x5F for both bandwidths; how it reaches its deviation with those values is unknown (?). Its FM factor on the modulation byte (6.4: x1.8 on a Wide channel, x0.9 on a Narrow one, kept to 255) may be the answer; RadioFoundry leaves it out.

• In the calibration page (6.4): what register 0x40 controls, what the squelch thresholds are compared with, the fields read at start-up without a found reader (0x203-0x209), and the unread rows.

• The authentication chip's marking (8.1), and what PTB16 drives (3.1).

• Whether the vendor's updater accepts a BF1801-V1 file made as in 6.2.

• The FM mic gain levels. The FM values are still the DM-32UV's 11 dB (section 12); measure them with tests/hil/test_mic_gain.py at 12.5 and 25 kHz (the bring-up checklist 5.1) and set MIC_GAIN_FM_12K5_DB and MIC_GAIN_FM_25K_DB.

• Whether the mic PCM carries the microphone in FM receive (PTB14 high), which VOX needs (section 12).

• MMDVM SFR: the inbound losses are fixed by switching the FD6818 straight between its RX and TX words and by the 2.0 ms RF TX lead (5.6). The SDR bench still can't confirm the repeats during a call, since its station keeps its carrier up through our slot. Before the lead change, the straight switch passed the SFR repeat test in 6 of 8 runs; the failures were the clipped-header case (5.6). How the trip through idle detunes the receiver isn't known (?). The experiment build (PR 38) recorded each modem interrupt, RF switch and deframe (RX_TYPE_INFO, RECV_INFO_COUNT, PHASE_OUT) and switched these variants at run time (BENCH 2026-10-16, 461.4625 MHz, a 29-burst bench call):

  Variant	Bursts heard	Sent up	Bad header CRC
  Through idle, RadioFoundry before the fix	20-21	8-9	3
  No RF switching, no PA ("dry")	30	26	0
  RX / TX paths switch per burst, FD6818 held in receive	28	26	0
  Straight between BFF1 and C1FE, no idle (the fix)	28	24	2-4
  Straight, plus 0x7E = B07F, TX word C3FE or FDFE, or a b15 edge at each switch	28	24	2-4
  Straight, b15 clear in both words (3FF1 / 41FE)	2	2	0
  FD6818 switches per burst, paths held	20	8	3
  PA drive 0; FD6818 PA bias and driver off (TX 81F6)	21	8	3
  Through idle with TX word C3FE, FDFE or FFFF; 0x7E = B07F or B01F; AFC off; DAC_CONTROL 0x80000009	20-21	8	3
  Through idle with: DMR filter 0x43 = 4048; 0x50 / 0x52 restored at RX; dynamic sync off; RF TX interrupt 2.0 ms ahead; the DM-32UV's two-write switch; no 0x30 = 0200	20-21	8	3
  The radio's tables without 0x37; no 0x50 write; a full RX retune at each return; the radio's own burst sequence (5.4)	11-13	3-7	1
  0x37 = 1F1F at RX (the DM-32UV's word); HR_C7000 AF gain 0x1C	0-2	0-1	0-1

  Through idle, the first inbound burst in each listen window after one of ours demodulated with an offset: PHASE_OUT's center read +185 to +315 (minimum -600 to -850 against -1213 normally), about 400 Hz, and failed sync or EMB. Later bursts settled to about 0 within 60-90 ms. With the straight switch the centers read 1 to 35 from the first burst on. Keeping the RX chain, the AF DAC or the RX DSP on through TX (FD6818 programming guide bits, 5.7) doesn't help while the switch passes through idle, so what settles is in the PLL / VCO section that idle powers down (unverified). DMR transmit with the straight switch passes test_dmr_tx_off_air (ramps up 0.88 ms, down 0.38 ms, AMBE 1 bit corrected in 162 frames).

  Ruled out earlier: an FD6818 bit clock of 1 us instead of 5 us, and the RX path left on during TX bursts. Ruled out for the clipped-header losses (2026-10-19): the empty slot's sync pattern (0 instead of the listen word) and a header sent in the gap before voice.

11. What RadioFoundry reuses

12. Bring-up state

First run on a radio on 2026-10-15 (the bring-up checklist has the steps). Checked there:

• start-up, the power knob, the vibration motor, the update-mode flash route
• the display (upright, readable), every key, the data flash (Puya, JEDEC 852018) and the factory calibration
• the speaker path (amplifier and source pins), the debug link on the programming cable
• FM receive audio on a weather station, the squelch and the monitor key
• the squelch closes without a signal (fd6818_noise), CTCSS / DCS muting, and receiver battery save (rx_sleep: FD6818 idle and the RX path off)
• beeps through the prompt FIFO, clean and without pops
• the accelerometer answers and reads 1 g lying flat

Checked with the SDR bench's modem: DMR voice receive and transmit with the radio's own codec, late entry (2026-10-15: 18 of 36 bursts played, as the HIL test expects), the GPS, privacy and emergency call transmit tests, and DMR data: confirmed data with its response, SMS and ETSI SMS received and acknowledged. FM transmit with CTCSS 100.0 and DCS 023 (normal and inverted) was decoded by a DM-32UV, and the SDR bench's FM transmit tests (CTCSS, DCS, tone burst, roger beep) pass. The bandwidth test passes too: the CTCSS 100.0 tone deviates 298 Hz at 12.5 kHz (word 0x3048) and 597 Hz at 25 kHz (0x3028), a ratio of 2.00 (2026-10-16). The MMDVM hotspot on the programming cable works both ways on air (2026-10-16: the four test_hotspot_on_air cases). Not checked on the radio yet: the air band and the broadcast tuner (airband-and-broadcast.md). Not in: USB (the radio has none).

Further measurements and notes:

• The programming cable sits on the microphone and speaker jack and now and then delivers a burst of noise bytes (0xFC, 0xFE) between CPS requests. The CPS shim drops them (counter cps.junk).
• Crash log (2026-10-17): the modem SRAM kept the record through the soft reset and the vendor bootloader. A trap test (exception 7, breakpoint) in task host was recorded, and the fault trace appears on UART0, the programming cable.
• APRS: the shared AFSK through the codec mixer decodes off air with a valid FCS (2026-10-16), and test_aprs.py passes at amplitude 46 (3.25 kHz peak). Its receive is the DM-32UV's code and is unchecked here (aprs.md).
• Modem notes: the prompt FIFO path does not decode on this radio, so DMR voice takes the codec mixer route (hrc7000_codec_dac_to_tx). PHASE_OUT while receiving DMR reads about +1216 and -1149. The DTMF deviation is 5.8 Hz per step on UHF (measured). The CDCSS TX code is taken when FM_PTT goes on.

VOX (not checked on the radio): the radio has no analog microphone level tap, so RadioFoundry measures the level on the codec ADC's mic PCM, the same 10 ms halves DMR voice uses (radio-features.md 3.4). The first mic_level() call sets AUDIO_CONTROL b4 and unmasks the PCM interrupt without starting the PCM stream; 1 s without a call turns them off again unless the stream is running. The PCM interrupt runs in FM: FM beeps are paced by it. In FM receive with the squelch closed PTB14 is high (the microphone to the HR_C7000's FM input, as for an FM transmission), so the codec ADC should hear the microphone the way it does on transmit. Whether its samples carry the microphone in receive is the first thing to check. On the radio: vox.mic=1, then vox.level (features section) and the diagnostics line mic lvl L pk P n N on|off (level, the last half's peak from its mean, halves measured, running): N should grow by about 100 a second while vox.level is read, and L and P should rise when someone talks at the radio (test_radio_features::test_mic_level, radio only; test_vox_quiet with --allow-rf).

Mic gain: GCR_ADCL (bits 5:0 = 0 to 42 dB, hardware-dm32.md 9.1) gets three board levels, as the radio uses separate FM and DMR values (modem-hrc7000.md 4 step 32, 5.1 step 2): MIC_GAIN_DMR_DB at power-on, at every DMR entry and at every DMR transmit start, and MIC_GAIN_FM_12K5_DB or MIC_GAIN_FM_25K_DB at every FM transmit start, before FM_PTT. All three are the DM-32UV's 11 dB (0x8B) for now. The Mic gain setting adds (step - 5) x 2 dB to each through hal_radio_t.mic_gain (radio-features.md 3.6), so the bench can step it without a reflash (debug link SETTING 29). Speech on FM gave 1.4 kHz peak deviation (above), which is low; the channel bandwidth of that measurement isn't recorded, so the target isn't settled. If the path is linear up to the deviation limiter, each dB of gain adds 1 dB of deviation. See section 10.

APRS: positions over DMR (LRRP and UDT) decode on the SDR bench. FM APRS uses the shared HR_C7000 AFSK (platform/hrc7000/hrc_afsk.c), which plays the tones through the prompt FIFO. On the DM-32UV the FIFO's playback reaches the modulator by itself (ring play). On this radio it doesn't: the frame went out as a bare carrier (7 Hz rms in the 300-3000 Hz band on the SDR bench, 2026-10-16), and every direct codec register, AUDIO_CONTROL, WORK_MODE, FM_PTT and RF_MODE matched the DM-32UV's during the tones. An experiment build tried each candidate route on air (BENCH 2026-10-16):

RadioFoundry takes the mixer route (hrc7000_codec_dac_to_tx, modem-hrc7000.md 8.4): it keeps the FIFO feed both radios share. The codec's mic mute sits after the mix, so it would mute the tones too; MIX_3 keeps the microphone out instead. With it, positions decode off air with a valid FCS at every level tried.

At first the deviation saturated near 1.65 kHz peak at 25 kHz, whatever the level. The cause was the TX limiter, FM_DEV_COEF b23:16 (modem-hrc7000.md 8.4): the KP value 4 caps all audio through the codec ADC, the microphone included. This radio sets 0x0F at 25 kHz (the chip's reset value; 4.7 kHz most) and 5 at 12.5 kHz. With 0x0F the tones are linear in the level, and the 2200 Hz tone sits 5.1 dB above the 1200 Hz one, the slope of the TX pre-emphasis (FM_BANDWIDTH b4) between them. With amp_per_level 68 at 25 kHz (BENCH 2026-10-16):

amp_per_level is 46: at level 50 the position decoded with 3.25 kHz peak (mark 1.61, space 2.91 kHz) and test_aprs passes. APRS receive is unchecked.

MMDVM SFR: the radio hears the call's header, uplinks it and repeats it in the other slot with the right link control, on the right slot and a clean 60 ms grid. While it sends, it loses inbound bursts (2026-10-16, test_hotspot_sfr.py::test_sfr_repeats_bench_call). The bench's call is clean on the SDR (8 voice LC headers 60 ms apart, 18 voice bursts, 3 terminators, no errors), but only about 20 of its 29 bursts reach the SFR runner. Headers at 60, 180 and 360 ms are missing and those at 118 and 299 ms fail their CRC; voice bursts at about 539, 722, 778, 838 and 1210 ms come with a wrong EMB (color code 1, 0 or 9 for 2, a wrong voice index). The pattern is the same in every run, also right after a fresh start. The DM-32UV on the same test: 25 received, 22 repeated, 3 bad CRCs (the terminators). Our bursts: RF on to off 32-33 ms, the RF switch 2.06 ms with interrupts off, the PA keyed 2.1-3.2 ms after RF on. Fixed by switching the FD6818 straight between RX and TX per burst (5.6): 28 heard, 24 sent up (section 10).

View the source of this page