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: 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
