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

2016-07-18 9:57 GMT+02:00 Sebastian Müller <address@hidden>:

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 <address@hidden>:
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 <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
>>
>

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

From:	Sebastian Müller
Subject:	Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback
Date:	Fri, 22 Jul 2016 16:11:46 +0200