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 <gse...@gmail.com>: > 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 (gse...@gmail.com) 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 (kraemer...@gmail.com) 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 <gse...@gmail.com>: > >> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
