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
M
On Fri, Sep 19, 2014 at 2:58 PM, <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_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
No comments:
Post a Comment