Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Martin Braun]

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 <address@hidden <mailto:address@hidden>> 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 <address@hidden
>>     <mailto:address@hidden>>:
>>
>>         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:address@hidden>address@hidden
>>         <mailto:address@hidden>>:
>>
>>             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
>>             <address@hidden <mailto:address@hidden>> 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:address@hidden>address@hidden
>>                 <mailto:address@hidden>) 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:address@hidden>address@hidden
>>>                 <mailto:address@hidden>) 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:address@hidden>address@hidden
>>>>                 <mailto:address@hidden>>:
>>>>
>>>>                     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:address@hidden>address@hidden
>>>>                     <mailto:address@hidden>) 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:address@hidden>address@hidden
>>>>>                     <mailto:address@hidden>) 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:address@hidden>address@hidden
>>>>>>                     <mailto:address@hidden>>:
>>>>>>
>>>>>>                         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:address@hidden>address@hidden
>>>>>>                         <mailto:address@hidden>
>>>>>>                         
>>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>
>>
>>                 _______________________________________________
>>                 Discuss-gnuradio mailing list
>>                 address@hidden <mailto:address@hidden>
>>                 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>