Re: Constant baseline between FFTs

[Kimmo Lehtinen]

I think that in your Python block, 'input_items[0]' is a list of lists, so it is like

[ [spectrum_1], [spectrum_2],...,[spectrum_n] ]

and the number of spectra in the list is different for each run of the Python block.

In general, if having a list of lists like

>myList=[ [1,2,3], [4,5,6] ]

then using Numpy's median-command gives

>numpy.median(myList)

3.5

just a scalar, but you want a median value for each of the spectra.

You can do it by using

>numpy.median(myList, axis=1)
array([2., 5.])

Then you have to find out how to divide a list of lists with a Numpy array     

(you cannot simply divide myList with the numpy array)

Also, the following for-loop should work:

for i in range(len(input_items[0])):

    output_items[0][i] = input_items[0][i] / np.median(input_items[0][i])

Cheers, Kimmo

lauantaina 30. joulukuuta 2023 klo 15.57.20 UTC+2 Dr Cdiff <drcdiff@gmail.com> kirjoitti:

Am Sa., 30. Dez. 2023 um 10:39 Uhr schrieb Fons Adriaensen <fons@linuxaudio.org>:

On Sat, Dec 30, 2023 at 08:20:28AM +0100, Dr Cdiff wrote:

> I have complex data in a file sink. I do File Source, Throttle, Stream to
> Vector, FFT, Multiply Conjugate,

So then the real part is magnitude squared. So why

>  Complex to Mag²

which results in magnitude^4 and not "select real part" ?

Insufficient knowledge. ;-)

Replaced it with Complex to Mag.

 

> I can handle the problem by dividing by the median of every FFT.

If by 'moving baseline' you mean that the gain of the process seems to
be different in each iteration, then "dividing by median" is the *cause*
the problem. Just don't do it, and you will have constant gain.

Here is an example (without division by median!): https://ibb.co/FmxZ3ZK (x is time in h and y is frequency in weird unit)

The gain is probably the root of my problem. I am using a SDRPlay RSP1a. When I deactivate the AGC, the gain seems not to be fixed entirely AND no AGC slows down the flowgraph (yes, that is weird). That is why I had AGC on in this case. For the newer SDRPlay devices there is only a weird proprietary driver ...

 

If you mean that the low level bins of your spectrum seem random,
that is because those are probably noise. To measure this you need
to average the power over time.

The low level bins show noise. I use real world data. The noise is random (of course), but that is not a problem.

When you look at my results without division by median (https://ibb.co/FmxZ3ZK), most of the time (most columns) I have 7 peaks (the signals I want to measure) in an ocean of noise. But at some points of time in the middle and between 16h and 22h the noise floor is higher. That is what I want to fix.

 

If you mean that e.g. a constant level sine wave appears not to be
constant in the output, that may be because you don't window before
the FFT.

No. I use window.blackmanharris(FFT_size).

 

If you want some form of 'automatic gain control' then you could
use the total power (sum over the mag^2 vector) and average this
over time before dividing by it. Certainly not the median.

I have a really small bandwidth here. When I have no signal at a time, AGC with total gain would increase the noise. The aim of using the median was to divide by the noise floor to be independent from the signals.

Here the same figure but divided by the median in GNURadio (everytime I run the flow graph it looks slightly different (vertical lines on different places)): https://ibb.co/pfYyr0r

Here is the same figure but divided by the median later in python (looks clean and always the same): https://ibb.co/gRsBDVd