Configuring and Optimizing a Digirig

Updated: July 8, 2026

The most exciting advancements in digital modes for ham radio are being made in software, not hardware. To utilize these modes, like APRS and FT8, you need a way for audio from your radio to get digitized and into your computer.

There are several ways to make this happen. You can put the audio from your radio into the sound card in your computer. Or you can get an external device that turns the voltage based audio signals into digital signals over USB. The latter is preferred by most hams. There are many manufacturerers of these external devices, including the NA6D AIOC, the Signalink USB, the Digirig Lite and the Digirig Mobile.

I prefer the Digirig Mobile for it’s small size, excellent chips, and durable construction. You’d think you can buy the device and the proper cables, plug them in, and you are good to go. Usually, it’s not that easy and it can take some fiddling to optimize the performance of your setup.

I’ll give a bunch of specifics for the Digirig, but these principles can be applied to any usb audio interface. I’ll focus on Linux since it’s the trickiest to get working, and it seems that lots of hams buy inexpensive Raspberry Pies or other single board computers to use for their ham radio projects, and Linux is the preferred operating system on these platforms.

This deep dive will describe how these devices and the Linux sound subsystem work, and how to configure Linux to optimize the performance of your device.

Background and Context

USB audio interfaces like the Digirig perform one key function. They take audio signals, usually in the form of voltage on a wire, and turn them into digital signals, which are transmitted over USB to the host computer. The Digirig is powered by the host USB bus, and has a chip (or two) in it which do most of the work.

The USB sound subsystem of the Linux kernel is called ALSA, or Advanced Linux Sound Architecture. This subsystem recognizes usb devices, loads appropriate drivers, and creates devices in the operating system that user programs can use to record and play sound. ALSA also provides basic audio capabilities, depending on the capabilities of the device and the device driver for it. For example, some devices support Automatic Gain Control (AGC), and if the devices and it’s driver support this capability, ALSA can turn it on and off.

About the hardware

The Digirig Mobile has two chips in it, and this is why I prefer it over the Digirig Lite.

Silicon Labs CP2102N USB to UART Bridge Controller

C-Media Electronics CM108 USB Audio Device

Use good USB cables with ferrite beads. Some people have good results with the old charging cable the found in their junk drawer, but many operators have underwhelming results that are improved by using better cables with good shielding and ferrite beads.

The audio pathway

Making it convenient

Digirig mobile is a usb device, and therefore how it shows up in linux and is addressed the the operating system can change depending on what other usb devices are in the computer.

The usb audio chip in the digirig mobile, C-Media Electronics CM108 Audio Controller, ID 0d8c:013c, does not have a unique serial number, so all of these chips look the same to the linux operating system no matter what device they are in. This means that the operating system can’t tell the difference between one digirig and another.

root@hamspot:/etc/udev/rules.d# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 0424:2412 Microchip Technology, Inc. (formerly SMSC) Hub
Bus 001 Device 006: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 007: ID 0d8c:0012 C-Media Electronics, Inc. USB Audio Device
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 1546:01a7 U-Blox AG [u-blox 7]
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Also, the also drivers in linux identify this chip with the name “Device” which is less helpful.

root@hamspot:~# cat /proc/asound/cards
 0 [Device         ]: USB-Audio - USB Audio Device
                      C-Media Electronics Inc. USB Audio Device at usb-xhci-hcd.0-2.2, full speed
 1 [vc4hdmi0       ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 2 [vc4hdmi1       ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1

The good news is that’s it’s easy to improve. The first thing we will do is teach the linux dev subsystem about this card and instruct it to give it a friendlier name. I’ve chosen “digirigmdev” for this. Digirig is obvs. M is for mobile, if you have a digirig lite, you could use a “l”, but you’ll need different chip identifiers. ‘Dev’ because this is the device name.

Put this in /etc/udev/rules.d/85-digirig-mobile.rules. The file name doesn’t really matter, as long as it ends in .rules and you don’t overwrite a file that’s already there.

SUBSYSTEM=="sound", KERNEL=="card*", ATTRS{idVendor}=="0d8c", ATTRS{idProduct}=="0012", ATTR{id}="digirig_m_dev"

It’s super important that this be all on one line with no linefeed in the middle.

Then:

# udevadm control --reload-rules
# udevadm trigger --subsystem-match=sound

Sometimes you have to physically unplug and replug the device, and now you should see

# cat /proc/asound/cards
 0 [digirig_m_dev  ]: USB-Audio - USB Audio Device
                      C-Media Electronics Inc. USB Audio Device at usb-xhci-hcd.0-2.2, full speed
 1 [vc4hdmi0       ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 2 [vc4hdmi1       ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1

This solves most of the problem. Now you can do things like:

# alsamixer -c digirig_m_dev -V all

And you’ll always get the right card.

But we are going to take it one step further. One of the limitations of audio devices on linux is that only a single process can have the device open at one time. That means if you are using graywolf with your digirig, you can’t see or adjust the mixer levels with alsamixer. This is inconvenient because adjusting audio levels can be a bit tricky, and it’s really nice to be able to see all the stages in the audio pipeline at the same time.

To fix this, we are going to create a new, sharable also device on the mic input of the digirig, which will allow multiple process to open it at the same time. It’s super easy.

Put this in /etc/asound.conf:

#
# allow multiple processes to read the digirig microphone
#
# relies on the udev rule in /etc/udev/rules.d/ to
# give a device name of digirig_m_dev
#
pcm.digirig_m_mic {
    type dsnoop
    ipc_key 2001
    ipc_perm 0666
    slave {
        pcm "hw:digirig_m_dev,0"
        channels 1
        rate 48000
        format S16_LE
    }
}

This will create a shared memory segment, readable by any user on the system, which multiple processes can open to concurrently get audio. In graywolf, use digirig_m_mic as the device path for your “input” audio device.

[screenshot]

Limitations

Because all the chips identify the same, if you plug two digirig mobiles into your linux machine: - only one of them will get the convenient digirig_mobile device name - you don’t have a reliable way of knowing which device got that name, if you plug them in after boot, it will usually be the first one. If both devices are plugged in when the system boots, it’s random. - The second device will get some other generic name like Device or Device_1

If you want to fix this, then you’ll have to switch your strategy and assign a friendly name based on the usb port it’s plugged into, instead of based on the chip in the device. Since that vast majority of people only have one digirig plugged in at a time, I won’t document the port based approach (unless someone contacts me and asks for it).

For PTT, it’s different

THE Silicon Lab CP2102N chip in the digirig mobile, does have a serial number.

# ls -l /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_c880b1631cc6ef11bf7f6d527a5e3baa-if00-port0
lrwxrwxrwx 1 root root 13 Jul  8 12:03 /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_c880b1631cc6ef11bf7f6d527a5e3baa-if00-port0 -> ../../ttyUSB1

This USB serial chip (yes the digirig has 2 chips, one for audio, one for data) does have a serial number, and linux creates a device with the serial number in it. You can use this device in your software bind the software to only this specific physical digirig device, you have two? The device name will be different for each one.

Notice also that the device with the serial number is just a link to the friendly device name. You might choose to just use the /dev/ttyUSB1 device, which will be stable-ish, probably, as long as you don’t have many usb devices and you don’t plug/re-plug them very much.

Variability in radio performance

The design and quality of the circuitry in your radio can make a big difference in how well it performs using digital modes.

Setting up your radio

No matter what radio you have connected to your Digirig, you should adjust the following settings.

Squelch Off: There are two reasons we want to turn the squelch off on the radio. First, it can take a few milliseconds for the radio to notice the signal and open the squelch. That means the first part of the signal is lost. When using analog voice modes this doesn’t matter. For digital modes it can reduce the number of packets you decode. Second, modern modem software is really good at decoding packets. Give it all the noise from the radio and let it figure out what the signal is.
Single band: If a single comes on the other band, you don’t want it interrupting the digital signal you are trying to decode. Start in single band mode and get it working, then you can experiment with whether your radio will work in dual band mode. Most won’t but my Kenwood TM-V71 sends only the signals from the designated digital band to the Digirig, and you can concurrently use the handset on the other band.
Power Save Off

squelch off
volume knob less than half
tune 144.390
use left channel or mono for both input and output
PTT via RTS

KG-UV9PX

black K1 cable to the black port on the digirig mobile

Menu 8 SQL-LE - set to 0 - squelch completely off Menu 8 Vox - OFF Menu 2 Power Save - OFF

Push TDR to disable band B Tune Band A to 144.390

Put the volume knob in the middle.

go to Graywolf -> Audio Devices, and mess with the gain

The first time, I had to restart graywolf to get the PTT to work. I think it might be because I had the TM-V71 hooked up, then unplugged the digirig mobile from the Pi, then hooked up the UV9PX. But when I tried to replicate, it worked fine.

TM-V71

Green 6 pin Din to Data port on the Radio, black TRRS jack to the Audio port on Digirig Mobile

The data port on the radio outputs at constant volume, which is independent of the front panel volume. This makes it easy to turn up the volume to hear if data packets are coming, but turn it down it you don’t want to hear it during regular operations.

Set Menu 517 to B, which transmits and receives data on Band B
Set Menu 518 to 1200 for the APRS data speed

Tune band B to 144.390

In graywolf: - PTT via RTS - left channel or mono for both input and output

Go to audio devices and mess with the gain

No adjustments required to graywolf settings to switch between K1 cable and the minidin6 cable.