Great work! On Fri, Jul 29, 2016 at 10:36 AM, Sebastian Müller <gse...@gmail.com> wrote:
> Hi all, > > week 10 of GSoC is over and I managed to implement an OFDM sync block: > https://grinspector.wordpress.com/2016/07/29/week-10-sync/ > > Since I make good time, I will try to add a FM demod block to the toolbox. > Target is to have one example workflow from Ether to demod data (= sound). > > Cheers, > Sebastian > > 2016-07-22 16:11 GMT+02:00 Sebastian Müller <gse...@gmail.com>: > >> Hi list, >> >> in week 9 of my GSoC I finally managed to implement a working OFDM >> parameter estimation block. Read here about it: >> https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/ >> >> Next up is a frequency and timing synchronization block. >> >> Cheers >> Sebastian >> >> 2016-07-18 9:57 GMT+02:00 Sebastian Müller <gse...@gmail.com>: >> >>> 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
