On Tue, Sep 23, 2014 at 12:22 PM, Martin Braun <martin.br...@ettus.com>
wrote:
> On 23.09.2014 09:08, ruben.m...@swisscom.com wrote:
>
>> I was expecting that answer (not the jumping up and down part, but the
>> let's fix the right problem).
>>
>> I can try to fix it, I just need to find some time. Would you have a good
>> example of another block to look into?
>>
>
> First of all, you'll need to change check_topology to this:
>
> bool
> deinterleave_impl::check_topology(int ninputs, int noutputs)
> {
> set_relative_rate(1.0/double(noutputs));
> d_noutputs = noutputs;
> return true;
> }
>
> Notice the rate change fix.
> Then, work needs to consume as much as possible (right now, it's as little
> as possible). stream_mux might be a good example for how to do that. The
> difficulty is, you need to keep track of where you are, what you have
> consumed etc.
> Which is probably why this wasn't implemented properly the first time
> 'round :)
>
>
> M
>
Martin, Ruben,
Thanks for pointing this out. Check out this patch here:
https://gist.github.com/trondeau/7d5d06ea2f0586f0e9e4
Passes all our QA, doing the right thing in my test setup, and working
about 20x faster than before.
Tom
> Ruben
>>
>> -----Original Message-----
>>> From: discuss-gnuradio-bounces+ruben.merz=swisscom....@gnu.org
>>> [mailto:discuss-gnuradio-bounces+ruben.merz=swisscom....@gnu.org] On
>>> Behalf Of Martin Braun
>>> Sent: Tuesday, September 23, 2014 5:40 PM
>>> Cc: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Issue with deinterleave block from a file
>>> source to USRP sink with x300
>>>
>>> I usually jump up and down with excitement when people send
>>> documentation patches, but this is not one that should go in GNU Radio.
>>> First of all, deinterleave and stream_to_streams are not identical
>>> unless you
>>> have unit block size. Second, we should fix the deinterleaver rather than
>>> pointing out it is broken in the docs.
>>>
>>> Would you want to fix the deinterleaver? Basically, it needs to follow
>>> the
>>> 'process as much as you can' paradigm.
>>>
>>> M
>>>
>>> On 23.09.2014 00:02, ruben.m...@swisscom.com wrote:
>>>
>>>> Indeed.
>>>> Would the following patch to the documentation be useful (since streams
>>>> to
>>>>
>>> stream seems to replace it properly)?
>>>
>>>>
>>>> diff --git a/gr-blocks/include/gnuradio/blocks/deinterleave.h
>>>> b/gr-blocks/include/gnuradio/blocks/deinterleave.h
>>>> index a3b5480..1b9d5c1 100644
>>>> --- a/gr-blocks/include/gnuradio/blocks/deinterleave.h
>>>> +++ b/gr-blocks/include/gnuradio/blocks/deinterleave.h
>>>> @@ -40,6 +40,10 @@ namespace gr {
>>>> * a single input to each output unless blocksize is given in the
>>>> * constructor.
>>>> *
>>>> + * This block can only process one block at a time. Therefore its
>>>> + * efficiency may be limited. It is advised to use the streams to
>>>> + * stream block instead.
>>>> + *
>>>> * \code
>>>> * blocksize = 1
>>>> * connections = 2
>>>>
>>>> Ruben
>>>>
>>>> From: discuss-gnuradio-bounces+ruben.merz=swisscom....@gnu.org
>>>> [mailto:discuss-gnuradio-bounces+ruben.merz=swisscom....@gnu.org] On
>>>> Behalf Of Martin Braun
>>>> Sent: Tuesday, September 23, 2014 1:11 AM
>>>> Cc: discuss-gnuradio@gnu.org
>>>> Subject: Re: [Discuss-gnuradio] Issue with deinterleave block from a
>>>> file source to USRP sink with x300
>>>>
>>>> It seems deinterleave is both buggy and inefficiently designed. The bug
>>>> is
>>>>
>>> the relative rate is wrong, the inefficiency is that it only works on
>>> one block at
>>> a time. I suggest using something else.
>>>
>>>>
>>>> M
>>>>
>>>> On Fri, Sep 19, 2014 at 2:58 PM, <ruben.m...@swisscom.com> wrote:
>>>> Hello,
>>>>
>>>> I have the following setup: a file source, a deinterleave block and a
>>>> USRP
>>>>
>>> sink (see the attached .grc and related .png). This setup is a test to
>>> distribute
>>> two different signals on two channels of the USRP x300 (the file source
>>> loads a
>>> binary file with alternated channels containing 64 bit long IQ samples -
>>> 32 real
>>> followed by 32 imaginary - channel 1/channel 2/channel 1/channel
>>> 2/etc...).
>>>
>>>>
>>>> The hardware is a USRP x300 with two wideband SBX (SBX-120) boards.
>>>>
>>>> Now, the above setup used to function without a hitch. But recently, it
>>>>
>>> completely freezes gnuradio. Basically, I start the flowgraph and
>>> quickly get a
>>> large number of 'L' and no signal is transmitted. The only thing I can
>>> do is then
>>> to kill gnuradio-companion and related python processes.
>>>
>>>>
>>>> The interesting thing is that if I replace the deinterleave block by a
>>>> "stream
>>>>
>>> to streams" block, everything works fine. I am bit puzzled as to what I
>>> am
>>> missing.
>>>
>>>>
>>>> The operating system is Ubuntu 14.04 LTS (updated state), UHD is the
>>>> head
>>>>
>>> of the maint branch, and gnuradio as well (UHD_003.007.002-2-gdb35bf46
>>> and Gnuradio: 9dcb5067c55a0630c9edca6b62a32b1f8e633930). Firmware
>>> is also the most recent. I have attached the .grc, and the binary file I
>>> am using
>>> can be obtained here: http://www.net.t-labs.tu-
>>> berlin.de/~ruben/files/sine_test_10kHz_20kHz_cpx_float_2chan_interleaved
>>> _1MSs.bin.
>>>
>>>>
>>>> Assuming there is not something wrong in my .grc setup, how do I debug
>>>> this
>>>>
>>> issue?
>>>
>>>> Thanks for any suggestion or help,
>>>> Ruben
>>>>
>>>> _______________________________________________
>>>> 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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
