Re: [Discuss-gnuradio] GR-Inspector Issues

[Sebastian Müller]

Ogün,

Am 27. April 2018 um 15:27:13, ogün levent (address@hidden) 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 <address@hidden>:

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 <address@hidden> wrote:

Hi Shalom,

Am 5. April 2018 um 11:14:22, Shalom Dubinsky (address@hidden) 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 
address@hidden 
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

address@hidden

PGP ID DC2AA3EE

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio