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
