UHD Source -and- Sink In Same GRC Flowgraph?

GNU Radio
1

Hi Folks,

I’m having some fun and games with gnuradio, a USRP1, and trying to
transmit and receive at the same time, using gnuradio-companion.

A Simple [UHD SOURCE] ----> [UHD SINK] works perfectly, but when I
start to try to do other things, I get a Segmentation Fault from
somewhere.

Even something as simple as this graph SEGVs on me (Yes, I know it’s
useless, but I cut everything down to as simple as I could to confirm
the problem wasn’t in my flowgraph, and those blocks were already in
my wonderfully crafted flowgraph!):

[SIGNAL SOURCE 1750Hz] -> [UHD SINK]
[UHD SOURCE] -> [MULTIPLY CONST] -> [WX_WATERFALL]

It does not seem to matter what antennas or sub devices I
select (I have twin WBX boards, so am able to switch which
antennas do what…)

My gnuradio installation is from git, just a few weeks ago,
gnuradio-config-info -v shows v3.5.1-43-g309ca769

UHD is from the same date (3rd Feb looking at my datestamps),
and uhd_find_devices reports:

linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-5b06adb

for it’s version, and does find my URSP as expected with it’s
dual WBX’s. USRP Firmware is from 29-11-2011 (latest I found), Base
system is Ubuntu 12.04.

Anyone have any pointers ? Is this a known issue ? Would upgrading
to the very latest HEAD help me ? Or is there something I need to
do in code prior to running both a UHD SOURCE and SINK in the same
flowgraph under grc ?

Best Regards

Iain

2

On Tue, Feb 21, 2012 at 11:55 AM, Iain Young, G7III [email protected]
wrote:

useless, but I cut everything down to as simple as I could to confirm
My gnuradio installation is from git, just a few weeks ago,

Anyone have any pointers ? Is this a known issue ? Would upgrading
to the very latest HEAD help me ? Or is there something I need to
do in code prior to running both a UHD SOURCE and SINK in the same
flowgraph under grc ?

Rebuild gr-uhd, reinstall it, try again.

–n

3

I’m willing to bet that your segfault comes from our friend OpenGL:

Try this before you start your application:

export
“LIBGL_ALWAYS_INDIRECT=1”

Also try updating to latest master for Gnu
Radio and UHD. If you’re on Ubuntu or Fedora, you can use:

http://www.sbrac.org/files/build-gnuradio

To do the
download/build/install/post-install dance

-Marcus

On Tue, 21 Feb
2012 19:55:45 +0000, Iain Young, G7III wrote:

Hi Folks,

I’m
having some fun and games with gnuradio, a USRP1, and trying to

transmit and receive at the same time, using gnuradio-companion.

A
Simple [UHD SOURCE] ----> [UHD SINK] works perfectly, but when I
start
to try to do other things, I get a Segmentation Fault from

somewhere.

Even something as simple as this graph SEGVs on me (Yes,
I know it’s
useless, but I cut everything down to as simple as I could
to confirm
the problem wasn’t in my flowgraph, and those blocks were
already in
my wonderfully crafted flowgraph!):

[SIGNAL SOURCE
1750Hz] → [UHD SINK]
[UHD SOURCE] → [MULTIPLY CONST] →
[WX_WATERFALL]

It does not seem to matter what antennas or sub
devices I
select (I have twin WBX boards, so am able to switch which

antennas do what…)

My gnuradio installation is from git, just a
few weeks ago,
gnuradio-config-info -v shows v3.5.1-43-g309ca769

UHD is from the same date (3rd Feb looking at my datestamps),

and
uhd_find_devices reports:

linux; GNU C++ version 4.6.1;
Boost_104601; UHD_003.004.000-5b06adb

for it’s version, and does
find my URSP as expected with it’s
dual WBX’s. USRP Firmware is from
29-11-2011 (latest I found), Base
system is Ubuntu 12.04.

Anyone
have any pointers ? Is this a known issue ? Would upgrading
to the
very latest HEAD help me ? Or is there something I need to
do in code
prior to running both a UHD SOURCE and SINK in the same
flowgraph
under grc ?

Best Regards

Iain

Discuss-gnuradio
mailing list
[email protected] [1]

Discuss-gnuradio Info Page [2]

Links:

4

Hi Marcus,

Thanks for the pointers, You Wrote:

I’m willing to bet that your segfault comes from our friend OpenGL:

Try this before you start your application:

export “LIBGL_ALWAYS_INDIRECT=1”

Tried it, no improvement.

Also try updating to latest master for Gnu Radio and UHD. If you’re on
Ubuntu or Fedora, you can use:

Tried the latest and greatest. I don’t think I’ll be taking that bet…
…Still doesn’t work, but do get a bit more of an error report:

iain@qcerberus:~/FlowGraphs$ ./cw_tx_test.py
linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-b1f34b4

The program ‘python’ received an X Window System error.
This probably reflects a bug in the program.
The error was ‘BadRequest (invalid request code or no such operation)’.
(Details: serial 566 error_code 1 request_code 136 minor_code 19)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)

Curiously, I don’t get the issue when using the QT GUI sinks, just
the WX. Would this be expected with the OpenGL issue ? Anything
else I can try [without gdbing tonight…]

Further tests indicate that if I remove the Graphical elements,
(replacing them with Null Sinks where needed), and tell GRC
“No GUI” in the Options Block/Generate Options, I get SEGV again.

[Oh and to clarify, it’s Ubuntu 11.10 I’m running, not 12.04…Wishful
thinking and not time travel or ultra-fast neutrinos :slight_smile: ]

Best Regards

Iain

5

On 21/02/12 22:20, Marcus D. Leech wrote:

Hmmm, I had a simultaneous send/receive app on USRP1 a few weeks ago
that SEGVed. I didn’t have time to investigate.
But perhaps this is the same issue?

Could you reduce it to UHD+“stuff”+innocuous sink – does that work?

Sure can. Graph is as follows:

[Null Source] —> [UHD SINK]
[UHD Source] —> [Null Sink]

Results are as follows:

Options Block/Generate Options set to QT-GUI : Runs Fine
Options Block/Generate Options set to WX-GUI : SEGV
Options Block/Generate Options set to No-GUI : SEGV

Also added a “NOP” block in-between the sources and sinks,
same result.

Iain

6

On 02/21/2012 05:05 PM, Iain Young, G7III wrote:

Tried it, no improvement.
The program ‘python’ received an X Window System error.
Curiously, I don’t get the issue when using the QT GUI sinks, just

Best Regards

Iain

Hmmm, I had a simultaneous send/receive app on USRP1 a few weeks ago
that SEGVed. I didn’t have time to investigate.
But perhaps this is the same issue?

Could you reduce it to UHD+“stuff”+innocuous sink – does that work?

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

7

On 02/21/2012 06:18 PM, Iain Young, G7III wrote:

They was within the same GRC File, although not linked (IE separate
RX and TX chains)

Yup, the precipitating characteristic appears to be that both TX and RX
facilities are in use on the same USRP1.

I was able to reproduce here with a trivial flow-graph. Sent a report
off to Josh.

Hope that helps

Iain

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

8

On 21/02/12 23:04, Marcus D. Leech wrote:

Options Block/Generate Options set to No-GUI : SEGV

Also added a “NOP” block in-between the sources and sinks,
same result.

Iain

OK, but were these sending/receive from the USRP1 simultaneously, in the
same flow-graph?

They was within the same GRC File, although not linked (IE separate
RX and TX chains)

The case I’m interested in is where there’s only one of those at a time.

I just tried [UHD SOURCE] -> [MULTIPLY CONST] -> [UHD SINK], and that
worked with all three Options Block/Generate Options settings.
[UHD SOURCE] -> [MULTIPLY CONST] -> [WX WATERFALL SINK] has always
worked.

Just having one “chain”, RX or TX has always worked for me, even with
the WX GUI sinks.

Hope that helps

Iain

9

On Tue, Feb 21, 2012 at 05:46:51PM -0800, Josh B. wrote:

OK guys, thanks. I pushed a minor fix to master. The max samples per
packet was mis-advertised and too many bytes were committed to the
interface in some cases when the previous send() was a short one.

Thanks Josh, amazingly quick response! I just had 5 minutes to test
this.
I can confirm that NO-GUI with dual chains now works. With WX-GUI, I
still
get hit by the famous OpenGL bug, but that was to be expected.

Thanks again both!

Iain

10

On 02/21/2012 03:30 PM, Marcus D. Leech wrote:

OK guys, thanks. I pushed a minor fix to master. The max samples per
packet was mis-advertised and too many bytes were committed to the
interface in some cases when the previous send() was a short one.

-Josh