DM-1801 Pro: the AMBE+2 codec and how it is called

Status: research, 2026-10-15. Taken from the radio's complete program flash image (1,048,576 bytes, sha256 072ece15...9f29e42a). Nothing here has run on a radio.

The rule of codec-dm32.md holds: the radio runs the codec it already carries, the user's machine carves it from the radio's own flash image or an original update file, and no codec bytes go in this repository or in a release.

Result. The DM-1801 Pro's codec, its init routine and the wrappers that call it are the DM-32UV 049 build, with the data tables and the state blocks at different RAM addresses. RadioFoundry's DM-32UV hosting (codec-dm32.md, platform/hrc7000/vocoder.c) therefore interfaces with it the same way. The changes for this board are addresses. One thing in that interface was wrong: the encode flags word (section 3 and section 5).

Tags: K = known from the image, I = inferred, ? = not determined.

1. Where it is

Against the DM-32UV 049 codec

The whole RAM code block shares 82.7% of its 16-byte chunks with the DM-32UV 049 image. The shared part includes every function the codec calls and all the wrappers in section 3. The differences are hardware-specific code (UART, the modem and display glue) and addresses.

2. Entry points

All eight sit at the 049 offsets from the code start and begin with the same prologues.

3. How the codec is called

Init

Byte for byte the DM-32UV 049 routine, with D and E at the addresses in section 1. The parameter values and the order are those of codec-dm32.md C: E[0x172C] = 0x1840, E[0x173A] = 0x2000, E[0x173C] = 128, E[0x173E] = -20, E[0x1740] = -22, E[0x1742] = 20, E[0x1744] = -10, E[0x1746] = -40, E[0x1748] = 0x4000, E[0x174A] = E[0x174C] = 3276, E[0x174E] = 1310, E[0x1750] = 10, E[0x1752] = 20, D[0x1152] = 0, D[0x116A] = 128, D[0x116C] = -20. Then:

1. encoder init (E, 1, 1)
2. FEC init (E + 0x16E0, 1)
3. encoder set (E, E[0x173C], E[0x173E])
4. decoder init (D, 1)
5. FEC init (D + 0xFD0, 1)
6. decode (D + 0x12AE, 80, D + 0x1354, 0; stack 8, 0, D)
7. decoder set (D, D[0x116A], D[0x116C])
8. clear the state flags (halfwords and bytes around E + 0x1732..0x1736 and D + 0x1162..0x1168, and the bytes at E + 0x1728..0x19D6 and D + 0x1150..0x1498)

platform/hrc7000/vocoder.c reset() makes the same calls with the same values.

Encode

This is the DM-32UV call (codec-dm32.md, calling convention) and what encode() in platform/hrc7000/vocoder.c passes.

The flags word (sp+0). The wrapper has six encode calls in two patterns. Each pattern passes one value on every call; none passes 0x1840 first and 0x800 afterwards. Every call is followed by the XOR step and ECC.

E[0x172C] is 0x1840 after init, and the one routine that writes it again has no caller, so pattern B always passes 0x1840. The wrapper picks the pattern from the bytes E[0x1728] and E[0x172A] and the halfword E[0x1732], which code outside the codec sets; which pattern DMR voice takes is not traced.

The two values give different parameter bits (section 5): over 234 frames of speech, 0x800 and 0x1840 differ in 174 frames (74%). On speech bit 0x1000 has no effect (0x840 equals 0x1840): it is tone detection, which acts on a steady tone or tone pair (codec-md380.md, "Encode flags"). Bits 0x40, 0x80, 0x100, 0x200 and 0x800 are tested in the parameter stage; 0x800 only counts while E[0x138A] is not 0. Both patterns produce frames the decoder accepts.

What RadioFoundry's hosts do. platform/hrc7000/vocoder.c (this radio and the DM-32UV) and platform/stm32f4/hrc/vocoder.c (the DM-1701 and MD-380) pass one word on every call, from drivers/vocoder/ambe2_flags.h: 0x800, plus 0x40 for noise reduction, 0x1000 for tone frames and 0x2000 for AGC. The default is 0x1840, pattern B's value (dmr-voice.md 6).

Afterwards the wrapper XORs the bit buffer with a second buffer 0x90 bytes above it, then calls ECC (0x1893C) with r0 = r1 = the bit buffer, r2 = E[0x1738], r3 = the buffer minus 440 bytes. The XOR and the ECC step belong to the wrapper's own frame building (72 bits); RadioFoundry takes the 49 parameter bits from the encode call and builds the frame in core/dmr/ambe.

Decode

The normal frame path:

One other call passes sp+4 = 0. The flags word is the status the wrapper gets back from a 72-bit error-correcting decode of the received frame (RAM 0x182BC, run on each of the three sub-frames, I). The wrapper stores each result in D at 0x1156 + 6 * k (+ 2 for the second and third sub-frame), and the decode call reads one back (the halfword at D + 0x1154 + 2 * (3 * k + D[0x1164]) + 2) and ORs in D[0x1154], a copy of D[0x1152] (0 after init). So the wrapper tells the codec how damaged the frame was, and the codec can conceal damage itself.

Measured effect of the flags word (values 0..0xF, each single bit and random words, clean and noisy input, same on the DM-1801 Pro codec and an independent ARM build): bits 0 and 1 change nothing, so 0..3 decode like a good frame; any value with bit 2 or 3 set (4..0xF) makes the decoder repeat the previous frame, which is silence when there is none; 0x4000 replaces the output with a steady noise at a fixed level (RMS about 1190); every other bit does nothing. platform/hrc7000/vocoder.c passes 0 and does its own error correction and concealment in core/dmr/ambe. That is right for a good frame, and 0 is also the status an error-free decode returns (see codec-md380.md). It gives the codec no damage information, so the repeat-previous-frame concealment (4 or 8) never runs and RadioFoundry conceals before the codec instead. Whether the two sound the same at the edge of coverage is a hardware question, not an interface error.

Level setter

set(level, which). With which = 0: E[0x1736] = D[0x1166] = min(level, 4). With which != 0: E[0x1738] = D[0x1168] = min(level, 6). The wrapper calls it from four places and only with which = 1: level 0 twice and level 4 twice. So E[0x1736] and D[0x1166] stay 0 (the host's use of the state's own value is right), and E[0x1738] / D[0x1168], the ECC parameter, is 0 or 4 by mode. RadioFoundry never calls ECC, so it doesn't matter unless a later version moves frame building into the codec.

Not part of the interface

The wrapper's start-up also creates three RTOS semaphores (names in the data image at RAM 0x18000EA0, 0xEAC, 0xEB8) and stops with an error code 1, 2 or 3 if one fails; that is task start-up, not the codec.

4. How RadioFoundry hosts it

Before the move, RAM was split in two around the codec's vendor addresses.

Measured on the radio: encode about 12.3 ms per 20 ms frame at the top priority, decode about 2.4 ms, stack use about 3.9 KB. RX and TX voice work on the bench (hardware-dm1801pro.md 5).

5. Cross-check against an independent build

The DM-1801 Pro codec was run on a host and compared with the MD-380-generation build of the same codec, run in an emulator from a running radio's RAM image. The host used the reset sequence of platform/hrc7000/vocoder.c on state blocks at the addresses in section 1. Neither is part of this repository.

What this settles:

• The DM-1801 Pro codec is functionally the same codec as the MD-380 one, for decode and encode with any flags. The differences with bit 0x2000 set came from different values in the AGC parameter block (E+0x16A2..0x16B6), not from different code (codec-md380.md, "Encode flags").
• The reset sequence in section 3 and the argument values platform/hrc7000/vocoder.c passes (r1 = E[0x1736], sp+8 = E[0x173A], decode r3 = D[0x1166], two 80-sample calls per frame) are right. They produced identical output to a radio that had been running.
• The encoder delays its output by one frame: a tone that starts in input frame 10 first changes output frame 11.
• The hosts pass the encode flags word as the wrapper does: one value on every call (section 3).

6. Open

• Which encode flags pattern DMR voice uses (0x800 or 0x1840): what sets E[0x1728], E[0x172A] and E[0x1732] before the encode calls. A bench transmission with each value, decoded by a second radio, would also settle it.
• The return value of the error-correcting decode (0x182BC) on this build. The flags measurement above shows 0..3 are harmless and 4..0xF repeat the frame; the MD-380 build returns 0 good and 4 for an uncorrectable C0.
• What the XOR step before ECC does with the second buffer.
• Whether this radio has the 046 HRVocoder variant of the codec in some firmware versions. The image is one version of the radio's firmware.
• Audio quality and timing on hardware.

View the source of this page