iq_client --fft additional parameters about rs HOT 7 CLOSED

additionally I should say that power scanning with the iq_server is waaay too expensive so I had to switch back to my own csdr based solution. I do averaging over 5 seconds but I only do 100 measurements within this time period. Additionally I only do 4096 bins fft.

from rs.

The FFT threads keeps reading IQ-data after finishing the FFT, because when reading live data from rtl_sdr, I didn't want the buffers to fill up if there is no other (decoder) thread running, someone has to pick up the incoming data. If there is no other thread, probably the reading is faster than the rtl_sdr, but the loop that waits for more data still consumes cpu. I will look at it again. If there is a decoder thread running, the FFT thread could be stopped or put to sleep, and every x minutes a new scan for 2 seconds could be made.
Bin size of approx 200 Hz is needed for accurate peak location.

from rs.

Before I was only testing on my old laptop, it is slow enough. Now on my desktop the FFT doesn't matter, so I don't know if it is worth the effort... Maybe I have to check the raspi3.

@flux242
What hardware are you testing on?

from rs.

that additional thread that just eats input stream if no fft client connected doesn't bother me actually because it doesn't consume much. I was doing

while true; do iq_client --fft /dev/stdout; done | processing_scan_result

and that would consume one core 100%. The question is how do you perform fft? Is it similar to what csdr does? https://github.com/ha7ilm/csdr#fft_cc

from rs.

I guess the algorithm is ok. Maybe (with older compilers?) the complex-float calculations are not as fast as optimized versions, for me it is fast enough.
However with 2Msps it averages approx 250 FFTs (continuously doing FFT) in 2 sec. That is probably not necessary, a FFT every 1/20 sec would be enough, i.e. averaging 40 FFTs in 2 sec.
On faster computers you don't see the difference, but on a raspi that would be noticeable, I guess.
I did not have in mind doing permanent FFTs in a while-loop, though.

Ok, I changed it such that FFT_SEC*FFT_FPS=2*20 FFTs are made, not depending on the sample rate, that should reduce computations for higher sample rates. No further smoothing, that's up to post-processing/peak-detection.

Remark:
For RS41 and more so for M10 the signal is reduced of course, for a weak M10 signal the threshold should be a little lower.

from rs.

well it would be better of course if I didn't have to use the loop and the client would stay connected delivering the fft results constantly (i.e once in 2 seconds)

another question is how much data should be transferred to the client. Shouldn't it be enough to transfer only the measurement results? It's clear that it's from -0.5 to 0.5 and I also do know what sampling rate is used, so no need for the 2nd column too imo

from rs.

Yes, when saved to a file, there was additional (debug) data.
I removed the frequency/Hz and put the sample rate in a header line.
There is the option --fft0to save the client FFT request at the server location, no TCP, though it has a fixed default filename.

from rs.