Wiki Reference
Troubleshooting
The app does not stay silent about failures: every refusal comes with a window or a line in a panel that gives the cause and the advice. This page collects the messages you may see — from “no picture” to lost samples — in the order “what you see → why → what to do”.
No spectrum and no waterfall
- The OpenGL unavailable window
- Cause. The spectrum and waterfall are drawn with OpenGL 3.3, and this computer did not provide it. The window shows the error text and says that the rest of the program works, but there will be no picture. What to do. Update the graphics driver; in a virtual machine, enable 3D acceleration. The cause is written to the crash record.
- The The spectrum is not being drawn window
- Cause. Drawing a spectrum frame failed with an error after OpenGL had already come up. The app itself says this is its own defect, not the graphics card's; the rest of the program works. What to do. Restart the app. A report is written to the crash record — the window names its path.
- The The display has stopped window 0.9.28
- Cause. The display stopped receiving spectrum frames because of an error; the window names it. The spectrum and the waterfall are no longer updated. What to do. Restart the app. Details are in the crash record.
- The QML error window
- Cause. The interface itself did not load; the app closes and leaves a crash record. What to do. Try reinstalling the app; if it repeats, keep the crash record for a support request.
The device is not found or does not open
- The picker window says No HackRF, RTL-SDR or tinySA found 0.9.25
- Cause. No device is visible on USB. What to do. Check the cable and power — a charge-only cable without data lines looks exactly the same. For a HackRF One and an RTL-SDR, assign the WinUSB driver with Zadig (zadig.akeo.ie); a tinySA should show in Device Manager as “STMicroelectronics Virtual COM Port”. Then press Refresh. In SDR SA PRO PRO this caption never appears: the Pluto / Pluto+ by address… row is always in the list; how to prepare its receivers is described on the pages ADALM-Pluto, Fobos SDR and bladeRF.
- Red text in the picker window: The device library did not load 0.9.25
- Cause. A library from the app's
driversfolder did not load — this is not about the device itself. What to do. Reinstall the app. The demo signal and recordings still open. - The Could not open the source window
- Read it from top to bottom: what happened, what to do, the technical cause. After it the app returns to the picker window — fix the cause, then press Refresh and Connect.
| First line of the window | What it means | What to do |
|---|---|---|
| Device not found | The device is not on the USB bus, or it vanished between the search and the opening. | Cable, power, Refresh. |
| Device visible, but no driver is bound | The device is on USB, but it could not be accessed. | First close other SDR programs; if that does not help — Zadig, the WinUSB driver, reconnect the USB. |
| Device busy with another program | Another program holds the device. | Close it and try again. |
| Device does not support the requested mode | The device or its firmware cannot do what was asked. | The cause is named further down in the window. |
| Device connection lost | USB traffic broke off. | The cable and the USB port, then connect again. |
HackRF One
- “HackRF not found on the USB bus”
- Check the cable and power; a charge-only cable without data lines looks exactly the same.
- “Device … is visible on the USB bus, but libhackrf does not see it”
- Most likely the WinUSB driver is not bound. Run Zadig and assign WinUSB to this exact device.
- The list shows serial number unavailable (in use by another program, or no driver)
- The serial number cannot be read from the bus — this happens when another program has already opened the device. Close SDR#, SDRangel, GQRX or hackrf_transfer, then press Refresh.
- “libusb could not access the device”
- The app names two causes in order of likelihood: (1) another program holds the device; (2) WinUSB is not bound. Zadig is deliberately second: someone who merely has another program open does not need to reinstall a driver.
- “The device firmware is older than the library”
- Update the HackRF firmware, or do not use the function it does not support.
- The Hardware sweep unavailable window
- The device did not start its own sweep; the app sweeps by the software path — tens of times slower. The cause and the advice are in the window.
- The Not confirmed that transmission stopped window 0.9.25
- Cause. The device did not confirm that it left transmit mode: the transmitter may still be on. What to do. Unplug the HackRF from USB and plug it in again — on connection the firmware sets the OFF mode. Unplugging does not switch off a PortaPack with a battery: turn its power off.
- A yellow line “USB transfers of odd length: N” in the Source group 0.9.36
- The device delivered a transfer whose last byte is half a sample. The app dropped it and marked the place as a break. If the spectrum became mirrored, press Reconnect.
- The caption LNA (RF) ? or VGA (IF) ?, and Total gain reads unknown 0.9.25
- Cause. The device did not confirm the new value: it may have been applied, or not. The app does not make up a sum it does not know. What to do. Set that gain again. For the amplifier (the Receive amplifier not confirmed window), toggle AMP in the Source group again.
RTL-SDR 0.9.25
- Device busy with another program
- Close the program that holds the dongle (SDR#, rtl_tcp, SDR++) and try again.
- Device visible, but no driver is bound — “the dongle has the wrong driver”
- Install the WinUSB driver on “Bulk-In, Interface (Interface 0)” with Zadig. The app drives the dongle with its own driver over WinUSB.
- Device does not support the requested mode on opening
- The dongle has a tuner the driver cannot handle. R820T and R820T2 are supported (checked on an R820T2), as is R828D / Blog V4 (not yet checked on hardware); E4000 and FC0013 are not supported yet.
- “the RTL-SDR stream has stalled for … s: no transfers” or “the RTL-SDR stream broke off”
- Check the cable and press Reconnect.
- The PLL NOT LOCKED badge in the trust bar
- The tuner's synthesiser did not lock at this frequency: the frequency is unreliable, and the spectrum on screen is not from that part of the band. Do not trust the readings while the badge is lit. The same state is shown by the Tuner PLL field in the Source group.
- “the bias-tee may still be on”
- Switching the antenna power off was not confirmed — voltage may be on the connector. Disconnect the antenna or load and reconnect the dongle.
- “the USB reader of the previous stream did not stop”
- Reconnect the dongle; if that does not help, restart the app.
- Yellow lines “USB transfers that came back with an error: N” or “USB transfers of odd length: N” 0.9.36
- Single USB transfers did not arrive whole. The stream is not stopped: there are breaks in their place, no spectrum frame is built across them, and a recording gets a mark. How many samples are missing is shown by Lost in transit. If there are many such transfers, check the cable and the USB port. See RTL-SDR.
tinySA 0.9.25
- “tinySA not found” or “port … does not exist”
- Connect the tinySA with a USB cable; the port should appear in Device Manager as “STMicroelectronics Virtual COM Port”.
- “port … is busy”
- Close tinySA-App or the terminal that holds the port.
- “the device on … is not a tinySA”
- Another device answers on this port. Choose another port in the list.
- “tinySA on … did not answer Enter …”, “… has been sending replies nobody asked for …”, “tinySA answered something other than “…” …”, “… did not name its model …” 0.9.42
- The four connection refusals; each says what the instrument sent 0.9.43. Most often the instrument is still finishing a sweep, the number keypad or a VERSION / TOUCH TEST screen is open on it, or it is still answering the commands of the previous connection. Close such a screen on the instrument, wait a few seconds and connect again. Each one in detail is on the tinySA page.
- “tinySA … does not accept commands: it is still running the previous sweep”
- Wait for the sweep to finish; with a narrow RBW this takes minutes. If there is no sweep on the instrument, close the number keypad or the screen that does not close by itself on it.
- “tinySA did not start the sweep within … s” or “the sweep frame is cut short”
- The RBW may be too narrow for this span: set RBW to auto, narrow the span or reduce the number of points. If the instrument is still running the previous sweep, wait; if USB dropped, reconnect the instrument.
- The spectrum stands still, the tinySA instrument group shows the yellow line “The instrument ended the program's sweep itself …”, the trust bar shows SWEEPS CUT
- Someone is touching the instrument's screen or buttons, and it cuts the app's sweeps. The app sweeps again by itself; the spectrum updates with the first complete sweep. The attenuator, LNA and spurs are unknown after that — choose them in the app again. See Touching the instrument while it works.
- “tinySA has not answered commands for … s after ending a sweep itself”
- The number keypad or a screen that does not close by itself is open on the instrument, or a finger is still on the screen. Close that screen on the instrument and press Reconnect.
- The yellow line “The instrument's screen shows a different band than the program sweeps …” 0.9.43
- Most often the app's span reaches beyond the range of the mode the instrument is in: a tinySA Ultra with Ultra mode off goes up to 800 MHz. Do not take points outside that range for signal levels. See When the instrument's screen shows another band.
- Attenuator windows: “tinySA set the attenuator to … instead of …”, “tinySA holds the attenuator at …: it was changed outside the program”
- With the LNA on the instrument has no manual attenuator; an attenuator changed from the instrument's menu is set again by the app after Reconnect. See What the app knows about the instrument's controls.
- No audio, no IQ recording and no zero span
- This is not a fault: a power analyzer returns levels, not IQ samples, so it has no audio and zero-span groups and no record buttons.
A connection lost while running 0.9.25
- The picture froze, the Device connection lost window
- Cause. USB traffic broke off on a device that was already open. The advice in the window distinguishes two cases: the device is on the bus but traffic with it is failing (cable, port, hub), and the device has disappeared from the bus. Zadig or another program is not the issue here: nobody else can take a device that is already open. What to do. Check the cable and the USB port — preferably without a hub — and press Reconnect in the Source group on the Device tab.
Lost samples and coverage below 100 %
Losses are counted separately at each level, because they are different faults. The counters are on the Device tab; in detail — on the page Trust bar and loss counters.
- Drops in the trust bar is red; Ring buffer (drops) is growing
- Cause. The app did not take the samples from the source ring buffer in time. The early warning is Ring buffer fill above 70 %. What to do. Lower the device sample rate; leave Spectrum from blocks on auto; set Spectrum frames to 30 or 15.
- Lost in transit is above zero
- Cause. Samples are being lost in USB before they reach the app. The driver does not report them, so this is an estimate from the clock; the ring buffer counter shows zero meanwhile. What to do. A lower sample rate, or another USB port with no neighbours on the same controller.
- Coverage below 100 % in the trust bar
- Cause. The machine cannot compute the spectrum from every block of samples, and the app skips some blocks instead of losing samples for everyone. The recording, the audio and zero span get every block, but an event shorter than the gap may not reach the screen. What to do. If you need every block, lower the device sample rate. Spectrum from blocks: all turns skipping off — then, if the machine falls behind, the device ring loses samples.
- Discarded while paused
- Not a fault: these are samples that arrived while the stream was paused. The recording has a gap at that point.
- During a recording Disk fell behind is growing, or Writer queue is above 70 %
- The drive cannot keep up with the stream. 20 MS/s needs a sustained 40 MB/s on drive C:. Lower the sample rate.
Levels and odd peaks
- In a sweep, a red line in the Resolution bandwidth group: “The ADC is saturated in … tunes”
- The levels in those segments are clipping products, not a measurement; false peaks are possible nearby. Reduce the gain or remove the strong signal.
- The noise floor jumps, peaks appear that are not on the air
- This is input overload. On a HackRF One, lower LNA (RF) and switch AMP off — the input amplifier sits before the filters and in a city is easily overloaded by strong nearby transmitters.
- A peak exactly at the centre of the band with the DC mark
- It is a property of the receiver, not a signal on the air. Switch on the DC filter in the Resolution bandwidth group, or move the receive centre if the signal you need sits exactly there.
- The BAND CLIPPED badge
- The VFO band extends beyond the captured one: there are no samples past the capture edge, and that side is not measured. Move the centre or narrow the bandwidth.
- The spectrum is off the edge of the screen, or the waterfall is a single colour
- The level scale does not match the signal. Set Scale: auto 0.9.25 in the Amplitude group, or press A once.
- The dBFS — UNCAL badge
- Not a fault but a reminder: levels from a HackRF One and an RTL-SDR are relative to full scale, not calibrated dBm.
Sweep, recording, audio and transmission at the same time
- No audio during a sweep
- The receiver keeps retuning, so no single frequency can be listened to. Select a span narrower than the device's instantaneous bandwidth.
- A recording made during a sweep has a gap
- While a sweep runs, the recording receives no samples; the gap is marked in the metadata as a sweep outage. If the recording must be continuous, do not start a sweep.
- The Sample rate not changed: recording in progress window 0.9.25
- Every sample of a recording must have the same rate, so the receive band cannot be changed while recording. Stop the recording, then choose the span again.
- The Sweep plan cannot be built window during a recording
- A sweep under a recording runs at the recording's sample rate. Set a larger N, or stop the recording so that the sweep can take a wider rate.
- The Recording stopped: the device sample rate changed window 0.9.25
- The device began delivering samples at another rate; they would have corrupted the file, so the recording was stopped. Everything recorded so far is intact.
- Transmission did not start, No sweep is running, Recording not started: transmission in progress, Sample rate unchanged: transmission in progress
- A HackRF One is half duplex: it either receives or transmits. During a transmission a sweep or a recording cannot be started and the sample rate cannot be changed, and during a sweep a transmission does not start. Stop what is running and repeat the action.
No audio
- The
rawmode is not demodulation: choosenfm,am,wfmor another mode in the Frequency group. - The indicator says squelch closed — the signal is below the Squelch level; lower the threshold.
- The stream is paused (the ⏹ button) — press ▶.
- A sweep or a transmission is running.
- In the FM broadcast band a mode other than
wfmis selected — the app warns about it with a yellow line. - Check Output and Volume in the Audio group.
A recording does not start, or has stopped
- The Could not start recording window
- Most often it reads “… GiB free on disk, at least 2.0 GiB required”: free some space on drive C:.
- A red line: “disk space exhausted — recording stopped; everything recorded so far is intact”
- The app stopped the recording by itself, without waiting for a disk error. Free some space.
- File → Open recording… answers Not implemented
- Switching the source from the main window is not done yet. Restart the app and open the recording with Continue without a device.
Settings and language
- The interface is in the wrong language
- The Language menu (fourth from the left) → Українська or English.
- The Language window: “The translation catalogue did not load; the interface stays Ukrainian”
- The installed app is missing a translation file. Reinstall the app.
- The settings went back to the defaults
- Either the session ended abnormally (the settings are written on closing), or the settings file was damaged — in that case it lies next to the original as
sdrsa.json.broken. See Settings, files and language.
The crash record sdrsa-crash.json
The file sdrsa-crash.json is in the data folder: Documents\SDR Signal Analyzer for the app from the Store, next to the program for the portable build. It appears when the app failed with an unhandled error, did not get OpenGL, could not draw a frame, did not load its interface, or when the spectrum display stopped because of an error 0.9.28. In SDR SA PRO PRO the file is in its own data folder — Documents\SDR SA PRO for the app from the Store — and a failure of a PRO part of the program, reported in a window, is written there too.
- It contains the time, the error text, information about where the app looks for its libraries (with paths on your computer) and the latest Qt warnings.
- There is one file: the next event is written over the previous one.
- The app never sends it anywhere. You may delete it at any time.
- If you write to support@sdrsa.net, attach this file — the decision is yours.
Limits
- The app neither installs nor repairs drivers: you assign WinUSB yourself, with Zadig.
- The advice for USB failures while running, for unconfirmed gains and for the exit from transmit was checked on software mock-ups of the devices, not on live failures.
- The diagnosis “HackRF is visible, but WinUSB is not bound” was derived from the libhackrf sources; it has not been observed on the author's hardware.
- Lost in transit is an estimate from timing, not an exact counter.