Error while running std examples max_power.py, bert : boost::math::round<d>(d): Value -nan

Hello,

I recently installed the latest git pull of both the GNU Radio and UHD
driver. I am getting the some relating to USRP initialization errors
when
I’m running some of the examples provided. max_power.py
and digital_bert_tx.py or rx.py.
My setup seems correct since I can run the fft scripts etc.

It seems to be some kind of overflow that is causing this but I am not
able
to figure out why. I tried to use my limited debugging skills and have
these comments

  1. Since bert is similar to the benchmark_tx, on comparing the two, I
    see
    that in digital_bert_tx, the error goes away if you comment out
    self._modulator = self._modulator_class(**mod_kwargs)
    and pass
    self._modulator_class(**mod_kwargs)._constellation
    to the bert transmitter chain initialization.

  2. There is a minor mismatch in the arguments to the uhd_transmitter
    initialization, a subdevice is expected between options.tx_gain
    and options.antenna.
    But that is certainly not causing the error.

  3. Looking at the C++ source code, the line of code that is actually
    throwing the exception is in the UHD tree (Line 152 in the
    uhd_src/host/lib/device.cpp)
    device::sptr dev = maker(dev_addr);

  4. I cannot figure out any temporary fix for the max_power.py failure.

Has anybody else faced similar issues before or have any suggestions for
debugging directions?

Thanks
Shalabh

Traceback (most recent call last): - From bert
File “./digital_bert_tx.py”, line 130, in
tb = tx_psk_block(mod, options)
File “./digital_bert_tx.py”, line 73, in init
options.antenna, options.verbose)
File
“/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py”,
line 137, in init
freq, gain, spec, antenna)
File
“/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py”,
line 49, in init
self.u = uhd.usrp_sink(device_addr=args,
stream_args=uhd.stream_args(‘fc32’))
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/init.py”,
line 112, in constructor_interceptor
return old_constructor(*args)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py”,
line 2320, in usrp_sink
return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round(d): Value -nan can
not be represented in the target integer type.

Traceback (most recent call last): - From max_power.py
File “./max_power.py”, line 140, in
main ()
File “./max_power.py”, line 133, in main
tb = build_block (options.args, options.tx_enable,
options.rx_enable)
File “./max_power.py”, line 63, in init
self.u_tx = uhd.usrp_sink(device_addr=args, stream_args=stream_args)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/init.py”,
line 112, in constructor_interceptor
return old_constructor(*args)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py”,
line 2320, in usrp_sink
return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round(d): Value -nan can
not be represented in the target integer type.

On Fri, Jan 6, 2012 at 12:47 AM, Shalabh J.
[email protected]wrote:

these comments
and options.antenna.
But that is certainly not causing the error.

  1. Looking at the C++ source code, the line of code that is actually
    throwing the exception is in the UHD tree (Line 152 in the
    uhd_src/host/lib/device.cpp)
    device::sptr dev = maker(dev_addr);

I’ll look into this tomorrow. When we moved everything to gr-digital and
all of the examples to using UHD, we were moving quickly, and this might
have been left behind after some change. I know it was working when I
first
added it. It looks like you found the fix; I’ll verify it tomorrow.

  1. I cannot figure out any temporary fix for the max_power.py failure.

I was debating over whether or not to even include this example when we
moved to using the UHD. This was a program only designed for the first
gen
USRPs and libusrp. It’s really probably not applicable to the conditions
under the UHD anymore, anyway. Again, I’ll check it tomorrow.

Has anybody else faced similar issues before or have any suggestions for
debugging directions?

Thanks
Shalabh

Thanks for the feedback!

Tom

On Sun, Jan 15, 2012 at 11:32 PM, Tom R.
[email protected]wrote:

It seems to be some kind of overflow that is causing this but I am not
2. There is a minor mismatch in the arguments to the uhd_transmitter
I’ll look into this tomorrow. When we moved everything to gr-digital and
moved to using the UHD. This was a program only designed for the first gen

File “./digital_bert_tx.py”, line 73, in init
File

line 112, in constructor_interceptor
return old_constructor(*args)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py”,
line 2320, in usrp_sink
return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round(d): Value -nan can
not be represented in the target integer type.

Shalabh,

I just pushed fixes to the digital BER tests. It was indeed a case that
some things changed with how the UHD interface was used that did not get
updated here. I just tested these over the air successfully.

I was able to run the max_power.py script just fine. Can you post your
hardware configuration so I can see if there is something specific there
that’s causing a problem?

Thanks,
Tom

On 30/01/12 09:36 PM, Shalabh J. wrote:

I’m really sorry for the delayed response. As I mentioned, I got
absorbed into some other work.

Thanks for your help.

Shalabh

In the case of uhd_fft.py, what parameters are you passing on the
command line?


Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On Mon, Jan 16, 2012 at 10:13 AM, Tom R.
[email protected]wrote:

My setup seems correct since I can run the fft scripts etc.
to the bert transmitter chain initialization.

Shalabh
File “./digital_bert_tx.py”, line 130, in
self.u = uhd.usrp_sink(device_addr=args,
not be represented in the target integer type.
File

Thanks,
Tom

Hi Tom,

The max_power.py script runs just fine. However, the problem still seems
to
persists in general with other examples. I’m posting the error while
running digital_bert_tx.py below. It exists for the rx example as well.
In
fact, with the latest version of gnuradio and uhd, even the uhd_fft.py
as
stopped working. This was working previously and would occasionally
error
out. Posting the error message below. It seems the problem is rooted
deeper
than the top level modules.

My hardware is USRP2 (rev 4.0) with the XCVR2450 daughterboard. The host
machine is a Dell Optiplex 980.
Software versions are GNURadio (29aa72d4 - downloaded 1/30), UHD
(e30cf4ec

  • downloaded 1/30), Firmware (003.004.000-322fb97), Ubuntu (10.04 -
    32bit)

If you need any more information, please let me know. I will try to
debug
this further. Please let me know if you have any suggestions in that
direction.

I’m really sorry for the delayed response. As I mentioned, I got
absorbed
into some other work.

Thanks for your help.

Shalabh

linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-e30cf4e

gr_fir_ccf: using SSE
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
Traceback (most recent call last):
File “./digital_bert_tx.py”, line 133, in
tb = tx_psk_block(mod, options)
File “./digital_bert_tx.py”, line 75, in init
options.antenna, options.verbose)
File
“/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py”,
line 137, in init
freq, gain, spec, antenna)
File
“/home/gnuradio/Shared/sj/usrp_stuff/code/s_eg/digital/narrowband/uhd_interface.py”,
line 49, in init
self.u = uhd.usrp_sink(device_addr=args,
stream_args=uhd.stream_args(‘fc32’))
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/init.py”,
line 112, in constructor_interceptor
return old_constructor(*args)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py”,
line 2324, in usrp_sink
return _uhd_swig.usrp_sink(*args)
RuntimeError: Error in function boost::math::round(d): Value -nan can
not be represented in the target integer type.

linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-e30cf4e
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
Traceback (most recent call last):
File “/opt/gnuradio-3.5/bin/uhd_fft.py”, line 297, in
main ()
File “/opt/gnuradio-3.5/bin/uhd_fft.py”, line 293, in main
app = stdgui2.stdapp(app_top_block, “UHD FFT”, nstatus=1)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 38, in init
wx.App.init (self, redirect=False)
File
“/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7978, in init
self._BootstrapApp()
File
“/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7552, in _BootstrapApp
return core.PyApp__BootstrapApp(*args, **kwargs)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 42, in OnInit
self._max_noutput_items)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 64, in init
self.panel = stdpanel (self, self, top_block_maker, max_nouts)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 86, in init
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File “/opt/gnuradio-3.5/bin/uhd_fft.py”, line 90, in init
otw_format=options.wire_format, args=scalar))
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/init.py”,
line 112, in constructor_interceptor
return old_constructor(*args)
File
“/opt/gnuradio-3.5/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py”,
line 2290, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: Error in function boost::math::round(d): Value -nan can
not be represented in the target integer type.

On 31/01/12 01:24 AM, Shalabh J. wrote:

Just the frequency option (-f 2440M).

-Shalabh
My suspicion is that you’re not using the version of Gnu Radio you think
you’re using, and there’s an
ABI difference between UHD and gr-uhd.

After you re-built UHD and Gnu Radio, did you “sudo ldconfig”?

On Mon, Jan 30, 2012 at 9:54 PM, Marcus D. Leech [email protected]
wrote:

seems the problem is rooted deeper than the top level modules.

Just the frequency option (-f 2440M).

-Shalabh

On Tue, Jan 31, 2012 at 7:54 AM, Marcus D. Leech [email protected]
wrote:

My suspicion is that you’re not using the version of Gnu Radio you think
you’re using, and there’s an
ABI difference between UHD and gr-uhd.

After you re-built UHD and Gnu Radio, did you “sudo ldconfig”?

Yes I did do that. I just rechecked the system for any previous
installation files, but there isn’t anything. My gnuradio and uhd
installs
are in specific directory rather than the default locations, so I can
claim
this with certainty. What I can try is to do a fresh install of latest
gnuradio and uhd branch on my personal laptop and see if this error
persists. I’ll report the results of that once I return home.

I can add another random finding to this since I tried rebooting the
machine. If my kernel buffers are set to the default size, I get the std
UHD warning to resize. However, the gui comes up for uhd_fft.py. But if
I
resize the buffers as suggested, I get the previously mentioned errors.
Though the bert example errors out in both the cases.

-Shalabh

Just the frequency option (-f 2440M).

-Shalabh

I am suspecting a possible issue with an initialized variable. Do you
mind trying this little patch: pastebucket.com - pastebucket Resources and Information.

-Josh

On Tue, Jan 31, 2012 at 5:52 PM, Josh B. [email protected] wrote:

If you pull the latest master you will get this fix (I hope it is the
fix for your issue):

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/5b06adb7911727353938df84a0a6b71cda66c95c/diff/host/lib/types/time_spec.cpp

Josh…

I tried both the patch (pastebucket.com - pastebucket Resources and Information.) and the latest
git
release independently.
Both of them work and solve the issue. I don’t see an immediate
correlation
between both of them. But they both work.
So I am going to continue using the git version, since I assume that is
the
‘official’ fix.

Thanks a lot for your help.

-Shalabh