Re: [Discuss-gnuradio] Issue with deinterleave block from a file source to USRP sink with x300

[Ruben.Merz]

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?
Ruben

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Martin Braun
> Sent: Tuesday, September 23, 2014 5:40 PM
> Cc: address@hidden
> 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, address@hidden 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: address@hidden
> > [mailto:address@hidden On
> > Behalf Of Martin Braun
> > Sent: Tuesday, September 23, 2014 1:11 AM
> > Cc: address@hidden
> > 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, <address@hidden> 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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio