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 <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/ > > 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 > (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/ >> >> Cheers, >> Sebastian >> >> Am 10. Juni 2016 um 15:14:24, Sebastian Müller >> (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/ >>> >>> 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 <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/ >>> >>> 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 <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 >>>> (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 >>>>> <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/ >>>>> >>>>> 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 >>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>> >>>>> 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