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

Hi all,

my GSoC update came a bit later this week, because I was abroad. The GUI came to life this week, read here about it:

https://grinspector.wordpress.com/2016/06/18/week-4-gui/

Cheers,

Sebastian

Am 10. Juni 2016 um 15:14:24, Sebastian Müller (address@hidden) schrieb:

Hi all,

like every week I want to give a short update about my GSoC project. For details, check the blog post at

https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/

Most of the week was used to debug the Signal Separator block, which did not pass my QA test. In consultation with my mentors I changed the structure under the hood and now the behavior is exactly like expected (same as Xlating FIR filter). Also I improved the Signal Detector with callbacks and an averaging function and started with the GUI.

Cheers,

Sebastian

2016-06-03 18:49 GMT+02:00 Sebastian Müller <address@hidden>:

Hi All,

the second GSoC week is over and I have updated my blog with the latest news:

https://grinspector.wordpress.com/2016/06/03/week-2-compiling/

Mainly I did C++ implementation of the Signal Detector and Signal Separator blocks and started with the Signal Extractor block. Next week I plan to improve these blocks and start with the GUI.

Cheers,

Sebastian

Am 28. Mai 2016 um 14:55:45, Sebastian Müller (address@hidden) schrieb:

Hi Jan,

thanks for the feedback!

PFBs are a topic I discussed with my mentors and we decided to not use them because of the following reasons. When using PFBs, there is a trade-off between band resolution and calculation effort (few filters lead to low number of possible frequency bands, many filters may have a high cpu usage). Since the band separation is not dependend on the input siganls, I think I can have a more efficient solution with „customized“ FIR filters for each signal. The second reason is the implementation effort that needs to be done (not only for the PFB but also for recombining the bands again to reconstruct the signals) is quite higher than for using FIR filters. We were afraid that time would be too short for implementing this (since all this should work until the midterms in four weeks).

We assume to have a moderate number of signals in the input spectrum (let’s say less than 5) and I think the FIR filter approach is more attractive here. But of course cpu usage is a topic which I have to deal with. Therefore I plan to use a lookup-table with precalculated taps for different bandwidths and steepnesses. Also, steepness (or something similiar) should be a parameter of the block, so the user can can somehow control the cpu usage with that.

I hope that answers your question!

Regards,

Sebastian

Am 28. Mai 2016 um 12:45:49, Jan Krämer (address@hidden) schrieb:

Hey Sebastian,

great work in your first week. Looking pretty good.
One question though. At the end you propose to seperate the signals with a filterbank of xlating FIRs. Is there a use case or a way to do that with a polyphase filterbank? Cause multiple FIRs are going to become a major burden for the CPU if their number rises, especially if the filterorder gets pretty high e.g. for narrowband signals.

Anyway keep up the good work.

Cheers,

Jan

2016-05-27 14:51 GMT+02:00 Sebastian Müller <address@hidden>:

Hi all,

there is a new blog post concerning the gr-inspector toolbox:

https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/

There I describe what I have done in my first week of GSoC. Mainly I have prototyped a signal detection block and started planning the signal separator block (which is used to pass the detected signals serialized).

As always, comments are very welcome :)

Cheers,

Sebastian

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

From:	Sebastian Müller
Subject:	Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback
Date:	Sun, 26 Jun 2016 13:10:57 -0400