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
