> Hey,
>
> Thanks a lot!
>
> I'm away from hardware until Tuesday. Will test it then.
I still think that for your application, you don't actually need it. A
test would still be appreciated.
M
>
> Ruben
>
> *From:*trondeau@trondeau.com [mailto:trondeau@trondeau.com] *On Behalf
> Of *Tom Rondeau
> *Sent:* Tuesday, September 23, 2014 7:55 PM
> *To:* Martin Braun
> *Cc:* Merz Ruben, INI-INO-ECO-MXT; GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Issue with deinterleave block from a
> file source to USRP sink with x300
>
> On Tue, Sep 23, 2014 at 12:22 PM, Martin Braun <martin.braun@ettus.com
> <mailto:martin.braun@ettus.com>> wrote:
>
> On 23.09.2014 09:08, Ruben.Merz@swisscom.com
> <mailto:Ruben.Merz@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.com@gnu.org
> <mailto:swisscom.com@gnu.org>
> [mailto:discuss-gnuradio-bounces+ruben.merz
> <mailto:discuss-gnuradio-bounces%2Bruben.merz>=swisscom.com@gnu.org
> <mailto:swisscom.com@gnu.org>] On
> Behalf Of Martin Braun
> Sent: Tuesday, September 23, 2014 5:40 PM
> Cc: discuss-gnuradio@gnu.org <mailto: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.Merz@swisscom.com
> <mailto:Ruben.Merz@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.com@gnu.org
> <mailto:swisscom.com@gnu.org>
> [mailto:discuss-gnuradio-bounces+ruben.merz
> <mailto:discuss-gnuradio-bounces%2Bruben.merz>=swisscom.com@gnu.org
> <mailto:swisscom.com@gnu.org>] On
> Behalf Of Martin Braun
> Sent: Tuesday, September 23, 2014 1:11 AM
> Cc: discuss-gnuradio@gnu.org
> <mailto: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.Merz@swisscom.com
> <mailto:Ruben.Merz@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
> <http://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 <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto: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
No comments:
Post a Comment