Sebastian, Thanks for responding! I've been through the code, and I see what you mean now by "complex baseband". However, it looks like you're assuming the carrier frequency is the sample rate. Is that something I should be trying to maintain throughout my project?
I also think I found a minor bug? In the build_threshold method, where you have `i` going up to `d_fft_len` but access `i + 1`. Thanks for your help, Shalom On Thu, Apr 5, 2018 at 6:57 PM Sebastian Müller <gse...@gmail.com> wrote: > Hi Shalom, > > Am 5. April 2018 um 11:14:22, Shalom Dubinsky (smdubin...@gmail.com) > schrieb: > > > Hello, > > My name is Shalom Dubinsky, and I'm having some trouble with the > gr-inspector module. I'm trying to use it to detect signals in the 2.4ghz > range, and I can't get reliable responses from it. Information on it seems > scarce, so I'm asking here. > > First, I tried playing with the default example of 3 cosine waves all > summed with a noise source and run through the Signal Detector block. This > works as expected - both the GUI Inspector sink and the message debug > output match. However, if I increase the sample rate too much it loses any > accuracy it had. Specifically, a sample rate of 4M only picks up two > signals, and a sample rate of 40M only picks up one signal. The error is > much higher in both of them, up to several hundred hz. Decreasing it to > 20k gives me two reasonably accurate signals and one garbage signal. > > I also tried building my own graph. I ran a single cosine wave > broadcasting at 200M through a noise generator, the signal detector block, > and the GUI Inspector block. The sample rate was consistent throughout the > graph, and the FFT length was set to 4096 across the board. The center > frequency of the inspector sink was set at 200M. The messages reported the > signal to be at 8000000, while the graph displayed it as 208Mhz. Dropping > the cosine frequency to 800k allowed the signal detector to work more or > less correctly, but I had to change the center frequency of the inspector > sink to 0 for it to display the signal correctly. The problem at 800k was > that the messages would alternate between ~800000 and ~-10183594. This > isn't the only time I saw negative frequencies, either. > > I next tried attaching it to a real radio. When I broadcast a signal(from > a different radio) at 2.425ghz, it detected that a signal was being > broadcast, meaning it only reported something when I broadcast a signal, > but did not accurately detect the signal frequency. Instead, it would > bounce around detecting different frequencies. > > Questions: > > Generally I’d like to point to the official documentation [1]. > > > * What is the relationship between sampling rate and signal detection > accuracy? > > As described in the docs, the bandwidth of the signal is quantized with > the block parameter ‚Rel. quantization‘. > > This avoids high message load because of noise that slightly changes the > detection boundries. > > The quantization is relative to the used sample frequency. More info can > be found in the docs and the code. > > > * What is the relationship between fft length and sampling rate? Is it > related to signal detection accuracy? > > Definitely. One FFT bin covers samp_rate/fft_length Hz. This is the > maximum resolution > > you can get for estimating the signal parameters and highly affects your > accuracy. > > In other words: there is a trade-off between bandwidth and resolution. > > > * Why does it sometimes report signals with negative frequencies? > > The frequencies are reported in *complex baseband*. Please research what > that means, > > but in a nutshell the frequencies are relative to the carrier frequency. > This is intended behaviour. > > > * Why does it sometimes seem to report a frequency delta? > > I’m not sure what you mean by that. The message format is (center_freq, > bandwidth). > > > * Is there anything else I'm missing about this module? > > If you’re just planning to detect signals, you might be better extending > the > > gr-inspector detection block or write your own. The algorithm used is very > basic > > and only works well for steep signal flanks. Depending on the kind of > signals you plan > > to detect you probably want to use a different algorithm. I tried to > communicate that in > > my blog [2]. > > > > I've attached the gr-inspector example signal-detection .grc as well as > the modified .grcs mentioned earlier. > > Also I’ve seen you mostly use the default parameters in the flowgraphs for > your > > application, which most likely won’t work. You need to understand the > parameters and > > sensibly choose them if you want the software to behave like you want. > > > Thank you, > > Shalom Dubinsky > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > [1] http://gnuradio.github.io/gr-inspector/ > [2] https://grinspector.wordpress.com/2016/06/26/week-5-midterms/ > > Regards, > > Sebastian Müller > gse...@gmail.com > PGP ID DC2AA3EE > <http://pgp.mit.edu/pks/lookup?op=vindex&search=0x9FFBD55DDC2AA3EE> > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
