[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] Signal level calibration and Linrad-01.14
- Subject: [linrad] Signal level calibration and Linrad-01.14
- From: Leif Asbrink <leif.asbrink@xxxxxxxxxxxxxxxxxxxx
- Date: Thu, 12 Feb 2004 21:18:14 +0100
Hi all,
Werner, DL2JA reported problems with 01-13 running slowly
on his computer. The problem seems to be caused by the
Linux kernel swapping some parts of RAM that 01-13 fails to
lock. This is stupid, of course - by locking most of the
memory used by Linrad but not all of it, the kernel will
not swap the infrequently used memory areas, it has to swap
those that are not locked and they happen to be used rather
frequently.
Linrad-01.14 locks all of the memory in use. It is done
with a call to mlockall() in the idle routine which is
guaranteed to be executed now and then. In case swapping
occurs it will not last long.
Werner also has a question that might be of general interest:
> One more question, in my configuration is the signal level in the fft3
> window approx 5dB higher than in the fft1/2 windows, is this due to
> noise/qrn or is my audio level setting not correct?
No. This is a bug in Linrad.
The calibration factor that has to be used in each window
is a complicated expression that depends on a large number
of parameters. The fourier transforms (there are many different
implementations) have different gain. They are designed for speed
and there is no reason to make them all produce the same output
level. There is a routine that finds out exactly which routines
are in use. At program start this routine computes the calibration
factors that are used when pixels are set on the screen. It is
possible that there are still some error for some particular
parameter combinations.
The calibration is intended to give the same reading for a
perfect sinewave in all windows. The noise floor will of
course not be at the same level in the different windows
because the noise floor depends on the bandwidth which is
typically different in different windows.
Until the error is fixed (low priority) you should not compare
dB values from different windows unless you measure the difference
in zero point that may be present by looking at the same signal
in both windows.
73
Leif
LINRADDARNIL