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

[Tom Rondeau]

On Sun, Jan 15, 2012 at 11:32 PM, Tom Rondeau <address@hidden> wrote:

On Fri, Jan 6, 2012 at 12:47 AM, Shalabh Jain <address@hidden> wrote:

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);

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.

 

4. 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

 

Traceback (most recent call last): - From bert

  File "./digital_bert_tx.py", line 130, in <module>

    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>(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 <module>

    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>(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