Re: [Discuss-gnuradio] FFT Header SWIG Issues
Michael, That seems to have done it, thanks! Much appreciated. On Mon, Apr 30, 2018 at 11:06 PM Michael Dickens <michael.dick...@ettus.com> wrote: > Hi Shalom - Something to check / verify: In the top-level CMakeLists.txt > file, when searching for GNU Radio, make sure to include the FFT module, > not just RUNTIME. From the look of the error, libgnuradio-fft is not being > linked into your OOT anywhere. This small tweak should do the trick if this > is indeed the actual issue. Hope this helps! - MLD > > On Mon, Apr 30, 2018, at 3:43 PM, Shalom Dubinsky wrote: > > I'm not very experienced with c++ or with swig, so perhaps I'm missing > something here, but I've got a problem and I can't figure it out. > > I'm trying to replicate the signal_detector block in gr-inspector, and I > can't seem to include the fft header so that swig detects it. I can't find > the difference between my code and the gr-inspector code, either. > > I can reliably reproduce this by: > 1. creating a new module. > 2. creating a new block, with python qa code > 3. including the fft header `#include ` > 4. instantiating an fft_complex object `fft::fft_complex *d_fft = new > fft::fft_complex(1024, true);` > 5. running `make && ctest -V` > > The second test will fail, and the relevant part of the error message is > "ImportError: > /home/reader/code/drones/drone-hacker/gr-mwe/build/lib/libgnuradio-mwe-1.0.0git.so.0.0.0: > undefined symbol: _ZN2gr3fft11fft_complexC1Eibi". > > Declaring the object without instantiating it - `fft::fft_complex *d_fft;` > will work. > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FFT Header SWIG Issues
Hi, I'm not very experienced with c++ or with swig, so perhaps I'm missing something here, but I've got a problem and I can't figure it out. I'm trying to replicate the signal_detector block in gr-inspector, and I can't seem to include the fft header so that swig detects it. I can't find the difference between my code and the gr-inspector code, either. I can reliably reproduce this by: 1. creating a new module. 2. creating a new block, with python qa code 3. including the fft header `#include ` 4. instantiating an fft_complex object `fft::fft_complex *d_fft = new fft::fft_complex(1024, true);` 5. running `make && ctest -V` The second test will fail, and the relevant part of the error message is "ImportError: /home/reader/code/drones/drone-hacker/gr-mwe/build/lib/libgnuradio-mwe-1.0.0git.so.0.0.0: undefined symbol: _ZN2gr3fft11fft_complexC1Eibi". Declaring the object without instantiating it - `fft::fft_complex *d_fft;` will work. Thanks, Shalom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR-Inspector Issues
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 800, 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 ~80 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 > param
[Discuss-gnuradio] GR-Inspector Issues
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 800, 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 ~80 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: * What is the relationship between sampling rate and signal detection accuracy? * What is the relationship between fft length and sampling rate? Is it related to signal detection accuracy? * Why does it sometimes report signals with negative frequencies? * Why does it sometimes seem to report a frequency delta? * Is there anything else I'm missing about this module? I've attached the gr-inspector example signal-detection .grc as well as the modified .grcs mentioned earlier. Thank you, Shalom Dubinsky signal_detection_ghz.grc Description: application/gnuradio-grc signal_detection.grc Description: application/gnuradio-grc live_signal_detection.grc Description: application/gnuradio-grc signal_detection_usrp.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
