Wiki › Reference

Performance

How much CPU the app takes, what the Host group shows, and what to do when the computer cannot keep up with the stream of samples. The main rule: the app does not degrade silently. If the spectrum was computed from less than all of the air, it states the share as a number; if samples were lost, it shows at which level.

Measured load

The numbers below were measured on a live window with a HackRF One: an i7-13650HX processor, a 144 Hz display, N 4096. They are a share of one core, summed over all the app's threads — the interface with rendering, the signal processing and the graphics driver thread.

On another processor the numbers will differ, but the relation is the same: the load grows with the sample rate, because the FFT is computed from every sample. Your own computer's numbers are shown in the Host group.

The Host group

The Host group is on the Device tab, below the source and recording groups. It holds two selectors and a set of readouts:

panel fps

The animation rate of the side panel itself — the smoothness of the interface. Green from 59, amber from 45, red below. The counter runs only while the group is visible on screen.

ms/frame

The same rate in milliseconds per frame.

spectrum frames/s

How many frames of the spectrum and waterfall were actually drawn per second. This is a different number from panel fps, and the two should not be confused.

Spectrum frames

The cap on the redraw rate: 60, 30 or 15 — see below.

Spectrum from blocks

Which blocks of samples the spectrum is computed from — see below.

Spectrum coverage

The share of air time the spectrum was really computed from, in per cent, and the current skipping step. Green at 100 %, amber otherwise.

rows/s and spectra/s

How many waterfall rows were produced per second and how many spectra were computed.

DSP, cores

How much of one core's time the signal processing thread takes, in per cent. Green up to 60 %, amber beyond.

History

live when the waterfall shows the live air, or a negative number of rows by which it is scrolled back.

The two small lines at the bottom of the group are the OpenGL version with the name of the graphics card, and the library the FFT is computed with.

Spectrum frames: 60, 30 or 15

The Spectrum frames selector sets how many times a second the spectrum and the waterfall are redrawn because of new data. The default is 60. A lower cap loses nothing: waterfall rows land in the same frame as a batch, and mouse actions are drawn at once under any cap.

30 or 15 is for a weak machine: less CPU and graphics driver work spent on the picture. Measured at 20 MS/s with a cap of 30: the interface thread 19 → 15 % of a core, the driver thread 9 → 5 %. The choice is remembered between launches.

Spectrum from blocks, and coverage

The spectrum is the most expensive part of the processing: an FFT of every sample, the folds, the traces. Recording and audio are cheap. So when the machine cannot keep up, the app can compute the spectrum from fewer than all blocks of samples, while the recording, the audio and the zero span envelope still get every block. That is better than an overflowing device ring, which loses samples for everyone at once.

auto

The default. The spectrum is computed from all blocks while the processing fits into air time. When it takes more than 80 % of that time for two reviews in a row — or at once, if the device ring is already a quarter full — the app skips as much as is needed. The skipping step never exceeds 16, so the spectrum is computed from at least 1/16 of the air time; only the ring-overflow guard (see below) takes the coverage lower. When the machine keeps up again, the skipping decreases by itself.

all

Always every block. If the machine falls behind, the device ring loses samples, and that shows in the Drops counter.

every 2nd, every 4th, every 8th

Forced skipping. "Every n-th" means 1/n of the air time, not of the number of blocks.

The price is stated honestly: an event shorter than the gap may not reach the screen. The share of time the spectrum was really computed from stands in the trust bar, in the Coverage field, whenever it is below 100 %, and always in the Spectrum coverage field of the Host group. Explanations appear there as well:

• 1/… of the time — the current skipping step;
• skipping impossible: the frame is longer than half a block — N is so large that an FFT frame is assembled from several blocks, and a skipped block would tear every frame;
• the device ring is filling up — catching up — in the auto mode the ring is more than half full, and blocks are skipped regardless of the step so that no samples are lost.

What happens to the rest of the picture meanwhile:

• The waterfall keeps its set pace in wall time: there are no fewer rows per second, each simply contains fewer spectra.
• The weighted detectors qp, cav and crms freeze during a gap: their time constants run on processed time.
• There is no skipping in a sweep.

The drive for recording

A recording writes the device's own sample format without compression — two bytes per sample. For a HackRF One at 20 MS/s that is 40 MB/s: ten minutes take 24.26 GB, with zero losses on a drive that keeps up (measured). For an RTL-SDR 0.9.25 at 2.56 MS/s it is about 5 MB/s. The speed needed at the current sample rate is given in the tooltip of the Format field in the Record group.

What matters is the sustained speed, not the peak one. On the author's machine a DRAM-less NVMe drive held 1443 MB/s until its fast cache ran out and then fell to 8.6–20 MB/s, with single writes taking 23 s — and a ten-minute recording at 20 MS/s lost 1.17 billion samples there. Drive C: wrote the same 24 GB without a single drop, with the longest write at 3.05 ms. That is why the recording folder is C:\sdrsa-rec, and it cannot be changed in this version.

While recording, watch the Writer queue field: a growing queue means the disk is not keeping up. What has already been lost because of the disk is counted by Disk fell behind. More on the pages IQ recording and Trust bar and loss counters.

A minimised or covered window 0.9.30

Windows decides by itself how important a process is, and it may give less to a program whose window is minimised: move its threads to the power-saving cores and ignore its requests for a fine timer tick. For an instrument that is receiving at that moment, this would mean lost samples.

That is why, while the source is running and not paused, the app forbids Windows to slow it down, and a minimised or covered window does not hold the app back. On pause and after a stop the decision returns to the system. The price: a minimised app that is receiving uses as much as a visible one — noticeable on battery. An "Efficiency mode" switched on for the app in Task Manager is not overridden: it stays as it was.

Graphics card and OpenGL

The spectrum and the waterfall are drawn by the graphics card through OpenGL 3.3, and this is a hard requirement. If the graphics driver does not provide it, the app shows the dialog OpenGL unavailable with the reason: the rest of the app works, but there will be no picture. Updating the graphics driver usually helps; in a virtual machine, enable 3D acceleration. Which OpenGL version and which graphics card the app received is shown in the small line at the bottom of the Host group.

Tips for a weak machine

• Lower the instrument sample rate. This is the most effective step: in the measurement above 2 MS/s costs almost three times less than 20 MS/s. Take as much bandwidth as the task needs.
• Set Spectrum frames to 30 or 15. The measurement does not suffer.
• Leave Spectrum from blocks on auto and watch Coverage in the trust bar. If it stays far from 100 %, the machine cannot handle this sample rate.
• Do not keep the Device tab open needlessly. While the Host group is visible, its frame counter makes the side panel redraw on every screen frame.
• Be careful with the qp detector. Quasi-peak is the heaviest of the detectors: about half a core at 20 MS/s.
• FPV video is a separate load. The decoder runs in its own thread and, when it cannot keep up, drops blocks and says how many; for colour the practical choice is 16 MS/s. See FPV video.
• If Lost in transit is growing, the problem is not the CPU but USB: try a lower sample rate or another port with no neighbours on the same controller.

Limits

• The load numbers were measured on one machine with one device; they are a guide, not a guarantee.
• The FFT is computed on the CPU; the graphics card only draws the spectrum and the waterfall.
• Block skipping saves the recording and the audio, not the picture: at low coverage short events do not reach the screen.
• Without OpenGL 3.3 there is no spectrum and no waterfall at all.
• The recording folder cannot be changed: for 20 MS/s drive C: must sustain 40 MB/s and have tens of gigabytes free.

The wiki describes version 0.9.49. Your app's version is shown in the Help menu, under About. Found a mistake? Write to us.