Analog and DMR voice over USB: feasibility and design

A computer should be able to hear the radio's receiver, transmit through it, and control PTT, channel and frequency over USB: as a USB sound card (optionally with a serial port beside it, like the commercial "data radio" interfaces), over the serial port, or over the USB network personality (usb-network.md). This page is the feasibility study and the design. Built so far: USRP voice over UDP on the network personality (CONFIG_NET_USRP, 9.1) with the stream sharing it needs (core/usbaudio/audio_mux.c, part of 5.1) and an HR_C6000 board's FM transmit path (PWM into the microphone input), and a bench probe (CONFIG_AUDIO_PROBE) that measures a board's audio paths. The sound card, the serial transports and CAT are not built. Section 9 lists what is in the repository.

Summary

1. Use cases and transports

• Digital modes on FM: fldigi, WSJT-X, JS8Call, VARA FM, Direwolf (APRS / packet) see a sound card and key PTT through a serial port's RTS or DTR, a CAT command set, or a CM108-style HID GPIO.
• Linking: AllStarLink, HamVoIP, DVSwitch and similar link a radio to a network as an RF node. They want 8 kHz audio, PTT from the network side, and a carrier-operated squelch (COS) signal from the radio.
• DMR as a USB voice endpoint: the radio's AMBE codec turns host PCM into a DMR call and DMR calls into PCM, so a computer can join a DMR channel on RF with no codec of its own (DVSwitch-like set-ups, dispatch consoles).
• Remote operation over IP: the USB network personality already gives the host an IP link to the radio.

Transports, as the task names them: (a) the USB network personality (UDP over CDC-NCM), (b) the USB serial port (CDC-ACM, or a UART on radios without USB), (c) a USB Audio Class sound card, alone or composite with the serial port.

2. Audio paths per radio

What each radio offers the design. Radios not listed have not been studied.

A discriminator signal is flat (before de-emphasis and the voice filters). Voice needs de-emphasis and a 300 Hz high pass in software; 9600 baud packet and AFSK use the flat signal directly. A timer-triggered ADC samples it at 8-48 kHz on a second ADC, so the existing ADC scan stays as it is.

The probe (CONFIG_AUDIO_PROBE, debuglink.md 3.14) measures a board's paths on the bench.

2.1 Budgets

On the STM32F4 radios only the buffers that DMA or USB touches need main RAM; the rest can go in CCM.

3. USB: what fits

The USB core of the STM32F405 radios (OTG_FS) has endpoint 0 plus 3 IN and 3 OUT endpoints and 1.25 KB of FIFO RAM (USB_OTG_FS_MAX_IN_ENDPOINTS = 4 including EP0 and USB_OTG_FS_TOTAL_FIFO_SIZE = 1280 in ST's device header; TinyUSB's dwc2_stm32.h: 4 endpoints, 320 words).

FIFO budget for CDC-ACM + UAC1 at 48 kHz: RX FIFO about 64 words (control, bulk 64 B and isochronous 96 B packets with the per-packet status words), TX FIFOs EP0 16, notification 16, bulk IN 32 (double), isochronous IN 2 x 25 words: about 180 of 320 words. Comfortable at 48 kHz, ample at 8 or 16 kHz.

TinyUSB (third_party/tinyusb, release 0.21.0) has an audio device class that handles both UAC1 and UAC2 descriptors (src/class/audio/audio_device.c; TUD_AUDIO10_* descriptor macros in usbd.h), composite devices, and a cdc_uac2 example of exactly the serial + sound card composite.

Driverless: UAC1 binds the in-box class driver on Windows (usbaudio.sys, since long before Windows 10), macOS and Linux (snd-usb-audio). UAC2 binds in-box on macOS, Linux and Windows 10 version 1703 and later (usbaudio2.sys). CDC-ACM binds in-box everywhere current (usbser.sys on Windows 10+). HID needs no driver. Choose UAC1: the widest reach, everything a mono 8-48 kHz interface needs, and no clock-source entities to get wrong.

Rates: offer 48 kHz (the default alternate setting: what WSJT-X, fldigi and the OS mixers prefer and what CM108 interfaces offer), plus 16 kHz and 8 kHz (no resampling at 8 kHz; Direwolf and AllStar's 8 kHz paths). The firmware resamples 8 kHz to the chosen rate and back.

Clocks: the radio's audio clock is the modem's 8 kHz word clock (on its own crystal), not the USB frame clock. The IN stream (radio to host) is asynchronous: the device sends 47 / 48 / 49 samples per frame (or 7 / 8 / 9 at 8 kHz) as its clock dictates, which every host handles. The OUT stream is adaptive: the host sends at its rate, and the firmware's jitter buffer (core/usbaudio/pcm_slip.c) absorbs the difference by dropping or repeating one sample when the fill drifts a block away from its target. At 100 ppm that's one sample every 1.25 s, inaudible on voice and harmless to AFSK and the FSK modes (host test: 200 ppm either way for 10 minutes with 15 ms of jitter, no underrun, no overflow). The same buffer serves USRP and serial audio, whose senders run on the host's clock too.

IDs: the radios use NXP's VID with the PIDs that qdmr and the open-firmware CPS look for today (board_usb_ids; platform/stm32f4/platform.h says a release should move to an ID of its own). A composite personality changes the interface set, so it needs its own PID (Windows caches the driver binding per VID/PID). pid.codes (VID 0x1209) gives open-source projects PIDs for free; the AIOC adapter, an MIT-licensed STM32 sound card + serial + CM108-style HID cable, does that (1209:7388).

4. Protocols

The rule: implement what existing software already speaks; add our own only where nothing fits.

4.1 Control (PTT, frequency, channel, squelch state)

Recommendation:

• On the serial port: RTS/DTR PTT (configurable which line and polarity; default PTT = RTS asserted, as most software defaults to RTS; AIOC uses DTR=1 and RTS=0 after finding that CHIRP-style programmers toggle DTR) and a Kenwood TS-480-style CAT subset recognized beside the other protocols.
• Over IP: rigctld on the radio. Built: port 4532 on the USB network link with a minimal TCP (CONFIG_NET_RIGCTL, tcp-services.md 6), so the host bridge first planned here (tools/rfoundry_rig.py) isn't needed.
• In the sound-card-only personality: CM108-compatible HID report layout (PTT on GPIO 3 as an output report, COS as an input report bit), under our own VID/PID.

4.2 Audio over IP

Recommendation: USRP over UDP, voice type 0 (16-bit PCM) by default and type 6 (mu-law, half the bytes) as an option. The radio sends a frame every 20 ms while its receiver is active (keyup = COS, 5.4) and stops (after a keyup-0 frame) when it closes; the host's frames with keyup 1 key the transmitter. Ports are configurable; AllStar and Analog_Bridge set-ups commonly pair 32001 / 34001 (one side's TX port is the other's RX port). The format as implemented in core/usbaudio/usrp.c comes from the public descriptions (header words big endian, samples little endian, as every known peer runs on little-endian hosts); it must be confirmed against a live Analog_Bridge or AllStar node with a packet capture before release (owner question 4). The GPL implementations were not used as a source.

Coexistence with the IP gateway: the gateway answers the radio's own address on ICMP, DHCP and UDP 3334, and forwards everything else addressed to radio IDs and talkgroups over the air (usb-network.md 3). The USRP port becomes a third local UDP port of the radio's address; the gateway's air side and the voice side share the modem only in the sense that a DMR voice transmission and a data transmission can't overlap (the data service already waits for a free channel). In FM mode the gateway has no air side at all, and USRP is the only user.

4.3 Audio over the serial port

8 kHz 16-bit PCM is 128 kbit/s each way, 256 kbit/s full duplex: about 2 % of full-speed USB, and CDC-ACM bulk moves several Mbit/s on all three host OSes, so it fits with a wide margin (8-bit mu-law halves it). The issue is framing on a byte stream that the host link already shares among MMDVM (first byte 0xE0), the debug link (0xA5 0x5A) and the CPS (ASCII letters) (cps-protocol.md 1). Options:

• the debug link's framing: requests are capped at 64 bytes, too small for a 320-byte frame without a new frame kind;
• KISS (FEND 0xC0): the TNC framing Direwolf and APRS software speak, but its data frames mean AX.25 packets, and a KISS client would misread audio;
• SLIP (RFC 1055) framing of whole USRP datagrams, first byte 0xC0 (END), which no other protocol on the port starts with. The radio runs the same USRP code for serial and IP; a host bridge (socat-like, a few lines of Python) turns the serial port into a UDP USRP endpoint, so Analog_Bridge or AllStar can use the radio over the serial port too. Recommended.

Serial audio matters most on radios whose host port is a UART (section 2), and on hosts where installing the network adapter is unwanted. 8 kHz mu-law is 64 kbit/s plus framing, about 70 % of a 115200 baud UART in one direction: half duplex works, full duplex doesn't. Most USB-serial cable chips run 460800 baud or more; a faster host port is a setting both ends must agree on. With the composite sound card the serial port carries only CAT and RTS/DTR.

4.4 Choices

5. Design

5.1 The audio router (core/audio, new)

Today the DMR voice code (ambeVoice.c) owns hal_audio_t.start() while in DMR, and beeps start the stream on their own in FM (core/radio/beep.c). With USB audio and APRS (the core/aprs work package) there are four consumers of the one 8 kHz stream, so one module should own it and hand each block to its users:

The router keeps the stream running whenever any consumer wants it, calls board.audio_tap->fm_tx_inject() (hal/hal_audio_tap.h) as the active consumers need, and resolves conflicts by priority: local PTT and emergency over host PTT, DMR voice over APRS, APRS transmit only on an idle channel. hal_audio_tap.h is the interface the USB audio and APRS packages share; the APRS agent should use it rather than adding its own audio hooks.

5.2 USB personalities

The serial / network switch (usb-network.md 1) grows into a choice of personalities, each with its own PID, chosen by a setting and switched by re-enumeration:

UAC1 topology: input terminal "radio receiver" (type 0x0710, radio receiver) to an output terminal USB streaming (the host's microphone); USB streaming input terminal to an output terminal "radio transmitter" (0x0711) (the host's speaker); a feature unit with mute and volume on the transmit side lets the host set the TX audio level. Product string names the radio (the board's product name followed by "audio"), so it is recognizable in sound settings. If a host mishandles the radio terminal types, fall back to the generic microphone (0x0201) and speaker (0x0301) types.

5.3 Rates and the radio side

The stream stays 8 kHz. Toward UAC at 48 or 16 kHz a polyphase FIR interpolates and decimates (3.4 kHz passband, fixed point, about 1 KB of code). The exception is flat FM audio from an MCU ADC (5.5): it goes to the host at the ADC's rate, without the voice band filter. The jitter buffer sits on the host-to-radio side (pcm_slip, target 60 ms); the radio-to-host side needs none (the asynchronous IN endpoint carries the radio's own clock). USRP frames are exactly one 160-sample block each way.

5.4 Squelch and COS

The radio core knows when the receiver is "active": FM squelch open with the right tone, or a DMR call playing (radio_status, the state key of the debug link view). That one bit is the COS:

• USRP: keyup in the radio's frames; frames flow only while it is set, plus a keyup-0 frame at the end.
• CDC: SERIAL_STATE notification with DCD (needs CFG_TUD_CDC_NOTIFY; Windows exposes it as RLSD, Linux as TIOCM_CD), and the Kenwood BY answer.
• HID: an input report bit, as CM108-based interfaces report a COS input.
• rigctld: \get_dcd.

RX audio sent to the host is gated by the same bit (silence otherwise), so software that has no squelch of its own (VOX-keyed linking) doesn't hear noise. A setting "ungated" passes the receiver's audio all the time for decoders that prefer to see noise (some packet modems); that needs the FM feed-through on in the chip regardless of the squelch, which the probe will show is or isn't independent of the speaker.

5.5 FM audio: voice or flat

A setting picks what FM audio the host gets and gives, so the same radio serves voice linking and data modems that bring their own waveform (9600 baud G3RUH, VARA FM, M17 or other 4FSK, anything a soft modem generates):

What flat means depends on the receive source (section 2):

• Discriminator on an MCU ADC: flat RX is the native path, and at 48 kHz it carries 9600 baud. Flat TX goes through the modem with its pre-emphasis, compressor and band-pass bits off (modem-hrc6000.md 8, 8.1). Whether the modem's transmit path reaches down to a few tens of Hz, as 9600 baud needs, is a bench measurement.
• FM receive audio from the modem at 8 kHz: flat is limited to about 300 Hz-3.5 kHz, enough for 1200 baud AFSK and 2400-4800 baud schemes, not 9600. Voice and flat are two settings of the modem's receive filters. If the tap is ungated, the squelch gating of 5.4 is done in software from the radio's COS.

The setting lives with the other USB audio settings, and the host can change it on the control channel (a CAT extension and a debug link / rigctld command), so a modem program can switch to flat for a session. hal_audio_tap_t carries it: fm_tx_inject() takes the mode, and caps says which modes and rates a board has (AUDIO_TAP_FM_RX_RAW, AUDIO_TAP_FM_TX_FLAT). An HR_C6000 board offers voice only so far (9.1).

5.6 DMR as a USB voice endpoint

Receive: every DMR call that the radio would play (talkgroup and contact filters as for the speaker) goes to the host as PCM, with COS for the call's duration; the call's metadata (source, destination, talker alias) goes to the host on the control channel (CAT has no place for it: the debug link view, or USRP TEXT frames, type 2, which Analog_Bridge uses for metadata). Transmit: host PTT starts a call to the channel's talk target (or one the host sets) and the host PCM is encoded instead of the microphone. The timing is that of a normal call: the encoder already runs from 20 ms blocks queued ahead of the timeslot interrupt (modem-hrc6000.md 6.3). No new codec work, no new CPU.

6. Behavior and safety

6.1 Levels

• RX: the FM tap is at the codec's level before the volume knob; the host sets its own capture level. DMR decoded audio is the codec's output level.
• TX: where the host's audio enters the modem's FM transmit chain (section 2), pre-emphasis, the modem's limiter and the channel filter keep the deviation inside the channel whatever the host sends. Where it bypasses the chain, the firmware does pre-emphasis and limiting. The feature unit volume and a firmware gain scale it; hal_audio_tap_t.fm_tx_nominal_peak (the sample level that gives 60 % of peak deviation) is measured once on the bench per band and bandwidth with the probe's tone and the SDR bench, like the FM deviation calibration.
• Sub-audio (CTCSS / DCS) on transmit stays the radio's: the host doesn't have to generate it.

6.2 PTT sources and priority

Local PTT (the side key, the accessory jack), VOX, the radio's own features, and host PTT (RTS/DTR, CAT TX, HID GPIO, USRP keyup, rigctld T 1). Local PTT wins: pressing it while the host transmits switches the source to the microphone for as long as it is held. Emergency always wins. Host PTT is refused (and reported: CAT ?;, USRP frames ignored) when the radio refuses any transmission: TX inhibit, receive-only channel, busy channel lockout, battery critical, out of band.

6.3 Watchdogs (no transmission without a live host)

• USRP: the host must keep sending keyup frames; 300 ms without one unkeys (USRP_KEYUP_TIMEOUT_MS), and a hard per-transmission limit (default 180 s) locks out until the host sends keyup 0 or stops (core/usbaudio/usrp.c, host tested).
• RTS/DTR: honored only while the host has the audio interface streaming (the OUT alternate setting active) or the port open with DTR in a CAT session; unplug, suspend, port close or the OUT stream stopping for 1 s unkeys.
• CAT TX;: unkeys when the host has sent nothing on the port for 5 s (CAT clients poll every second or so).
• Always: the radio's TOT (tot_s, radio-features.md 1 and 3.2) applies to host PTT too.
• MMDVMHost and the CPS toggle DTR and RTS as they open the port: line PTT is armed only when the "serial PTT" setting is on and no MMDVM or CPS session is active (hostlink_mode() idle), so programming the radio can't key it.

6.4 Sharing the serial port

The host link dispatches by the first byte of a request (cps-protocol.md 1). CAT commands are two uppercase letters followed by digits, a sign or ;; open-firmware CPS requests are a letter followed by binary bytes (an area or sector number 1-10, or a sub-command 2-7). A CAT recognizer accepts [A-Z][A-Z] followed by [0-9;+-] within 3 ms, and a CAT session ends after 2 s without a CAT command, as the CPS session ends today. SLIP-framed USRP starts with 0xC0. Both need the host link to accept more than one side protocol (today it takes one, the debug link: hostlink_set_side_protocol), a small change in core/hostlink.

6.5 Interaction with the hotspot and the UI

• Hotspot mode owns the modem (MMDVM over the serial port or UDP); USB audio sessions are refused while it runs, and entering hotspot mode ends them.
• The SFR and the IP gateway follow the same rule as the hotspot for DMR transmit (the data service's channel access).
• The UI shows a status chip ("USB", "NET") while a host audio session is active and "TX USB" while the host keys; the speaker keeps playing received audio unless the user mutes it; the volume knob doesn't change the level sent to the host.
• Settings (UI and qdmr): USB personality (serial, serial + audio, network, network + audio, audio fob), serial PTT line and polarity, RX gating (squelch / ungated), USRP ports and peer, TX audio gain.

7. Phased plan and effort

Effort in working days for one developer who knows the code base, including host tests, HIL tests and docs.

Total: about 30-45 working days for phases 1-4 (6-9 weeks), plus phase 5 options. Phases 2 and 3 are independent after phase 1; phase 4 needs only phase 1 and one of 2 / 3. On a radio with no FM path, phases 2-4 still deliver DMR over USB.

8. Risks

9. In the repository now

Running the probe: tools/rfoundry_debug.py aprobe, on a board with CONFIG_AUDIO_PROBE.

9.1 USRP on the network (CONFIG_NET_USRP)

What the radio does with the switch on, in the USB network personality (or PPP):

An HR_C6000 board's FM transmit path is PWM into the HR_C6000's differential microphone input: MIC_P / MIC_N on and the microphone (LINEIN1) off while the host transmits, a timer channel at 72 kHz with DMA, nine carrier periods a sample, linearly interpolated with the rounding error carried from period to period. Full scale is ±50 timer steps, about 2.6 kHz rms deviation for a full-scale sine before the chip's limiter; fm_tx_nominal_peak (13800) is about 60 % of the peak deviation. The chip's own FM chain does the rest (pre-emphasis, limiter, sub-audio tone). On the SDR bench a 1 kHz tone at 13800 from the host went out at 1.1-1.2 kHz rms deviation (1.68 kHz peak) with 13-14 dB SINAD in the voice band (2026-10-13). The probe's plain PWM measured 14-16 dB, so the error feedback doesn't improve it, and the PWM's resolution is probably not the limit.

Known limits:

• The receive audio is the speaker's FM feed-through, so it follows the volume knob (the HR_C6000's RX gain), stops at volume zero, and drops out while a beep plays (the feed-through is off for PCM). A tap independent of the speaker (the RX RAM, modem-hrc6000.md 8) would fix all three.
• No flat mode: the PWM path stops at the codec's 3.5 kHz, so 9600 baud needs the 0x04 path or a modification.
• Ports and peer are fixed; settings (UI, qdmr) come with phase 3's settings.
• The wire format is from the public descriptions; a capture against a live AllStar node or Analog_Bridge is still owed (owner question 4).

9.2 MMDVM FM frames

MMDVMHost can carry FM audio to and from the modem (AllStar linking through its FM network). That frame layout is not in any public prose description we found (2026-10-13): the protocol write-ups predate FM. It can be specified the way the rest of mmdvm-protocol.md was: by observing what an unmodified MMDVMHost sends to and expects from an MMDVM modem with FM configured (a serial capture on the bench), written up as black-box behavior. Until then the hotspot only ACKs FM_PARAMS (mmdvm-protocol.md 2.14) and USRP (9.1) is the FM network path.

10. Owner questions

1. USB IDs: move to a pid.codes VID 0x1209 block for all personalities now (the existing serial / network PIDs too), or keep NXP's VID for serial and network and use pid.codes only for the new ones?
2. Default serial PTT line and polarity: RTS asserted (most software's default) or DTR=1 / RTS=0 (AIOC's choice, safe with CHIRP-style programmers)? Either way it only arms in audio sessions.
3. Which personality should a radio boot into: serial (today), or serial + audio once phase 3 is done?
4. USRP: confirm the wire format with a capture from the owner's AllStar node or Analog_Bridge before the firmware relies on it; which ports and peer address as defaults?
5. rigctld on the radio, or a host bridge? Settled: on the radio (CONFIG_NET_RIGCTL, tcp-services.md 6).
6. DMR voice endpoint: send DMR call metadata (IDs, talker alias) to the host as USRP TEXT frames (Analog_Bridge's convention), on the debug link only, or both?

References

• HR_C6000 user manual (Zhejiang Hongrui; vendor datasheet): 4.5 codec, figure 4.12, 5.3 RAM tables, 6 FM, register table (0x06, 0x22, 0x36, 0x37, 0x82, 0xD7, 0xE0-0xE4) and appendix A (FM paths).
• STM32F405 device header (stm32f405xx.h, ST, in third_party/cmsis-device-f4): OTG_FS endpoint count and FIFO size. TinyUSB 0.21.0 (MIT): src/class/audio, src/portable/synopsys/dwc2/dwc2_stm32.h, examples/device/cdc_uac2.
• USB Device Class Definition for Audio Devices 1.0 and 2.0; USB CDC 1.2 (ACM, NCM); USB HID 1.11 (usb.org).
• ITU-T G.711 (mu-law). RFC 1055 (SLIP), RFC 3550 / 3551 (RTP and its audio profile), RFC 4733 (RTP events), RFC 5456 (IAX2), RFC 7587 (Opus over RTP).
• Hamlib rigctld(1) manual (the NET rigctl protocol); flrig documentation (XML-RPC).
• AIOC, an MIT-licensed USB sound card + serial + CM108-style HID cable on an STM32: https://github.com/skuep/AIOC (interfaces, PTT lines, rates, ASL3 and Direwolf support as its README states).
• AllStarLink community forum, USRP channel driver set-ups (ports 32001 / 34001 with Analog_Bridge): https://community.allstarlink.org/t/linking-allstar-to-a-mmdvm-hotspot-dmr-to-allstar-node-bridge/18146; M17 project wiki, usrp2m17: https://wiki.m17project.org/usrp2m17_bridge; AllStarLink wiki, usbradio channel driver: https://wiki.allstarlink.org/wiki/Chan_usbradio.

View the source of this page