discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] isolate channels from wideband


From: Chris Kuethe
Subject: Re: [Discuss-gnuradio] isolate channels from wideband
Date: Tue, 11 Aug 2015 22:00:46 -0700

Here it is; many thanks to N8UR for the feedback and corrections ...
https://github.com/ckuethe/gnuradio-examples/tree/master/pfb_channelizer

The synthesizer doesn't really look like much when it's running, but
you can see on the waterfall where the "extra" channel is used - it's
having an existential crisis, full of nothingness and being torn in
half... :D
https://raw.githubusercontent.com/ckuethe/gnuradio-examples/master/pfb_channelizer/synthesizer_gui.png

The channelizer now works as expected; if you generate a set of "this
is channel %d" audio files and synthesize them into a band, the
flowgraph will extract them again in the proper order.
https://raw.githubusercontent.com/ckuethe/gnuradio-examples/master/pfb_channelizer/channelizer_gui.png

On Tue, Aug 11, 2015 at 8:16 PM, Chris Kuethe <address@hidden> wrote:
> I have produced a complementary demonstration of the polyphase channel
> synthesizer and a tool for generating test signal. As before, it was
> developed using the a very recent gnuradio release (3.7.8rc1) so older
> installations may be unable to load the grc file. Will publish
> shortly...
>
> As a meta point, I encourage everyone developing with gnuradio to
> build test tools and synthetic data sources before starting on the DSP
> work (or make some good recordings if you're working with real world
> signals). As I am not blessed with 5 or 6 audible NOAA stations, I
> wrote a tool to generate distinctive audio streams that could then be
> fed through the synthesizer - in this case "flite" was used to convert
> the weather reports for 7 different airports to wav files, and a
> prologue containing expected channel number and frequency offset was
> prepended. This allowed me to very easily hear when/if the channelizer
> was correctly selecting the channels I wanted.
>
> On Thu, Aug 6, 2015 at 7:08 AM, Daniele Nicolodi <address@hidden> wrote:
>> On 22/07/15 15:40, Tom Rondeau wrote:
>>> On Wed, Jul 22, 2015 at 4:57 AM, Daniele Nicolodi <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>>     On 21/07/15 21:39, Tom Rondeau wrote:
>>>     > Here's my presentation from last GRCon:
>>>     >
>>>     > http://gnuradio.squarespace.com/grcon14-presentations#tut-rondeau
>>>
>>>     Hello Tom,
>>>
>>>     browsing through your presentation I see that on page 58 and 59 you
>>>     recommend to use firdes filter design tool and not optfir to build re
>>>     reconstruction filter.  However, I don't quite understand why the filter
>>>     generated by one tool is better than the other is this case.
>>>
>>>     Can you please comment on it?
>>>
>>>     Thanks! Cheers,
>>>     Daniele
>>>
>>>
>>> The shape of this filter matters greatly. The inband, transition, and
>>> stop band behavior all determine if the filter can be used for the
>>> reconstruction purposes. The image on slide 59 shows the specific
>>> transition between the pass band and stop bands. To match that with the
>>> PM (i.e., Remez) algorithm, you can't get the same stop band performance
>>> for that given transition. Plus the equal response in the stop band is
>>> bad when channelizing because all channels will alias at equal powers,
>>> whereas the roll off in frequency with the windowed (firdes) filter
>>> continues to decrease with f. Remez also produces a pass band ripple,
>>> which will also affect things. The ripple with the firdes is not
>>> equiripple like Remez promises, but it's much, much smaller.
>>
>>
>> Thanks Tom, very clear explanation.
>>
>> Cheers,
>> Daniele
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]