Issue with deinterleave block from a file source to USRP sink with x300

addis_a · September 20, 2014, 12:37am

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

laber · September 23, 2014, 1:12am

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

laber · September 23, 2014, 9:04am

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=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+ruben.merz=removed_email_address@domain.invalid] On
Behalf Of Martin B.
Sent: Tuesday, September 23, 2014 1:11 AM
Cc: [email protected]
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, [email protected] 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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

laber · September 23, 2014, 5:41pm

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

laber · September 23, 2014, 6:09pm

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

laber · September 23, 2014, 7:56pm

On Tue, Sep 23, 2014 at 12:22 PM, Martin B. [email protected]
wrote:

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:

gist.github.com

https://gist.github.com/trondeau/7d5d06ea2f0586f0e9e4

gistfile1.txt

diff --git a/gr-blocks/lib/deinterleave_impl.cc b/gr-blocks/lib/deinterleave_impl.cc
index c9d0e9a..9e18c35 100644
--- a/gr-blocks/lib/deinterleave_impl.cc
+++ b/gr-blocks/lib/deinterleave_impl.cc
@@ -41,13 +41,20 @@ namespace gr {
               io_signature::make (1, io_signature::IO_INFINITE, itemsize)),
         d_itemsize(itemsize), d_blocksize(blocksize), d_current_output(0)
     {
+      d_size_bytes = d_itemsize * d_blocksize;
       set_output_multiple(blocksize);

This file has been truncated. show original

Passes all our QA, doing the right thing in my test setup, and working
about 20x faster than before.

Tom

laber · September 23, 2014, 6:24pm

On 23.09.2014 09:08, [email protected] 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

laber · September 24, 2014, 10:41am

On 22.09.2014 23:50, [email protected] wrote:

We are using a similar setup to transmit a 2x2 MIMO OFDM waveform on the
x300. Because we were not sure what to assume from a TX synchronization
point of view, we decided to put the IQ samples of both channels
interleaved in one file. We figured that reading them in sequence, IQ
sample by IQ sample, would definitely ensure that both channels are
synchronized.

But, now that I understand better how to synchronize both channels via
the UHD API, I could probably use two files, one for each channel. Any
comment?

Yes, that would be the way to do it. Effectively, from the UHD sink’s
point of view, this is what you’re already doing.

M

laber · September 24, 2014, 5:39pm

On 24.09.2014 01:47, [email protected] wrote:

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

laber · September 24, 2014, 11:24am

Hey,
Thanks a lot!
I’m away from hardware until Tuesday. Will test it then.
Ruben

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom R.
Sent: Tuesday, September 23, 2014 7:55 PM
To: Martin B.
Cc: Merz Ruben, INI-INO-ECO-MXT; GNURadio D.ion 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 B.
<[email protected]mailto:[email protected]> wrote:
On 23.09.2014 09:08,
[email protected]mailto:[email protected] 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?