Ruben
*From:address@hidden [mailto:address@hidden *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 <address@hidden
<mailto:address@hidden>> wrote:
On 23.09.2014 09:08, address@hidden
<mailto:address@hidden> 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:
address@hidden
<mailto:address@hidden>
[mailto:discuss-gnuradio-bounces+ruben.merz
<mailto:discuss-gnuradio-bounces%2Bruben.merz>address@hidden
<mailto:address@hidden>] On
Behalf Of Martin Braun
Sent: Tuesday, September 23, 2014 5:40 PM
Cc: address@hidden <mailto: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
<mailto: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>
[mailto:discuss-gnuradio-bounces+ruben.merz
<mailto:discuss-gnuradio-bounces%2Bruben.merz>address@hidden
<mailto:address@hidden>] On
Behalf Of Martin Braun
Sent: Tuesday, September 23, 2014 1:11 AM
Cc: address@hidden
<mailto: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
<mailto: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
<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
address@hidden <mailto:address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden <mailto:address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden <mailto:address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio