Ogün, Am 27. April 2018 um 15:27:13, ogün levent ([email protected]) schrieb:
Hello, I also have few problems with gr-inspector. It was working without any problem until gateware change of the limesdr now gateware issue resolved but I see a dc offset on qt sink and also Real time scheduling is not working. The DC offset has nothing to do with gr-inspector. I have never used a LimeSDR but it’s a rather affordable SDR and therefore don’t expect superior signal quality, including a remaining DC offset. You can cancel the offset yourself by doing signal processing. At the initial start some signals are spitting out at the terminal and sometimes detected signals have zero bandwidth shown inside the tuples. Correct me if I am wrong we are supposed to see complex baseband signals which are supposed to have bandwidth more than 0Hz? This depends on your block settings. Since you don’t provide which flowgraph or which blocks you are using, I can’t make a statement on if this is intended behaviour or not. Final problem is the even the samp rate is at its max value I still see aliasing. Also here, „max samp rate“ does not guarantee you don’t have aliasing. What do you see and why do you think it is aliasing? Why do you think there shouldn’t be aliasing? What are your parameters? I, again, assume this is just a hardware effect with mirroring frequencies due to the affordable SDR hardware. On qt gui marker shows the exact values of the tuple but on the terminal we see different values why? Again please provide more information on the flowgraph, blocks an parameters used. There is no way anybody can answer that question with the information you provide. Best. Regards, Sebastian 2018-04-18 8:16 GMT+03:00 Shalom Dubinsky <[email protected]>: > 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 <[email protected]> wrote: > >> Hi Shalom, >> >> Am 5. April 2018 um 11:14:22, Shalom Dubinsky ([email protected]) >> 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 >> [email protected] >> 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 >> [email protected] >> PGP ID DC2AA3EE >> <http://pgp.mit.edu/pks/lookup?op=vindex&search=0x9FFBD55DDC2AA3EE> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
