Closed fr0sty1 closed 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.
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.
Yep, absolutely right. Please try the current unstable, should work better now.
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;
I am using NFM demodulation, 1.6M bandwidth and 256FFT buckets. Would that make an difference to the measured noise?
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?
Was able to listen to a little bit of traffic and receive sounded good. Thanks for your help!
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.
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:
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