charlie-foxtrot / RTLSDR-Airband

Multichannel AM/NFM demodulator
GNU General Public License v3.0
759 stars 135 forks source link

Support for negative gain values #126

Closed fr0sty1 closed 5 years ago

fr0sty1 commented 5 years ago

rtl_power reports the following gain values:

Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U Found Fitipower FC0012 tuner Supported gain values (5): -9.9 -4.0 7.1 17.9 19.2

The config file only supports values >= 0 so my lowest gain option is 7.1 which appears to be way too hot:

261/ 98*  273/ 97*  308/ 98*  318/370   268/ 97*  276/ 98*  271/ 97   236/ 97   266/ 97*  287/ 98*  335/350*  287/350   275/ 97*  269/ 97*  253/ 98  
 246/ 98*  263/ 97*  293/ 98*  323/370   259/ 97*  281/ 98*  266/ 97   236/ 97   249/ 98*  280/ 98*  323/350*  293/350   263/ 97*  279/ 97*  262/ 98  
 263/ 98*  271/ 97*  301/ 98*  344/370   286/ 97*  280/ 98*  251/ 97   252/ 97   261/ 98*  276/ 98*  329/350*  298/350   281/ 97*  256/ 97*  256/ 98  
 273/ 98*  276/ 97*  300/ 98*  327/370   280/ 97*  284/ 98*  262/ 97   273/ 97   275/ 98*  287/ 98*  337/350*  293/350   282/ 98*  266/ 97*  261/ 98  
 274/ 98*  282/ 97*  298/ 98*  347/370   286/ 97*  292/ 98*  260/ 97   257/ 97   278/ 98*  292/ 98*  328/350*  310/350   277/ 98*  277/ 97*  263/ 98  
 261/ 98*  269/ 97*  297/ 98*  353/370   285/ 97*  274/ 98*  260/ 97   247/ 97   254/ 98*  279/ 98*  338/350*  300/350   269/ 98*  261/ 97*  258/ 98  

Is there a reason that the config parsing forces the values to be >=0 rather than just snapping to the nearest suitable value?

Also, are those numbers sensible? They seem quite high.

I am running 3.0.1 on a Raspberry pi 3 B

szpajder commented 5 years ago

Is there a reason that the config parsing forces the values to be >=0 rather than just snapping to the nearest suitable value?

The only reason is that so far I haven't come across a dongle which allows negative gains :) (AFAIR, I had already seen a few FC0012-based ones, but they didn't have that feature).

Also, are those numbers sensible? They seem quite high.

Indeed, they are high.

Please pull the latest unstable branch, it allows negative gain values in the config.

fr0sty1 commented 5 years ago

With the latest patch I think a negative gain value would still cause problems because ngain would be less than zero here:

int ngain = rtlsdr_nearest_gain(rtl, dev_data->gain);
    if(ngain < 0) {
        log(LOG_ERR, "Failed to read supported gain list for device #%d: error %d\n", dev_data->index, ngain);
        error();
}

In fact I can confirm this is the case because selecting a gain value of 0 or 1 (which rounds down to -4) causes rtl-airband to exit immediately while choosing 2 or higher (which rounds up to 7.1) works fine.

szpajder commented 5 years ago

Yep, absolutely right. Please try the current unstable, should work better now.

fr0sty1 commented 5 years ago

I can specify negative gain with unstable. signals look a little better

 101/ 89   103/ 89   101/ 89    97/ 88   102/ 90   107/ 89   112/ 89   108/ 89   100/ 87    97/ 88   102/ 89   101/ 88   109/ 89   103/ 89   110/ 89  
 106/ 89   103/ 89   104/ 89   105/ 88    95/ 90   101/ 89   110/ 89    99/ 89   101/ 87    98/ 88   105/ 89   103/ 88    99/ 89    96/ 89   108/ 89  
 101/ 89    97/ 89   105/ 89    97/ 88   100/ 90   104/ 89   106/ 89   107/ 89   105/ 88    95/ 88   105/ 89   101/ 88   104/ 89   108/ 89   108/ 89  

I get these compile warnings on RaspberryPi:

gpu_fft_base.c: In function ‘unsigned int gpu_fft_base_exec_direct(GPU_FFT_BASE*, int)’:
gpu_fft_base.c:65:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
     for (q=0; q<num_qpus; q++) { // Launch shader(s)
               ~^~~~~~~~~
gpu_fft_base.c:72:50: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
         if (((base->peri[V3D_SRQCS]>>16) & 0xff) == num_qpus) break; // All done?
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
gpu_fft_base.c:54:17: warning: unused variable ‘t’ [-Wunused-variable]
     unsigned q, t;
fr0sty1 commented 5 years ago

I am using NFM demodulation, 1.6M bandwidth and 256FFT buckets. Would that make an difference to the measured noise?

szpajder commented 5 years ago

These compilation warnings are harmless.

Numbers still look a little high, but it's not about the numbers, after all. Does it sound OK or not?

fr0sty1 commented 5 years ago

Was able to listen to a little bit of traffic and receive sounded good. Thanks for your help!

fr0sty1 commented 5 years ago

Numbers still look a little high, but it's not about the numbers, after all. Does it sound OK or not?

I played around with my gain/samplerate settings some more and the noise-floor eventually dropped to ~20. I originally thought this was related to the new sample rate I chose (2.88Ms/sec) but I was able to change back to 1.6Ms/s and keep the better noise number so there appears to be something strange about the internal state of the device that can be resolved by manipulation of the gain/samplerate. Unfortunately this problem hasn't occurred often enough for me to detect any sort of pattern.