[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

From: Sebastian Müller
Subject: Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback
Date: Thu, 26 May 2016 11:38:48 +0200

Hi Ben,

thank you for your interest and feedback!

To your first question: The desired behaviour of the signal detector would be to recognize a multi-carrier system (like OFDM) as one signal, since all the carriers are needed to transmit the information. If the frequency resolution is very fine, as you mentioned, the problem occurs that different subcarriers get interpreted as different signals since low-energy bins occur between them.
To be honest, a software will not be able to distinguish between two close incoherent signals and two subcarriers in a multi-carrier system, unless additional information is provided. One way to do this is to do further analysis of the signals and determine wether they "belong together", but I'm afraid this is much more work than I can do during the GSoC program. Another way would be to set a minimum absolute frequency spacing, under which the signals get interpreted as one. But I really don't want to hard-code any values in order to maintain maximum versatility of the inspector.
So, to come to an actual answer, at this point the user has to find out by himself for now. For this reason it will be possible to select the signals manually in the GUI and select what gets mixed down and filtered for the succeeding signal chain.

Your second question targets the waterfall ability of the toolbox. The idea is (if time allows) to use a waterfall plot instead of a spectrum plot in order to be able to analyze signals from the past (imagine the waterfall plot with red rectangles where signals were detected). This can become handy if signals are only present for a short time. In this case, an observation will be characterized by frequency band and start/stop time, instead of only frequency band as it is for now. If such a burst signal is detected, it will be filtered by the Signal Separator and will be stored until it disappears from the waterfall plot, so it will be analyzable for a much longer time period.
Nevertheless the inspector will of course be able to work on file sources with manually recorded signals.

I hope I could provide sufficient answers to your questions!

Also, I want to encourage the whole community to give feedback, especially on the mentioned questions at the end of the blog post:

Stay tuned for this week's blog post (likely on friday).


2016-05-25 16:19 GMT+02:00 Ben Hilburn <address@hidden>:
Hi Sebastian -

Thanks so much for the great update! I have two questions:

You mentioned in your blog post that all adjacent bins will be interpreted as one signal in your detection block, which then gets passed downstream to the analysis portion of your design. Can you comment on how this might be affected by multi-carrier systems, especially if the user has selected a bin count high enough to push apart the carriers?

You also mentioned the ability to analyze past signals in a waterfall plot. In this workflow, would you basically be playing back a recorded file and doing off-line analysis?

It looks like things are coming along really nicely. Great mock-ups, by the way!


On Fri, May 20, 2016 at 6:31 AM, Sebastian Müller <address@hidden> wrote:
Hey list,

there are some news regarding the gr-inspector toolbox, please check out my blog if you’re interested:

The strategy for the first big task, signal detection, is nearly finished thanks to the great feedback from my mentors. But still, there are some questions remaining on which I would love to get feedback from the community. The explicit questions are at the end of the newest blog post.

Beginning with the coding period on monday, weekly updates will be published on the blog along with a short mail on the list. Stay tuned!


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]