|
From: | Sebastian Müller |
Subject: | Re: [Discuss-gnuradio] GR-Inspector Issues |
Date: | Thu, 5 Apr 2018 17:55:36 +0200 |
Hi Shalom, Am 5. April 2018 um 11:14:22, Shalom Dubinsky (address@hidden) schrieb:
Generally I’d like to point to the official documentation [1].
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.
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.
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.
I’m not sure what you mean by that. The message format is (center_freq, bandwidth).
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].
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.
[1] http://gnuradio.github.io/gr-inspector/ [2] https://grinspector.wordpress.com/2016/06/26/week-5-midterms/ |
signature.asc
Description: Message signed with OpenPGP using AMPGpg
[Prev in Thread] | Current Thread | [Next in Thread] |