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
