{"id":951,"date":"2026-04-12T14:46:52","date_gmt":"2026-04-12T12:46:52","guid":{"rendered":"https:\/\/www.i8zse.it\/en\/?p=951"},"modified":"2026-06-07T14:50:45","modified_gmt":"2026-06-07T12:50:45","slug":"linux-ports","status":"publish","type":"post","link":"https:\/\/www.i8zse.it\/en\/linux-ports\/","title":{"rendered":"Linux ‘ports’"},"content":{"rendered":"

Serial and audio: nothing to fear<\/h3>\n

You connect the TRX to the PC and the software cannot find the port. A strange name such as \/dev\/ttyUSB0<\/code> appears (and disappears) without warning.
\nLet\u2019s clarify an issue that is often a source of headaches, and how to stop guessing.<\/p>\n

Anyone approaching the world of digital radio<\/strong> – FT8, PSK31, Winlink, CAT control – quickly runs into an unexpected obstacle: not propagation, not the antenna, but the simple fact of failing to make the computer and the radio communicate. On the system side we have USB peripherals, and Linux assigns seemingly mysterious<\/em> names that change: \/dev\/ttyUSB0<\/code> today, \/dev\/ttyUSB1<\/code> tomorrow.
\nWithout a map<\/em>, it is easy to get lost.<\/p>\n

The best approach is to start from the beginning: what a communication port is on Linux, how it is assigned a name, why there are \u201cphysical\u201d and \u201cvirtual\u201d ports, and finally – at the end – an accessory I wrote specifically to allow colleagues who prefer not to use the terminal to get a complete overview of the system.<\/p>\n

Everything is a file – the Unix philosophy<\/h3>\n

On Linux (like all Unix-like systems), every hardware device is represented by a special file<\/strong> in the \/dev<\/code> directory.
\nThis is not just a historical choice: it means that communicating with a serial port uses exactly the same interface (open, read, write, close) as a normal text file. A program like WSJT-X does not need to know whether it is talking to an FTDI chip or a Prolific: it simply opens \/dev\/ttyUSB0<\/code> and writes bytes.<\/p>\n

\n

Files in \/dev<\/code> do not occupy disk space because they are interfaces<\/em> to the kernel. Writing to \/dev\/ttyUSB0<\/code> means sending data to the radio connected to the first USB-serial adapter; reading from the same file means receiving data from the radio.<\/p>\n

Names<\/h3>\n<\/div>\n

But how does Linux assign names? A port name is not permanent by default: it depends on the order in which the kernel detects devices at boot time or when a USB device is connected. The subsystem responsible for this is called udev<\/strong>, and it works as follows: when a USB-to-serial adapter is inserted, the kernel loads the appropriate driver (e.g. cp210x<\/code> for Silicon Labs chips, ftdi_sio<\/code> for FTDI) and creates the node in \/dev<\/code>. Based on the device type it assigns a name (ttyUSB for USB serial adapters) and a number (0 for the first, 1 for the second, and so on). The zero in \/dev\/ttyUSB0<\/code> indicates it is the first available at that moment. If two interfaces are connected, the one the kernel sees first becomes ttyUSB0<\/code>, the other ttyUSB1<\/code>. Unplugging and reconnecting can change the order.<\/p>\n

External ports, internal ports<\/h3>\n

It is also important to distinguish between external physical ports<\/strong> (generally USB-connected) and internal physical ports<\/strong> (integrated into the motherboard or a PCI card).<\/p>\n

External ports<\/strong> are by far the most common in modern setups. A USB cable with an FTDI chip or a dedicated radio audio\/serial interface (Signalink, RigBlaster, DigiRig\u2026) all appear here.
\nLinux identifies the manufacturer and model using two numbers: the VID<\/strong> (Vendor ID) and PID<\/strong> (Product ID), stored in the chip firmware and usually visible with the lsusb<\/code> command.<\/p>\n

# Example: Silicon Labs CP2102 chip<\/span>\r\nBus 001 Device 004: ID 10C4:EA60<\/span> Silicon Laboratories CP210x UART Bridge\r\n                       ^^^^ ^^^^<\/span>\r\n                       VID  PID<\/span><\/pre>\n
Internal ports<\/h3>\n
The \/dev\/ttySN<\/code> ports correspond to physical UARTs soldered onto the motherboard (typically two, ttyS0<\/code> and ttyS1<\/code>, i.e. the old COM1 and COM2 of Windows). On modern PCs they are often unused or absent, but they are still common in older computers that work very well for amateur radio use. They have a fixed I\/O address (0x3F8<\/code> for COM1, 0x2F8<\/code> for COM2) and a dedicated IRQ (IRQ 4 for ttyS0, IRQ 3 for ttyS1), making them very stable and predictable – there is no risk of name changes. Often a 9-pin connector for ttyS0 is found on the rear panel, while ttyS1 may exist on the motherboard without an external connector.<\/p>\n
Virtual ports<\/h3>\n
A virtual port has no hardware<\/em> behind it: it is an abstraction created by software. Functionally it behaves like any physical port: it can be opened, read, and written. The data, however, follows a different path. There are several types:<\/p>\n
Pseudo-terminals (PTY)<\/strong>: ports created in pairs to manage user data streams; the pair consists of a master<\/strong> (\/dev\/ptmx<\/code>) and a slave<\/strong> (\/dev\/pts\/N<\/code>). Normally you never see them, but they may appear in port scans; if so, ignore them.<\/p>\n
Virtual pairs (socat, tty0tty)<\/strong>: tools such as socat<\/code> or the kernel module tty0tty<\/code> can create pairs of serial ports connected to each other: everything written on one side appears on the other. They are often used to bridge two programs that both want to \u201cown\u201d a port, or for debugging without physical hardware.<\/p>\n
Audio: same logic, different subsystem<\/h3>\n
Sound cards on Linux are managed by ALSA<\/strong> (Advanced Linux Sound Architecture), with an optional layer called PulseAudio<\/strong> or PipeWire<\/strong> running above ALSA.
\nUnlike serial ports, audio devices do not appear in \/dev<\/code> with readable names: they are accessed through numeric indices or higher-level APIs such as sounddevice<\/code> (Python) or portaudio<\/code>.<\/p>\n
For a radio operator, the most relevant parameters are the number of input and output channels<\/strong> (needed to handle separate signals), the sampling rate<\/strong>, and the latency<\/strong>.
\nChannel count matters when separating different streams (e.g. RX\/TX or multiple receivers); for a single transceiver it is less critical. Latency affects real-time monitoring and system stability.
\nRegarding sampling rate, while 44.1 kHz is the historical standard in music audio, in amateur radio 48 kHz is generally more important, as it is the de facto standard for most USB interfaces and DSP systems. Many digital mode programs such as WSJT-X<\/span><\/span> and many SDR devices operate internally at 48 kHz or multiples thereof, making this rate preferable to avoid resampling and potential signal degradation.
\nAn often-overlooked aspect is clock stability and timing synchronization: poor audio clock stability can introduce frequency drift in the sampled signal, making clock quality more important than nominal sampling rate alone.
\nLow latency is important for real-time monitoring and some SDR applications, while in digital modes like WSJT-X it is usually less critical. In some cases, higher latency can even improve system stability by reducing errors and audio dropouts.<\/p>\n
The standard way to inspect audio devices is using aplay -l<\/code> or pactl list sinks<\/code>, but the output is verbose and difficult to read at a glance.<\/p>\n
Devenum<\/h3>\n
\n
To reduce these issues and avoid using the terminal, I developed an application that displays all relevant information (port type, driver, VID:PID, USB path, IRQ, process using the device, audio channels, latency) in a single graphical window with a tabbed layout, easy to use. The program is preinstalled in HamLinux, but can also be downloaded from my GitHub<\/a>.
\nEach port is shown as a card<\/strong> with a colored strip on the left indicating its type at a glance.<\/div>\n
\"\"<\/a>
\n\"\"<\/a><\/p>\n<\/div>\n
The software displays all relevant information:<\/p>\n
For serial ports:<\/strong><\/p>\n