Hi Martin, I have no problem with keeping the 'old' algo in the toolbox. But still I'm not sure if it is usable in real-world scenarios with sampling offsets. Maybe someone can improve it if interested.
Cheers, Sebastian 2016-07-15 19:22 GMT+02:00 Martin Braun <martin.br...@ettus.com>: > To clarify, if Koslowski's algorithm (since you already coined the > term...) is *as* good as your original one, but also faster, you should > not have duplicates. But if you did all the work to create software that > actually outperforms the fast algorithm in some other aspect, there's no > harm in keeping it around. > > Cheers, > M > > On 07/15/2016 10:20 AM, Martin Braun wrote: > > Sebastian, > > > > thanks for sharing, and your awesome work! I would suggest if you have > > an algorithm with great detection characteristics, you should keep it. > > If you want another suboptimal but fast one, create a second block (or > > whatever it is). The first algorithm did cost you time, and its superior > > detection performance might be interesting to other people. > > > > Cheers, > > Martin > > > > On 07/15/2016 08:10 AM, Sebastian Müller wrote: > >> Hi list, > >> > >> week 8 of GSoC is over and the latest news on gr-inspector are online: > >> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/ > >> > >> This week was a bit disappointing because the algorithm for the OFDM > >> estimation, which did show nice estimation results, and which I dealt > >> with 2 weeks now, had to be replaced because of performance issues. Now > >> I'll try a more straight-forward algorithm and hope to get started with > >> synchronization in two weeks. > >> > >> Cheers, > >> Sebastian > >> > >> Sebastian Müller <gse...@gmail.com <mailto:gse...@gmail.com>> schrieb > am > >> Fr., 8. Juli 2016 um 13:48 Uhr: > >> > >> Hi all, > >> > >> week 7 of GSoC is over and I have written a blog post about what > >> I've been up to: > >> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/ > >> > >> I started implementing an OFDM parameter estimation block in python. > >> Also, I did some performance tests, which look quite good. Next, I > >> will implement this algorithm in C++. Stay tuned! > >> > >> Cheers, > >> Sebastian > >> > >> Am 01.07.2016 um 15:37 schrieb Sebastian Müller: > >>> Hi all, > >>> > >>> this week's GSoC blog post is ready! Check it out here: > >>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/ > >>> > >>> I have finished the GUI so far and improved the Signal Separator. > >>> In the next time I will start with an OFDM parameter estimation, > >>> so stay tuned. > >>> > >>> Cheers, > >>> Sebastian > >>> > >>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com > >>> <mailto:gse...@gmail.com>>: > >>> > >>> Hi Ben, > >>> > >>> thanks for your interest. The manual signal selection is like > >>> the demod function in gqrx. You can move and resize an overlay > >>> that will determine the signal information that gets passed > >>> downstream. I have not dealt with AMC for now, but based on my > >>> own experience with manual modulation recognition I don't see > >>> a problem when not exactly hitting the signal edges. If your > >>> concern is too narrow selection, there is an oversampling > >>> factor parameter in the Signal Separator block, that will > >>> allow filtering wider than actually from the GUI specified, to > >>> compensate the naturally underestimated bandwidth when using > >>> energy detection. Also, the GUI now supports zooming so a user > >>> can work really precise if needed :) > >>> > >>> Thanks again for the feedback! > >>> Cheers, > >>> Sebastian > >>> > >>> 2016-06-27 16:41 GMT+02:00 Ben Hilburn > >>> <<mailto:bhilb...@gnuradio.org>bhilb...@gnuradio.org > >>> <mailto:bhilb...@gnuradio.org>>: > >>> > >>> Hi Sebastian - > >>> > >>> Thanks for the great update! > >>> > >>> I'm curious how the "manual selection with the mouse" will > >>> work? For some of the back-end processing that is going > >>> on, like Chris's AMC work, not selecting all of the bins > >>> of the signal seems like it could seriously impact the > >>> success of those functions. If the the FFT is, for > >>> example, 1024 bins, it seems like it may be hard for a > >>> user to accurately select the bins that are important. > >>> Will there be some sort of "intelligent auto-aim", for > >>> lack of a better word, for this? > >>> > >>> Thanks for the great work so far! The GUI screenshots are > >>> looking great, by the way. > >>> > >>> Cheers, > >>> Ben > >>> > >>> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller > >>> <gse...@gmail.com <mailto:gse...@gmail.com>> wrote: > >>> > >>> Hi all, > >>> > >>> it’s GSoC midterms time! For that purpose, I wrote a > >>> new blog post with what I’ve been up to and with a > >>> review of what I’ve done so far: > >>> < > https://grinspector.wordpress.com/2016/06/26/week-5-midterms/> > https://grinspector.wordpress.com/2016/06/26/week-5-midterms/ > >>> > >>> I have managed to accomplish all of my midterm > >>> milestones and am looking forward for the next 8 weeks > >>> of GSoC. > >>> > >>> Cheers > >>> Sebastian > >>> > >>> > >>> Am 18. Juni 2016 um 15:06:11, Sebastian Müller > >>> (<mailto:gse...@gmail.com>gse...@gmail.com > >>> <mailto:gse...@gmail.com>) schrieb: > >>> > >>>> 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/> > https://grinspector.wordpress.com/2016/06/18/week-4-gui/ > >>>> > >>>> Cheers, > >>>> Sebastian > >>>> > >>>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller > >>>> (<mailto:gse...@gmail.com>gse...@gmail.com > >>>> <mailto:gse...@gmail.com>) 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/> > 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 > >>>>> <<mailto:gse...@gmail.com>gse...@gmail.com > >>>>> <mailto: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/> > 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 > >>>>> (<mailto:gse...@gmail.com>gse...@gmail.com > >>>>> <mailto: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 > >>>>>> (<mailto:kraemer...@gmail.com> > kraemer...@gmail.com > >>>>>> <mailto: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 > >>>>>>> <<mailto:gse...@gmail.com>gse...@gmail.com > >>>>>>> <mailto: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/> > 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 > >>>>>>> <mailto:Discuss-gnuradio@gnu.org> > Discuss-gnuradio@gnu.org > >>>>>>> <mailto:Discuss-gnuradio@gnu.org> > >>>>>>> < > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>>>>>> > >>>>>>> > >>>>> > >>> > >>> _______________________________________________ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org <mailto: > 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 > >> > > > > > _______________________________________________ > 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
