FPE with FM Rcvr

Working the following issue…any ideas?

System: Ubuntu 10.10, Gnuradio 3.3.0, uhd (Mar 2011), USRP2, TVRX

Using the attached grc model results in a floating point exception:

gnuradio_core_runtime.py (1476)

top_block.py (96)

 top_block_gui.py (72)

   USRP2_WX.py (326)

General output in GRC:

Generating: “/home/jim/radiostuff/refs/gen/USRP2_WX.py”

Executing: “/home/jim/radiostuff/refs/gen/USRP2_WX.py”

linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.000.000-3235792

Current recv frame size: 1476 bytes
Current send frame size: 1472 bytes
Making transport for DSP0…
Current recv sock buff size: 50000000 bytes
Making transport for DSP1…
Current recv sock buff size: 50000000 bytes
Making transport for ERR0…
mboard0 MIMO master

Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 3.200000 MSps
Actual sample rate: 3.225806 MSps #Betting this is the culprit but
haven’t completed a trace

gr_fir_ccc: using SSE

Done

I’m looking through the UHD spec to see if there is a function that
easily resolves this but nothing has jumped out, yet.

It might be a memory issue. An attempt to sample at the 6Mz limit with
the TVRX (board responds with ~5.88…) results in
gr_buffer:allocate_buffer: failed to allocate buffer of size 18760,
which points to an installation issue that make check should have
handled…a reinstall and closer scrutiny of the output should highlight
any neglected warnings/errors.

On 03/30/2011 09:31 PM, Ron H. wrote:

Working the following issue…any ideas?

System: Ubuntu 10.10, Gnuradio 3.3.0, uhd (Mar 2011), USRP2, TVRX

Using the attached grc model results in a floating point exception:

(process of elimination)

it looks like its coming from the xlating filter

It might be a memory issue. An attempt to sample at the 6Mz limit
with the TVRX (board responds with ~5.88…) results in
gr_buffer:allocate_buffer: failed to allocate buffer of size 18760,
which points to an installation issue that make check should have
handled…a reinstall and closer scrutiny of the output should
highlight any neglected warnings/errors.

failed to allocate is an issue introduced by a block that changed that
is used in the fft sink (tom?)

-Josh

On Fri, Apr 1, 2011 at 1:49 AM, Ron H. [email protected]
wrote:

Adding to the following, a backtrace that points to the throw
std::bad_alloc (), gr_buffer.cc (88)

May have some association with another error addressed earlier this year by
T. Rondeau: [Discuss-gnuradio] gr_vmcircbuf_sysv_shm: shmget (1): Invalid
argument, Dated: Fri, 11 Feb 2011 09:52:04-0500

Ron, I took a look at your graph, and I see a few discrepancies. Where
are
you getting your numbers for adc_rate, usrp_dec, and usrp_inter? Using a
sample rate for the USRP as 3.2 Msps doesn’t work because it runs at 100
Msps with integer decimation, so you are really asking for a decimation
of
31.25. Instead, it is giving you a decimation of 31 for a rate of 3.225,
as
the warning in your original email said.

I then don’t quite get what you are doing with the rational resampler
and
how you are building the taps for the frequency translating filter, but
maybe I just haven’t gone through the math properly.

Importantly, though, you have set the decimation of the filter to 0
(probably because you are doing integer division with
audio_inter/audio_dec,
which is less than 1; I suspect you meant audio_rate/audio_dec or
something), which, while I haven’t tested it, is probably where you’re
problem is.

gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument

gr_buffer::allocate_buffer: failed to allocate buffer of size 18760 KB

#3 0x008a3055 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/libstdc++.so.6
#4 0x008a0f35 in ?? () from /usr/lib/libstdc++.so.6
#5 0x008a0f72 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x008a10e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x00ae4861 in gr_buffer::gr_buffer (this=0xb4ef478, nitems=2345,
sizeof_item=8192, link=…) at gr_buffer.cc:88

You are asking for a huge buffer here. It’s throwing because it can’t
properly allocate you the size buffer you are requesting. It’s seeking a
buffer of 2345 items with a size of 8192 for each item. I’m not sure
which
block is doing this, but it strikes me it could be due to the decimation
of
0 in the filter.

Tom

Adding to the following, a backtrace that points to the throw
std::bad_alloc (), gr_buffer.cc (88)

May have some association with another error addressed earlier this year
by T. Rondeau: [Discuss-gnuradio] gr_vmcircbuf_sysv_shm: shmget (1):
Invalid argument, Dated: Fri, 11 Feb 2011 09:52:04-0500

gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument
gr_buffer::allocate_buffer: failed to allocate buffer of size 18760 KB
terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc

Program received signal SIGABRT, Aborted.
0x00436416 in __kernel_vsyscall ()
(gdb) bt
#0 0x00436416 in __kernel_vsyscall ()
#1 0x006c2941 in raise () from /lib/libc.so.6
#2 0x006c5e42 in abort () from /lib/libc.so.6
#3 0x008a3055 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/libstdc++.so.6
#4 0x008a0f35 in ?? () from /usr/lib/libstdc++.so.6
#5 0x008a0f72 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x008a10e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x00ae4861 in gr_buffer::gr_buffer (this=0xb4ef478, nitems=2345,
sizeof_item=8192, link=…) at gr_buffer.cc:88
#8 0x00ae4908 in gr_make_buffer (nitems=2345, sizeof_item=8192,
link=…) at gr_buffer.cc:96
#9 0x00acec5f in gr_flat_flowgraph::allocate_buffer (this=0xb4ef458,
block=…, port=0) at gr_flat_flowgraph.cc:121
#10 0x00acf1af in gr_flat_flowgraph::allocate_block_detail
(this=0xb4ef458, block=…) at gr_flat_flowgraph.cc:80
#11 0x00ad1538 in gr_flat_flowgraph::setup_connections (this=0xb4ef458)
at gr_flat_flowgraph.cc:62
#12 0x00af7880 in gr_top_block_impl::start (this=0xab2dcd0) at
gr_top_block_impl.cc:106
#13 0x00af61b0 in gr_top_block::start (this=0xaa91c78) at
gr_top_block.cc:59
#14 0x00179128 in _wrap_gr_top_block_sptr_start (args=0xa7bdeec) at
python/gnuradio_core_runtime.cc:15301
#15 0x080ddd23 in PyEval_EvalFrameEx ()
#16 0x080df04c in PyEval_EvalFrameEx ()
#17 0x080df04c in PyEval_EvalFrameEx ()
#18 0x080dfbb2 in PyEval_EvalCodeEx ()
#19 0x080de145 in PyEval_EvalFrameEx ()
#20 0x080dfbb2 in PyEval_EvalCodeEx ()
#21 0x080dfca7 in PyEval_EvalCode ()
#22 0x080fd956 in PyRun_FileExFlags ()
#23 0x080d7d09 in ?? ()
#24 0x080ddd23 in PyEval_EvalFrameEx ()
#25 0x080dfbb2 in PyEval_EvalCodeEx ()
#26 0x080dfca7 in PyEval_EvalCode ()
#27 0x080fe460 in PyRun_StringFlags ()
#28 0x080dee04 in PyEval_EvalFrameEx ()
#29 0x080dfbb2 in PyEval_EvalCodeEx ()
#30 0x080de145 in PyEval_EvalFrameEx ()
#31 0x080df04c in PyEval_EvalFrameEx ()
#32 0x080df04c in PyEval_EvalFrameEx ()
#33 0x080dfbb2 in PyEval_EvalCodeEx ()
#34 0x080dfca7 in PyEval_EvalCode ()
#35 0x080df0d8 in PyEval_EvalFrameEx ()
#36 0x080dfbb2 in PyEval_EvalCodeEx ()
#37 0x080de145 in PyEval_EvalFrameEx ()
#38 0x080dfbb2 in PyEval_EvalCodeEx ()
#39 0x08168e3c in ?? ()
#40 0x0805fd6a in PyObject_Call ()
#41 0x0805aa53 in ?? ()
#42 0x0805b295 in Py_Main ()
#43 0x0805a8ab in main ()
(gdb)

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs