Skip to content

Section 14 troubleshooting

Jump to bottom
madmedicnl edited this page Sep 30, 2026 · 3 revisions

14. Troubleshooting

"Waiting for spectrum" and no receive audio (CAT radio). The radio's capture device could not be opened. Common causes:

  • The device is being held by the system audio server (PipeWire/PulseAudio). On Linux, for a dedicated radio sound card, disable that card in WirePlumber so sdroxide can open it exclusively:

    # ~/.config/wireplumber/wireplumber.conf.d/51-radio.conf
monitor.alsa.rules = [
  {
    matches = [ { device.name = "alsa_card.usb-<your-card>" } ]
    actions = { update-props = { device.disabled = true } }
  }
]

    Then run systemctl --user restart wireplumber. (Find the exact device.name with wpctl status or pw-dump.)

  • The device is in use by another program, or was unplugged. sdroxide shows a warning banner naming the device; use Dismiss to hide it after fixing the device.

"A buffer underrun or overrun occurred", and FT8/FT4 will not decode. The audio device is losing samples. The line in the diagnostics reads

WARN sdroxide_audio: radio audio input: the audio stream from "…" glitched — the
host says samples were lost between two callbacks …

Read the stream's name first. Only two of them can cost a decode: radio audio input (a transceiver's demodulated audio) and radio IQ input (an SDR's I/Q on a sound card). The mic input stream is the microphone, and nothing reads it at all unless you are transmitting by voice — while receiving, its samples are drained and thrown away on every tick. Both streams glitch together on a machine that is momentarily busy, which is why the microphone's line is INFO and says so in as many words: it is not why a digital mode is failing to decode, and it sent one reporter looking for what a USB microphone had to do with FT8 (issue #367).

and after the first one they are counted and summarised rather than repeated, so a stream that does this every few seconds no longer buries the rest of the log. The host is telling sdroxide that the captured audio is not continuous: what arrives is spliced end to end, with a hole taken out of the middle.

For listening, that is a click. For the timed modes it is fatal, and silently so — every tone after the gap arrives earlier than it was sent, so the whole fifteen-second period misaligns and decodes nothing while the waterfall looks perfectly healthy. When that happens the FT8 panel says so directly:

WARN sdroxide_digi: FT8: the last receive period arrived 0.4 s short of the
15.0 s it should be — the audio device is losing samples …

The period you selected the mode in is exempt, however short it is: a mode chosen four seconds before the next boundary has legitimately only heard four seconds, and reporting that as a fault at every start had two people looking for a broken sound card that was never broken (issues #363, #367). So is the period the audio itself started in, which is not always the same one — the device may still be opening when the slot clock begins. Counting starts with the first period sdroxide has heard all of.

A period that arrives completely empty is a different message, because it is a different fault — no audio is arriving at all, rather than audio arriving with a hole in it:

WARN sdroxide_digi: FT8: no receive audio is reaching the decoder — a whole
15.0 s period arrived empty, so nothing can decode …

That is what a radio switched off, or an audio device that is not the one the radio is feeding, looks like from here. It is said once and not again until audio comes back, rather than every fifteen seconds for as long as it lasts — which is what filled one reporter's log with a thousand sample-loss warnings about a sound card that was never losing anything (issue #393).

A virtual audio cable — VB-Audio, VAC, Flex DAX — is the usual source, and it is not a fault in the cable so much as a consequence of what one is: there is no crystal at either end, so the program feeding it and sdroxide reading it drift apart until the driver drops or repeats a buffer to catch up. Things that help, roughly in order:

  • Set the same sample rate on both ends of the cable (48000 Hz) in Windows' Sound → device → Advanced, on the cable's playback and recording sides, and in the program feeding it. A rate mismatch is resampled by Windows and is the most common cause of a steady drip of glitches.
  • On VB-Audio's Control Panel, raise the cable's internal buffer (Max Latency) a step or two.
  • Give sdroxide and the feeding program a moment of CPU: a machine that is busy enough to stall either one for a few tens of milliseconds produces exactly this.
  • Where the radio offers a real sound device as well as a virtual one, use it.

A real sound card reporting the same thing means this machine is not keeping up with it, which is the capture frames dropped warning's territory rather than this one — see §6.2.

"No radio" at startup, or the radio disappears mid-session. sdroxide shows the reason it could not open the interface and keeps trying it in the background — every second at first, then more slowly — so a rig that is merely late (ExpertSDR3 not up yet, an SDR still booting) attaches on its own within a few seconds of appearing. The same applies when a network rig hangs up: it reconnects once the radio is back. You only need Apply / reconnect to switch to a different interface, or to apply a settings change.

The dial jumps back, with a banner saying the frequency is out of range. The receiver cannot tune there. sdroxide checks the range the front end reports before it asks the hardware for anything, and returns the dial to the last frequency that worked, because a driver asked for the impossible does not always fail cleanly — a LimeSDR asked for a frequency below its range stops receiving altogether until it is set up again. If it happens anyway (the driver accepted the request and then failed), the front end is restarted on the last good frequency by itself, and reopened from scratch if that is not enough. Nothing needs restarting by hand; Dismiss clears the banner.

IQ shows no spectrum, or a warning that the device is mono. IQ requires a two-channel (stereo) capture device. A mono USB adapter cannot carry I and Q. Use a stereo line-input interface for IQ, or switch Sound format to Demod audio.

The log warns about dropped samples and a lower sample rate, but only while I am transmitting. It is not a fault, and is no longer reported as one. Most front ends are read only while they are receiving, so for the length of an over the receiver is streaming into a buffer nobody is emptying; it fills, and everything after that is discarded until the backlog is dropped at key-up. That is the ordinary cost of transmitting, at exactly the sample rate, for as long as you hold the key — nothing to do with the computer keeping up, and lowering the sample rate does not change it. It is now counted separately and said in the same breath as "discarded while keyed", at debug level rather than as a warning. A drop count that appears while you are receiving is the real thing, and the advice there still stands.

This is most visible with a panadapter pairing (§6.2.15), where the lent receiver is a different radio from the one being keyed and knows nothing about the over; Blank on transmit, on by default, is what stops it being read. Turn that off and the receiver keeps being read through the over, in which case anything dropped really was dropped.

The T/R switch relay does not click. On Linux, the USB HID relay boards and the CM108 sound cards need a udev rule that no distribution ships. Install it and replug the device — see 6.11.1. If the device does not appear in the picker at all, cargo run -p sdroxide-relay --example relay -- --list --all prints every HID device the machine can see, which tells "not permitted" apart from "not recognised". Several CM108 clones carry a genuine C-Media id and ignore the GPIO report entirely; nothing but listening for the click separates those.

Every transmit is refused, saying the T/R switch is not answering. That is the switch's fail-safe doing its job: the relay that protects the receiver has stopped responding, so the over is refused rather than sent into an unprotected front end. Check the cable and press APPLY on the T/R switch tab to try again. If you would rather transmit anyway, set If it will not answer to Transmit anyway, warn — but read 6.11.4 first.

The SDR still gets blasted when I key the rig at the microphone. Expected, and the one thing this cannot fix from software: sdroxide learns of an over you start at the radio by asking over CAT, a few hundred milliseconds in. Wire the rig's SEND line into the transmit sense input (6.11.3) to cut that to milliseconds, key from sdroxide instead of the microphone where you can, and use an RF-sensed hardware T/R switch for a front end genuinely worth protecting. See 6.11.5.

Transmit was cut off, and now every key-up is refused. The SWR guard has tripped (§2.10): the radio reported an SWR at or above the limit, so the over was stopped and transmit is latched out until you say you have seen it. The banner names the figure; Acknowledge on it re-enables transmit, and the trip is also shown on Settings → General. Check the antenna first — if the fault is still there the next transmission stops too. Turning the guard off clears a standing trip as well, which is the answer while you are tuning a manual ATU.

The CAT radio does not change mode. On the Radio tab, set Mode control to CAT. For the modes sdroxide modulates through the rig's sound card — FT8, FT4, PSK, RTTY, SSTV and the rest — set Digimode mode to USB or DIGI as your rig expects; that setting governs them instead of Mode control. Check the serial port, baud, and (for Icom/Xiegu) the Radio ID. Check CAT family as well: Kenwood, Yaesu, Elecraft and QRP Labs look alike on the wire and none of them obeys the others' commands.

The rig goes to USB rather than USB-D, so nothing comes out of the USB audio. Set Digimode mode to DIGI. On an Icom, also check Radio model: USB and USB-D are the same mode byte over CI-V and what separates them is a second command, whose sub-command number differs by model — an Other Icom is not sent it at all, because the wrong number writes somewhere else entirely. With both set, the rig goes to USB-D (LSB-D where SSTV or RADE rides the lower sideband) and takes the over from its data input. A rig with no DATA position wants USB here instead, plus its SSB modulation source set to the USB input at the radio — MENU → SET → Connectors → MOD Input on an IC-7300.

The CAT radio follows my dial but ignores frequency changes from sdroxide. Take the radio out of memory mode: most rigs answer a frequency read from a memory channel but refuse to be tuned into one, so the app follows the radio while the radio ignores the app. (On Yaesu this used to also happen because the frequency field is eight digits wide on the FTDX1200/3000/5000 generation and nine on the FT-891/991A and FTDX10/101 — sdroxide now reads the width off the rig's own reply, so both work without a setting.) On a Kenwood, check that CAT family is Kenwood and not Yaesu: the frequency field is eleven digits here, and a Yaesu-width one is a syntax error the rig answers with ?; while carrying on reporting where it already was.

The Kenwood keys up and will not stop transmitting. CAT family is set to Yaesu. Yaesu unkeys with TX0;, and on a Kenwood that is a transmit command — the rig is being told to key, twice. Set the family to Kenwood, which unkeys with RX;. Pull the CAT cable or switch the rig off to stop it in the meantime.

The Kenwood keys but no audio goes out. On a TS-590S/SG, TS-890 or TS-990, set Send command to TS-590 style (TX1;). The plain send selects the microphone input and mutes the ACC2/USB audio sdroxide transmits.

The Kenwood transmits on the wrong band. On a TS-2000, set Send command back to TS-2000 style (TX;). TX1; is DATA SEND on a TS-590 but transmit on the sub-band on a TS-2000.

The QMX stopped answering, and now nothing on its CAT port works. Something sent it a carriage return, which a QMX takes as an instruction to leave CAT and become a terminal for the rest of the session — a terminal emulator left open on the same port does it on the first Enter. Close whatever else is on the port, then power the radio off and on. sdroxide never sends one.

The QMX answers nothing at all. Try its other ports. A QMX offers up to three virtual COM ports over USB and only one of them is the CAT port; Baud has no bearing on it either way, since the port is not a real UART.

The QMX's Drive slider does not change the power. It cannot: there is no CAT command that sets a QMX's output power, so the slider only reaches the level of the audio going into the sound card — and in Digi even that changes nothing, because the radio measures the frequency of what you send it and synthesises the carrier itself. Set the power at the radio.

The QMX will not transmit, and the log says its SWR protection has tripped. It has latched, and only the radio can clear it — sdroxide deliberately does not, because clearing a protection trip is a decision about an antenna. Check the antenna, then reset it at the radio.

The QMX's panadapter is 12 kHz off, or it is nothing but noise. Two different faults. Everything sitting 12 kHz from where it belongs is the I/Q centre offset: it should be -12000, which sdroxide fills in when you pick the QRP Labs family with Sound format on IQ — a config carried over from before that will still have 0. (In CW, expect a further ~700 Hz: the radio moves its I.F. by the pitch, and one figure cannot follow that.) A panadapter that is noise from edge to edge with the format on Demod audio is the other way round — the radio is still in its own I/Q mode from something else, and sdroxide switches it back off at connect, so reconnect.

The radio transmits at a power the Drive slider does not show — often much less — and moving the slider changes nothing. Every one of these radios stores its output power per mode, and sdroxide commands the mode at key-down. So the level you set while the rig sat in one mode was stored in that mode's register, and the over went out on another one's. sdroxide now writes the Drive level behind every mode command, which puts it in the register the over transmits on; if you are on a build older than that, set the power at the radio in the mode it actually transmits in. The tell is a tune: the operating level is restored at unkey, so the rig's own power display jumps to what the slider says the moment a TUNE ends.

The Elecraft goes into plain SSB for FT8 instead of DATA. CAT family is set to Kenwood. DATA is a flag beside the mode there (DA) but a mode of its own here (MD6), so the Kenwood profile leaves a K3 in USB and then earns a rejection for the flag — with nothing to show that anything was refused. Set the family to Elecraft.

The Elecraft is in DATA but nothing decodes, and sdroxide shows no mode. The rig is in the wrong DATA sub-mode. MD6 restores whichever of DATA A, AFSK A, FSK D and PSK D that band was last left in, and only DATA A is the sound-card path; the other three hand the over to the K3's own modems. Set Mode control to CAT and pick the mode in sdroxide, which sends DT0; behind the mode and pins it — or press DATA MD at the radio until it reads DATA A.

The Elecraft's Drive slider only reaches a fraction of the rig's power. The OM; query at connect found no power amplifier, so the slider spans 12 W rather than 110. On a K3 that means the KPA3 was not detected; on a KX3 or KX2, that the KXPA100 is not attached over its control cable. Check the log line Elecraft CAT: rig identified for what the radio said it was.

The rigctld link will not open. Check that a daemon is actually listening — rigctl -m 2 -r localhost:4532 f asks the one on this machine for its frequency — and that the address matches. The log line CAT open failed: Connection refused means nothing is listening there; CAT link open means the socket came up and any remaining fault is between the daemon and the radio, not between sdroxide and the daemon. Note also that PTT method DTR and RTS key nothing over a socket: a network link has no control lines. Use CAT, which asks the daemon to key the radio.

The Elecraft answers nothing at all. Check Baud: a K3, K3S, KX3 or KX2 goes no faster than 38400 (CONFIG:RS232 at the radio), so choosing 57600 or 115200 here leaves the link mute in both directions. Only a K4 runs above that.

CW transmits nothing. Check CW keying on the Radio tab — see 6.2.2. A rig in CW ignores audio sent to its sound card, so it can only be keyed from text: with Rig keyer (CAT), on Yaesu check that CW memory 1 is free to be overwritten; on a Yaesu FTX-1, sdroxide plays that memory with KY01, the form its CAT manual gives; through Hamlib rigctld, the text goes to Hamlib's send_morse, so it is Hamlib's backend for your rig that keys it (issue #412); on Kenwood, that break-in is on (sdroxide only asserts it when the rig has reported CW, because the same command is the VOX switch in every other mode); on Icom, that the radio takes 16 47 — sdroxide turns semi break-in on with every message, and a model old enough to answer NG to that needs break-in set at the radio, or [TRANSMIT] held on, instead; on Elecraft, that the rig is not sitting in a limited-access state such as BSET or VFO REV, where it answers ?; and does nothing; on any rig, that the radio is actually in CW (Mode control = CAT) and that the Drive slider — which is the rig's output power on a CAT rig, in CW as in every other mode — is not down at the bottom. On a radio whose keyer sdroxide cannot drive at all — a Xiegu G90 keys up with no power out, and the ELAD has no text keying — choose Sound card (MCW) instead: the keyed tone goes out as audio and the rig is kept on the Digimode mode sideband rather than switched to CW (on the G90, Radio controlled with the rig parked in U-D, as for FT8).

Two identical USB sound cards are hard to tell apart. Device names include the manufacturer, model, ALSA card id, and USB id in brackets (e.g. … [Device_1 · 0d8c:0014]), which disambiguates identical adapters. Where the system reports both under one name — Windows and macOS do, and two Icoms are two of the same USB codec — the second carries a tag of its own (… [#a3f1]). Re-select the intended device in the General tab if the names changed after an update. Which card each radio actually opened is in the log, on the audio output running and radio IQ input running lines.

Two radios share one sound card. Each radio has its own Radio audio devices, in its own settings — select the radio's tab first, then pick its cards. If both radios were configured before their two cards could be told apart, both may be holding the same name: re-pick each one from the list and press Apply / reconnect.

A setting did not take effect. Backend, serial, sound-format, and radio-audio-device changes apply when you press Apply / reconnect (Radio tab, or under the CAT radio-audio settings). Audio output/input device changes apply immediately. If a change still seems stuck, press Apply / reconnect again.

The display flickers, or sdroxide uses more CPU on a Raspberry Pi than it should. Both are the same setting seen from either side. Mesa's Vulkan driver for the Pi's V3D GPU (V3DV, on the Pi 4, 5, 400 and 500) makes the picture flicker — unusably so on some compositors, and not only under sdroxide; other wgpu and Vulkan applications flicker on the same driver. sdroxide looks for that adapter at startup and renders through OpenGL ES instead, saying so in the log:

sdroxide: the Raspberry Pi's V3D through Mesa's Vulkan driver (V3DV) flickers,
so this window renders through OpenGL ES instead.

The GLES path is steady but costs roughly one core of the four — 237% CPU against 140% on an RTL-SDR at 2.4 Msps, so on a Pi 5 that is a quarter of the machine. If your desktop turns out not to flicker under Vulkan, take it back with

WGPU_BACKEND=vulkan sdroxide

WGPU_BACKEND (vulkan, gl, metal, dx12) pins the renderer on any machine, and pinning it also turns the check above off — and the Windows one below with it — so WGPU_BACKEND=gl is how to force the steady path on a GPU sdroxide does not know about.

On Windows, sdroxide closes the moment it starts, and Event Viewer names igvk64.dll with exception code 0xc0000005. That module is Intel's Vulkan driver, and the exception is an access violation inside it — a crash in the graphics driver, before sdroxide has drawn anything. Nothing on this side can catch it. From 1.6.2 sdroxide does not load Vulkan on Windows at all: the window opens on Direct3D 12, with OpenGL behind it, which between them cover every Windows machine going back further than Vulkan does and are what a Windows driver is written against first. If your Vulkan driver is sound and you would rather use it, say

WGPU_BACKEND=vulkan

before starting sdroxide — in PowerShell, $Env:WGPU_BACKEND = "vulkan".

TUNE makes full power and FT8 makes full power, but speaking into the microphone makes milliwatts. The transmitter is doing exactly what it is told: it was handed silence. TUNE is a carrier and FT8 is a synthesised burst, so neither goes anywhere near the microphone — a voice mode is the only thing that does, and if the microphone is not the card you are speaking into there is nothing to modulate. The drive slider, the power register and the meters all read correctly throughout, which is what makes it look like a power bug.

An over that goes out with nothing on the microphone now says so when you unkey — "That over went out with no audio". Pick the input under Settings → General; on a headset this is usually a separate device from the speaker, and "System Default" is whatever the desktop's sound settings point at rather than whatever is plugged in.

sdroxide died with Failed to create staging buffer for index data, or another panic naming wgpu, after running for a while. The graphics driver refused an allocation and the renderer has no way to carry on without one. It is the driver's failure rather than sdroxide's — reported on an Intel HD Graphics 530 under Mesa, an hour into a session, with a wgpu validation error a moment before it — and nothing in the program can prevent it. What it can do is not walk into it twice: a panic that came from the graphics driver leaves a note in renderer-fallback.txt in the configuration directory (13), and the next start renders through OpenGL instead and says so:

sdroxide: the last session ended inside the graphics driver, so this window
renders through OpenGL instead.

The note stays until you delete it — a driver that has crashed once will crash again, and re-learning that costs another lost session. Delete the file to go back to the default renderer, or set WGPU_BACKEND to pick one yourself, which turns the check off in both directions. A panic anywhere else in sdroxide leaves no note and changes no renderer.

A blank window appears for a moment, sdroxide exits, and the console says Failed to wait for GPU to come idle before reconfiguring the Surface. An old graphics card taking too long over its first frame, on a machine with neither a Vulkan nor a Direct3D 12 driver — so OpenGL is all that is left. The first frame is where every shader is compiled and every texture allocated, and on such a card that can take several seconds; the window's real size, arriving while that is still going, used to make sdroxide wait for the card to catch up. OpenGL gives that kind of wait 2.147 seconds and not a moment more, after which the window counted as broken and the process died — twice over, the second time inside its own cleanup, which is where the backtrace came from.

sdroxide no longer asks to be kept waiting by an OpenGL driver, so a slow card is now merely slow. The wait bought nothing here in any case — nothing in sdroxide reads back from the GPU; every pass ends on the screen. To hand the timing back to the driver, for a bug report say:

WGPU_GL_FENCE_BEHAVIOR=normal sdroxide

If no window appears at all on such a machine, WGPU_BACKEND=dx12 on Windows falls back to the software renderer Windows always has (Microsoft Basic Render Driver). It is slow, and the log says Software rasterizer detected, but it draws.

From the User Manual. Home.

Clone this wiki locally