Hi all, it's the second last week of GSoC 2016 and I've dealt with the last (small) issues that accumulated during the last weeks. Read about it here: https://grinspector.wordpress.com/2016/08/12/week-12-solving-the-small-issues/
Stay tuned next week for the pybombs and promo video release! Cheers, Sebastian 2016-08-05 17:08 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>: > ach stimmt, du machst ja "live" decoding! ja, da müssen die sampleraten > insgesamt stimmen :) > > On 08/05/2016 05:07 PM, Sebastian Müller wrote: > > Die Audio Sink will halt 48kHz und spielt das, was rein kommt, mit genau > dieser Rate ab. Wenn ich jetzt ein Signal mit anderer Samprate reingebe, > wird das Signal zu schnell/langsam abgespielt. Bei kleinen Differenzen gibt > das Mickymousestimmen, aber irgendwann versteht man halt garnix mehr. > > Am 5. August 2016 um 16:43:36, Marcus Müller (marcus.muel...@ettus.com) > schrieb: > >> Kurz ma off-list: >> >> sag mal, was passiert eigentlich mitm demodulierten Signal bei FM, wenn >> du *nicht* resamplest? Steh ich da grad aufm Schlauch, oder ist die >> Frequenzmodulation dann einfach nur mitm Faktor skaliert? Wäre es da nicht >> einfacher, diesen Faktor nach dem Demodulieren draufzurechnen? >> >> Grüße >> Marcus >> >> On 08/05/2016 04:40 PM, Sebastian Müller wrote: >> >> Hi, >> >> GSoC week 11 is over and I have updated my block with what I have been >> doing this week: >> https://grinspector.wordpress.com/2016/08/05/week-11-let-the-music-play/ >> >> Thanks to an universal resampler in the Signal Extractor it is now >> possible to demodulate detected FM signals. >> >> Cheers >> Sebastian >> >> 2016-07-29 16:39 GMT+02:00 Dave NotTelling <dmp250...@gmail.com>: >> >>> Great work! >>> >>> On Fri, Jul 29, 2016 at 10:36 AM, Sebastian Müller < <gse...@gmail.com> >>> 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> >>>> 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/> >>>>> 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> >>>>> 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> >>>>>> 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>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>gse...@gmail.com <mailto: >>>>>>> <gse...@gmail.com>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>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>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>gse...@gmail.com >>>>>>> >>> <mailto: <gse...@gmail.com>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> >>>>>>> bhilb...@gnuradio.org >>>>>>> >>> <mailto: <bhilb...@gnuradio.org>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>gse...@gmail.com <mailto: >>>>>>> <gse...@gmail.com>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>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>gse >>>>>>> <gse...@gmail.com> <n...@gmail.com>n...@gmail.com >>>>>>> >>> <mailto: <gse...@gmail.com>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>https://grinspector. >>>>>>> wordpress.com/2016/06/18/week-4-gui/> <https://grinspector>h >>>>>>> ttps://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> >>>>>>> gse <gse...@gmail.com> <n...@gmail.com>n...@gmail.com >>>>>>> >>>> <mailto: <gse...@gmail.com>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>https://grinspector. >>>>>>> wordpress.com/2016/06/10/week-3-separation-issues/>https://gri >>>>>>> nspector.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> >>>>>>> gse <gse...@gmail.com> <n...@gmail.com>n...@gmail.com >>>>>>> >>>>> <mailto: <gse...@gmail.com>gse...@gmail.com>>: >>>>>>> >>>>> >>>>>>> >>>>> Hi All, >>>>>>> >>>>> >>>>>>> >>>>> the second GSoC week is over and I have >>>>>>> updated >>>>>>> >>>>> my blog with the latest news: >>>>>>> >>>>> < <https://grinspector>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>gse <gse...@gmail.com> <n...@gmail.com>n...@gmail.com >>>>>>> >>>>> <mailto: <gse...@gmail.com> >>>>>>> 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> <kraemer...@gmail.com>kraemer...@gmail.com >>>>>>> >>>>>> <mailto: <kraemer...@gmail.com> >>>>>>> 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 >>>>>>> <gse...@gmail.com> <n...@gmail.com>n...@gmail.com >>>>>>> >>>>>>> <mailto: <gse...@gmail.com> >>>>>>> gse...@gmail.com>>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> there is a new blog post concerning >>>>>>> the >>>>>>> >>>>>>> gr-inspector toolbox: >>>>>>> >>>>>>> < <https://grinspector> >>>>>>> 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>Discuss-gnuradio@gnu.org >>>>>>> >>>>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>>>> >>>>>>> < <https://lists.gnu.org/> >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>>> <https://lists.gnu>https://lists.gnu.org/mailman/ >>>>>>> listinfo/discuss-gnuradio >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> Discuss-gnuradio mailing list >>>>>>> >>> <Discuss-gnuradio@gnu.org> >>>>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>>>>> >>> <https://lists.gnu.org/>https://lists.gnu.org/ >>>>>>> mailman/listinfo/discuss-gnuradio >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> Discuss-gnuradio mailing list >>>>>>> >> <Discuss-gnuradio@gnu.org>Discuss-gnuradio@gnu.org >>>>>>> >> <https://lists.gnu.org/mailman/>https://lists.gnu.org/mailman/ >>>>>>> listinfo/discuss-gnuradio >>>>>>> >> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Discuss-gnuradio mailing list >>>>>>> <Discuss-gnuradio@gnu.org>Discuss-gnuradio@gnu.org >>>>>>> <https://lists.gnu.org/mailman/>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 >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
