Programming cables and drivers for radios: why the PC won't see the port

The scenario is familiar to anyone who has ever programmed a radio: you plug in the programming cable, launch CPS, hit "Read" — and nothing. "No COM port," "device not responding," the port list is empty. In 90% of cases the problem is not the radio and not the software, but the cable itself and its driver. Any "programmer" for a handheld DMR radio is essentially a USB → UART adapter: inside the USB plug housing there's a bridge chip that turns USB into an ordinary serial port, plus a cord with a proprietary connector on the end. Let's break down the connectors and chips you'll encounter, why the computer "won't see the port," and how to fix it — on Windows and on Linux.

Anatomy of a programming cable

A programming cable has two parts, and problems can occur in each:

• The USB-UART bridge. The chip inside the USB plug housing. This is what creates the virtual COM port in the system and requires a driver. The most common ones: CH340/CH341 (WCH, China), CP2102/CP210x (Silicon Labs), FT232 (FTDI) and PL2303 (Prolific). Which chip is inside determines which driver to install and how the cable will behave.
• The connector to the radio. For the vast majority of handheld DMR radios (Baofeng DM-1701, TYT MD-380/UV380, Retevis, AnyTone handhelds such as the AT-D878UV, Kenwood, Wouxun) this is the Kenwood 2-pin, also known as K1 — two plugs side by side: the larger 3.5 mm and the smaller 2.5 mm. It's the same socket used by headsets for these radios: the 3.5 mm plug carries the microphone and PTT, the 2.5 mm one carries the audio output (speaker), common ground and the programming line. During programming the data travels over the contacts of that same socket at TTL level.

It's important to understand: the K1 pinout is an analog headset socket, over which data travels at TTL logic level. You can't swap a Kenwood-connector cable for one meant for, say, an AnyTone mobile (which often uses mini-USB or a proprietary connector) — you need a K1 programmer specifically for your family of radios.

Why the PC "won't see the COM port": five causes

When CPS can't find the radio, one of these things is to blame — in descending order of frequency:

1. The chip driver is not installed. A bare Windows install does not always pull the driver on its own. In Device Manager you'll see an "Unknown device" with a yellow exclamation mark instead of a line under "Ports (COM & LPT)".
2. Counterfeit Prolific PL2303 — the scourge of the market. The official Prolific driver detects the clone chip and deliberately disables it: the device appears, but with the error "This device cannot start (Code 10)". Details below — this is a pain all its own.
3. A "charge-only" cable or a defective cord with no data lines. The device is not detected at all.
4. Wrong COM port in CPS. The driver is installed, the port exists (e.g. COM5), but a different port is selected in the CPS settings, or no port is selected.
5. Wrong speed / busy port. Less often: the wrong baud rate, or the port is stuck "busy" after CPS crashed — reconnecting the cable or rebooting helps.

Counterfeit Prolific PL2303 and "Code 10"

Everyone needs to know this. The PL2303 chip from Prolific has been mass-copied in China, and for decades cheap programming cables have used precisely these clones. The modern official Prolific driver (which Windows pulls in automatically via Windows Update) can tell a fake from the original and deliberately disables the fake chip — as an anti-piracy measure. The result: in Device Manager the port appears, but with an exclamation mark next to it and the "Code 10" error. The radio won't program.

What you can do:

• Roll back to the "golden" driver. The old Prolific version 3.3.2.102 (roughly 2008) couldn't detect clones and brings the fake chip to life. In Device Manager → device properties → "Driver" → "Update" → "Browse from a list" → pick the old version manually. After that it's wise to disable driver auto-update so Windows doesn't "fix" it back to the latest one.
• The best fix — throw out the Prolific cable. Messing with the driver rollback recurs with every major Windows update. It's more reliable to buy a programmer based on CH340 or CP2102 — they have no anti-clone policy, the driver installs once and works for years.

How to tell which chip is inside

The chip isn't labeled on the outside, but the system sees it. Plug in the cable and open Device Manager (Win+R → devmgmt.msc), expand the "Ports (COM & LPT)" section. The line will hint at the manufacturer:

If the line says "Unknown device," figure out the chip by its identifier: device properties → "Details" tab → "Hardware Ids." Match the VID (Vendor ID):

• VID_1A86 — WCH (CH340/CH341);
• VID_10C4 — Silicon Labs (CP210x);
• VID_0403 — FTDI;
• VID_067B — Prolific (PL2303).

Where to get drivers and how to install them correctly

The golden rule that every manufacturer repeats in their instructions: install the driver first, plug in the cable second. If you plug it in first, Windows may "register" the device incorrectly, and you'll have to remove it and reinstall.

1. CH340/CH341. Download CH341SER from the official WCH site (wch-ic.com / wch.cn). It's a WHQL-signed driver for Windows 7–11. Unpack it, run SETUP.EXE, click "Install" — one driver covers both CH340 and CH341.
2. CP2102/CP210x. On the Silicon Labs site (silabs.com) look for "CP210x VCP Drivers" (VCP = Virtual COM Port). There's a ready installer for Windows.
3. FTDI. On ftdichip.com — "VCP Drivers." On recent Windows it usually installs itself via Update.
4. PL2303. If the cable is genuine — the driver from the Prolific site. If it's a clone — see the "Code 10" section and the old version.

After installing and connecting, check Device Manager: under "Ports (COM & LPT)" a line should appear with no yellow icon. Sometimes a reboot is needed.

Choosing the port and speed in CPS

The driver is installed, the port is visible — now for CPS itself. The procedure is almost the same everywhere:

1. Open the connection settings: in most CPS this is Settings → Communication Port (or "COM Port," "Connection").
2. Select the exact COM port number you found in Device Manager (COM5 in our example). This is the most common beginner mistake — the default port (COM1) doesn't match the real one.
3. The speed (baud rate) for most handheld DMR radios in CPS is either fixed or not configurable at all — don't touch it if you're unsure.
4. First do "Read" (read from the radio) — to confirm there's a connection. Then edit, and only then "Write."

Linux: modules and /dev/ttyUSB

On Linux it's simpler: the drivers for CH340 (ch341), CP210x (cp210x), FTDI (ftdi_sio) and Prolific (pl2303) are already built into the kernel. Plug in the cable — a device /dev/ttyUSB0 (or ttyUSB1, etc.) should appear. To check:

dmesg | tail              # see which module picked up the cable
ls -l /dev/ttyUSB*        # is there a device
lsusb                     # VID:PID — 1a86 (CH340), 10c4 (CP210x), 0403 (FTDI), 067b (PL2303)

Two typical Linux gotchas:

• No permission for the port. To open /dev/ttyUSB0 without sudo, add yourself to the group: sudo usermod -aG dialout $USER (on some distros the group is called uucp), then log out and back in.
• brltty steals the device. On many distros (Ubuntu, Raspbian) the brltty daemon for Braille displays is preinstalled. It mistakes the USB-UART for a Braille display and "claims" the port — in dmesg you'll see a line like interface 0 claimed by ch341 while 'brltty' sets config #1, and /dev/ttyUSB0 keeps appearing and disappearing. The fix: disable the daemon — sudo systemctl mask brltty-udev.service brltty.service (more reliable than apt remove, and it doesn't touch dependencies), then reconnect the cable. If you don't need Braille at all — you can remove the package too.