How to change the channel width when data is transmitting

cao_jing · November 13, 2008, 12:09am

Hi,

I am working on change the channel width dynamically when data is
transmitting.

I tried to use set_interp_rate to change the interpolation when data
is transmitting, but it caused a program crashed.

Does anybody know how to do it correctly?

Thank you very much!

Jing

cao_jing · November 13, 2008, 12:47am

On Wed, Nov 12, 2008 at 6:07 PM, cao jing [email protected]
wrote:

Hi,

I am working on change the channel width dynamically when data is transmitting.

I tried to use set_interp_rate to change the interpolation when data
is transmitting, but it caused a program crashed.

Your program should never simply crash. You may want to try to figure
out where it’s crashing and give an extensive report to the list.

Does anybody know how to do it correctly?

Changing the interpolation rate between transmission bursts should
change the overall channel bandwidth.

Brian

cao_jing · November 13, 2008, 1:05am

On Wed, Nov 12, 2008 at 06:46:18PM -0500, Brian P. wrote:

On Wed, Nov 12, 2008 at 6:07 PM, cao jing [email protected] wrote:

Hi,

I am working on change the channel width dynamically when data is transmitting.

I tried to use set_interp_rate to change the interpolation when data
is transmitting, but it caused a program crashed.

I doubt it caused your program to crash. It may have caused the
program to start receiving junk.

This is a known problem, http://gnuradio.org/trac/ticket/290

You may be able to work around it like this:

u.stop()
u.set_interp_rate(new_interp_rate)
u.start()

I haven’t tested this.

Eric

cao_jing · November 14, 2008, 8:16am

cao jing wrote:

Hi,

I am working on change the channel width dynamically when data is transmitting.

I tried to use set_interp_rate to change the interpolation when data
is transmitting, but it caused a program crashed.

Does anybody know how to do it correctly?

I checked in a fix to the verilog to allow this. However, the released
rbf files haven’t been updated yet, so you will need to compile it
yourself.

Matt

cao_jing · November 15, 2008, 7:33am

Hi,

Matt E. wrote :

I checked in a fix to the verilog to allow this. However, the released
rbf files haven’t been updated yet, so you will need to compile it
yourself.

Matt

I compiled your changes today. The rbf is given on the link below. I
will
try to test it and give you a report.

http://rapidshare.com/files/163918423/std_2rxhb_2tx.rbf

Best Regards,

Firas

View this message in context:
http://www.nabble.com/how-to-change-the-channel-width-when-data-is-transmitting-tp20471587p20512914.html
Sent from the GnuRadio mailing list archive at Nabble.com.

cao_jing · November 17, 2008, 11:28pm

I changed my code to set the interpolation every 10 packets instead of
per packet. Now the program doesn’t block any more.

But now the problem is the transmitter can’t transmit the data
correctly, that is checked by bechmark_rx.py and usrp_ffy.py

Jing

cao_jing · November 17, 2008, 8:59pm

I downloaded your compiled rbf file to /usr/local/share/usrp/rev4.

Then try to set the interpolation dynamically. It still doesn’t work.

My code is as follow.

gnuradio/gnuradio-examples/python/digital/transmit_path.py

def send_pkt(self, payload='', eof=False):
    """
    Calls the transmitter method to send a packet
    """
    self.u.set_interp_rate(128)

    return self.packet_transmitter.send_pkt(payload, eof)

The program is paused when I call self.u.set_interp_rate(128).

Jing

cao_jing · November 18, 2008, 5:30am

Hi,

I have not test it yet. But did you followed Eric suggestion in this
thread!. change every (self.u.set_interp_rate(xxx)) with:

self.u.stop()
self.u.set_interp_rate(xxx)
self.u.start()

Best regards,

Firas

View this message in context:
http://www.nabble.com/how-to-change-the-channel-width-when-data-is-transmitting-tp20471587p20553469.html
Sent from the GnuRadio mailing list archive at Nabble.com.

cao_jing · November 18, 2008, 5:15pm

Hi,

If tb is your topblock, you can try the following :

tb.stop()
tb.wait()
self.u.set_inter_rate(xxx)
tb.start()

Don’t forget to give us a feed back.

Best Regards,

Firas

–
View this message in context:
http://www.nabble.com/how-to-change-the-channel-width-when-data-is-transmitting-tp20471587p20562715.html
Sent from the GnuRadio mailing list archive at Nabble.com.

cao_jing · November 18, 2008, 7:28am

Yes, I tried Eric suggestion too. It will report some USB error.

Jing

cao_jing · November 19, 2008, 5:12am

Hi,

What is your gnuradio code revision ?

svn info

Regards,

Firas

cao_jing · November 18, 2008, 9:21pm

I changed my code in benchmark_tx.py as follow. But the program
blocked at the tb.wait().

tb.start() // this is the first time
tb.stop()
tb.wait() // block here
self.u.set_inter_rate(xxx)
tb.start()

cao_jing · November 19, 2008, 7:04am

svn info

Path: .
URL: http://gnuradio.org/svn/gnuradio/trunk
Repository Root: http://gnuradio.org/svn
Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5
Revision: 9986
Node Kind: directory
Schedule: normal
Last Changed Author: jblum
Last Changed Rev: 9986
Last Changed Date: 2008-11-13 14:15:33 -0500 (Thu, 13 Nov 2008)

cao_jing · November 20, 2008, 9:38pm

I figured out a method to set interpolation correctly. Before the
interpolation is set, we have to flush out all the data from the
transmit path. Now I do it by sleep for a while before I set the
interpolation.

The best solution is there is a indicator to show whether the
transmitting path is empty.

Is there anybody know how to get this indicator?

Jing

cao_jing · December 5, 2008, 6:41am

Hi,

I have a strange suggestion to you (it worked for me in some time
earlier). If it works for you please give us a feedback.

the Suggestion:

Change TX amplitude from 12000 (as you stated in your email) to 2000 and
redo the experiment.

Note:
To run with real time scheduling, start your program with sudo (as a
root)

Best regards,

Firas

cao_jing · December 5, 2008, 7:31am

It works! Thanks a lot for the suggestion, but I think its enabling real
time scheduling that helped :). The Tx amplitude did not make any
difference.

Now I am checking how many of these packets reach successfully to the
receiver.

cao_jing · December 5, 2008, 6:20am

Hi guys,

Thanks a lot for all the help. Continuing where Jing left (we work in
the
same team) …

My installation is on ubuntu 8.10 using the repositories listed on
gnuradio
website. I am calling benchmark_tx.py with interpolation of 512 and
trying
to change it every alternate packet to 256. Other details:

gr_fir_fff: using SSE
bits per symbol = 1
Gaussian filter bt = 0.35
Using TX d’board A: Flex 2400 Tx MIMO B
Tx amplitude 12000
modulation: gmsk_mod
bitrate: 125kb/s
samples/symbol: 2
interp: 512
Tx Frequency: 2.5G
Warning: failed to enable realtime scheduling

The added code is the in the while loop:

    payload = struct.pack('!H', pktno & 0xffff) + data
    #Ritesh
    if pktno % 2 == 0:
            tb.stop()
            if curr_interp == options.interp:
                    curr_interp = (options.interp)/2
            else:
                    curr_interp = options.interp
            tb.wait()
            tb.txpath.u.set_interp_rate(curr_interp)
            tb.start()
            #time.sleep(0.01)
    send_pkt(payload)

Anyways, it looks like if I do not use the wait() call (as suggested by
Firas), then either of the following 4 things happen after some packets
are
transmitted. The number of packets that get transmitted before the
program
stops is not constant.

Segmentation fault. The gdb backtrace is here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4dd2b90 (LWP 20950)]
0xb66be8ea in fusb_devhandle_linux::_cancel_pending_rqsts () from
/usr/lib/libusrp.so.0
(gdb) bt
#0 0xb66be8ea in fusb_devhandle_linux::_cancel_pending_rqsts () from
/usr/lib/libusrp.so.0
#1 0xb66bf595 in fusb_ephandle_linux::stop () from
/usr/lib/libusrp.so.0
#2 0xb66b28a5 in usrp_basic_tx::stop () from /usr/lib/libusrp.so.0
#3 0xb66bb70d in usrp_standard_tx::stop () from /usr/lib/libusrp.so.0
#4 0xb6676860 in usrp1_sink_base::stop () from
/usr/lib/python2.5/site-packages/gnuradio/_usrp1.so
#5 0xb7bbdead in gr_single_threaded_scheduler::main_loop () from
/usr/lib/libgnuradio-core.so.0
#6 0xb7bbe83d in gr_single_threaded_scheduler::run () from
/usr/lib/libgnuradio-core.so.0
#7 0xb7bbc414 in gr_scheduler_thread::run_undetached () from
/usr/lib/libgnuradio-core.so.0
#8 0xb79313fd in omni_thread_wrapper () from
/usr/lib/libgromnithread.so.0
#9 0xb7eb450f in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#10 0xb7e027ee in clone () from /lib/tls/i686/cmov/libc.so.6

I also sometimes see these statements printed on stdout “fusb: (status
-2)
No such file or directory”, “fusb::pending_remove: failed to find urb in
pending_rqsts: 0x94f04f0”

One time it crashed without segmentation fault. It printed a huge
report
which I am attaching in the end of the email.
Sometimes it aborts after some failed assertions like:
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned
int,
unsigned int): Assertion s < d_bufsize' failed. OR python: /usr/include/boost/shared_ptr.hpp:315: T* boost::shared_ptr<T>::operator->() const [with T = gr_message]: Assertionpx != 0’ failed.
Very few times it goes through fine.

If I do put the tb.wait() statement, then the program keeps waiting. And
gdb
trace shows it stuck in the wait() call. Here is the gdb backtrace:

#0 0xb7f2f430 in __kernel_vsyscall ()
#1 0xb7ee2bf7 in pthread_join () from
/lib/tls/i686/cmov/libpthread.so.0
#2 0xb795ff0d in omni_thread::join () from
/usr/lib/libgromnithread.so.0
#3 0xb7bef75e in gr_top_block_impl::wait () from
/usr/lib/libgnuradio-core.so.0
#4 0xb7beed10 in gr_top_block::wait () from
/usr/lib/libgnuradio-core.so.0
#5 0xb7c74bef in top_block_wait_unlocked ()
from
/usr/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
#6 0xb7c7cebd in ?? () from
/usr/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
#7 0x0805d867 in PyObject_Call ()
#8 0x080cd502 in PyEval_EvalFrameEx ()
#9 0x080d0345 in PyEval_EvalCodeEx ()
#10 0x080ce728 in PyEval_EvalFrameEx ()
#11 0x080cfbf5 in PyEval_EvalFrameEx ()
#12 0x080d0345 in PyEval_EvalCodeEx ()
#13 0x080ce728 in PyEval_EvalFrameEx ()
#14 0x080d0345 in PyEval_EvalCodeEx ()
#15 0x080d0557 in PyEval_EvalCode ()
#16 0x080edf8f in PyRun_FileExFlags ()
#17 0x080ee25a in PyRun_SimpleFileExFlags ()
#18 0x080595e7 in Py_Main ()
#19 0x08058962 in main ()

If I do not change the interpolation rate every alternate packet and
instead
do it every 4th or 5th packet, then the program seem to go through fine.

Hopefully this info is useful to debug whats going on.

Thanks,
Ritesh

The report related to #2 above:

*** glibc detected *** python: double free or corruption (fasttop):
0x09fb4f60 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7daa3f4]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7dac456]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7a20031]
/usr/lib/libusrp.so.0(_ZN19fusb_ephandle_linux18completed_list_getEv+0x3c)[0xb66d8b5c]
/usr/lib/libusrp.so.0(_ZN19fusb_ephandle_linux4stopEv+0xa8)[0xb66d95c8]
/usr/lib/libusrp.so.0(_ZN13usrp_basic_tx4stopEv+0x35)[0xb66cc8a5]
/usr/lib/libusrp.so.0(_ZN16usrp_standard_tx4stopEv+0x1d)[0xb66d570d]
/usr/lib/python2.5/site-packages/gnuradio/_usrp1.so(_ZN15usrp1_sink_base4stopEv+0x20)[0xb6690860]
/usr/lib/libgnuradio-core.so.0(_ZN28gr_single_threaded_scheduler9main_loopEv+0x101d)[0xb7bd7ead]
/usr/lib/libgnuradio-core.so.0(_ZN28gr_single_threaded_scheduler3runEv+0x1d)[0xb7bd883d]
/usr/lib/libgnuradio-core.so.0(_ZN19gr_scheduler_thread14run_undetachedEPv+0xa4)[0xb7bd6414]
/usr/lib/libgromnithread.so.0(omni_thread_wrapper+0x7d)[0xb794b3fd]
/lib/tls/i686/cmov/libpthread.so.0[0xb7ece50f]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e1c7ee]
======= Memory map: ========
08048000-08144000 r-xp 00000000 08:04 744916 /usr/bin/python2.5
08144000-08145000 r–p 000fb000 08:04 744916 /usr/bin/python2.5
08145000-0816a000 rw-p 000fc000 08:04 744916 /usr/bin/python2.5
0816a000-08170000 rw-p 0816a000 00:00 0
09817000-0a26a000 rw-p 09817000 00:00 0 [heap]
a4bf3000-a4bf4000 —p a4bf3000 00:00 0
a4bf4000-a53f4000 rw-p a4bf4000 00:00 0
a53f4000-a53f5000 —p a53f4000 00:00 0
a53f5000-a5bf5000 rw-p a53f5000 00:00 0
a5bf5000-a5bf6000 —p a5bf5000 00:00 0
a5bf6000-a63f6000 rw-p a5bf6000 00:00 0
a63f6000-a63f7000 —p a63f6000 00:00 0
a63f7000-a6bf7000 rw-p a63f7000 00:00 0
a6bf7000-a6bf8000 —p a6bf7000 00:00 0
a6bf8000-a73f8000 rw-p a6bf8000 00:00 0
a73f8000-a73f9000 —p a73f8000 00:00 0
a73f9000-a7bf9000 rw-p a73f9000 00:00 0
a7bf9000-a7bfa000 —p a7bf9000 00:00 0
a7bfa000-a83fa000 rw-p a7bfa000 00:00 0
a83fa000-a83fb000 —p a83fa000 00:00 0
a83fb000-a8bfb000 rw-p a83fb000 00:00 0
a8bfb000-a8bfc000 —p a8bfb000 00:00 0
a8bfc000-a93fc000 rw-p a8bfc000 00:00 0
a93fc000-a93fd000 —p a93fc000 00:00 0
a93fd000-a9bfd000 rw-p a93fd000 00:00 0
a9bfd000-a9bfe000 —p a9bfd000 00:00 0
a9bfe000-aa3fe000 rw-p a9bfe000 00:00 0
aa3fe000-aa3ff000 —p aa3fe000 00:00 0
aa3ff000-aabff000 rw-p aa3ff000 00:00 0
aabff000-aac00000 —p aabff000 00:00 0
aac00000-ab400000 rw-p aac00000 00:00 0
ab400000-ab421000 rw-p ab400000 00:00 0
ab421000-ab500000 —p ab421000 00:00 0
ab5da000-ab5db000 —p ab5da000 00:00 0
ab5db000-abddb000 rw-p ab5db000 00:00 0
abddb000-abddc000 —p abddb000 00:00 0
abddc000-ac5dc000 rw-p abddc000 00:00 0
ac5dc000-ac5dd000 —p ac5dc000 00:00 0
ac5dd000-acddd000 rw-p ac5dd000 00:00 0
acddd000-acdde000 —p acddd000 00:00 0
acdde000-ad5de000 rw-p acdde000 00:00 0
ad5de000-ad5df000 —p ad5de000 00:00 0
ad5df000-adddf000 rw-p ad5df000 00:00 0
adddf000-adde0000 —p adddf000 00:00 0
adde0000-ae5e0000 rw-p adde0000 00:00 0
ae5e0000-ae5e1000 —p ae5e0000 00:00 0
ae5e1000-aede1000 rw-p ae5e1000 00:00 0
aede1000-aede2000 —p aede1000 00:00 0
aede2000-af5e2000 rw-p aede2000 00:00 0
af5e2000-af5e3000 —p af5e2000 00:00 0
af5e3000-afde3000 rw-p af5e3000 00:00 0
afde3000-afde4000 —p afde3000 00:00 0
afde4000-b05e4000 rw-p afde4000 00:00 0
b05e4000-b05e5000 —p b05e4000 00:00 0
b05e5000-b0de5000 rw-p b05e5000 00:00 0
b0de5000-b0de6000 —p b0de5000 00:00 0
b0de6000-b15e6000 rw-p b0de6000 00:00 0
b15e6000-b15e7000 —p b15e6000 00:00 0
b15e7000-b1de7000 rw-p b15e7000 00:00 0
b1de7000-b1de8000 —p b1de7000 00:00 0
b1de8000-b25e8000 rw-p b1de8000 00:00 0
b25e8000-b25e9000 —p b25e8000 00:00 0
b25e9000-b2de9000 rw-p b25e9000 00:00 0
b2de9000-b2dea000 —p b2de9000 00:00 0
b2dea000-b35ea000 rw-p b2dea000 00:00 0
b35ea000-b35eb000 —p b35ea000 00:00 0
b35eb000-b3deb000 rw-p b35eb000 00:00 0
b3deb000-b3dec000 —p b3deb000 00:00 0
b3dec000-b45ec000 rw-p b3dec000 00:00 0
b45ec000-b45ed000 —p b45ec000 00:00 0
b45ed000-b4ded000 rw-p b45ed000 00:00 0
b4ded000-b4dee000 —p b4ded000 00:00 0
b4dee000-b55ee000 rw-p b4dee000 00:00 0
b55ee000-b55ef000 —p b55ee000 00:00 0
b55ef000-b5def000 rw-p b55ef000 00:00 0
b5def000-b5df0000 r–s 00000000 00:09 964034594 /SYSV00000000 (deleted)
b5df0000-b5df8000 rw-s 00000000 00:09 964100139 /SYSV00000000 (deleted)
b5df8000-b5e00000 rw-s 00000000 00:09 964100139 /SYSV00000000 (deleted)
b5e00000-b5e01000 r–s 00000000 00:09 964034594 /SYSV00000000 (deleted)
b5e01000-b5e02000 r–s 00000000 00:09 964132899 /SYSV00000000 (deleted)
b5e02000-b5e0a000 rw-s 00000000 00:09 964198441 /SYSV00000000 (deleted)
b5e0a000-b5e12000 rw-s 00000000 00:09 964198441 /SYSV00000000 (deleted)
b5e12000-b5e13000 r–s 00000000 00:09 964132899 /SYSV00000000 (deleted)
b5e13000-b5e14000 —p b5e13000 00:00 0
b5e14000-b6614000 rw-p b5e14000 00:00 0
b6614000-b6615000 r–s 00000000 00:09 963837985 /SYSV00000000 (deleted)
b6615000-b661d000 rw-s 00000000 00:09 963903528 /SYSV00000000 (deleted)
b661d000-b6625000 rw-s 00000000 00:09 963903528 /SYSV00000000 (deleted)
b6625000-b6626000 r–s 00000000 00:09 963837985 /SYSV00000000 (deleted)
b664a000-b664b000 r–s 00000000 00:09 963739678 /SYSV00000000 (deleted)
b664b000-b6653000 rw-s 00000000 00:09 963805221 /SYSV00000000 (deleted)
b6653000-b665b000 rw-s 00000000 00:09 963805221 /SYSV00000000 (deleted)
b665b000-b665c000 r–s 00000000 00:09 963739678 /SYSV00000000 (deleted)
b665c000-b66b9000 r-xp 00000000 08:04 1297014
/usr/lib/python2.5/site-packages/gnuradio/_usrp1.so
b66b9000-b66bc000 rw-p 0005d000 08:04 1297014
/usr/lib/python2.5/site-packages/gnuradio/_usrp1.so
b66bc000-b66c2000 r-xp 00000000 08:04 980134
/lib/libusb-0.1.so.4.4.4
b66c2000-b66c3000 r–p 00005000 08:04 980134
/lib/libusb-0.1.so.4.4.4
b66c3000-b66c5000 rw-p 00006000 08:04 980134
/lib/libusb-0.1.so.4.4.4
b66c5000-b66e0000 r-xp 00000000 08:04 750555
/usr/lib/libusrp.so.0.0.0
b66e0000-b66e1000 rw-p 0001b000 08:04 750555
/usr/lib/libusrp.so.0.0.0
b66e8000-b66e9000 r–s 00000000 00:09 963936285 /SYSV00000000 (deleted)
b66e9000-b66f1000 rw-s 00000000 00:09 964001831 /SYSV00000000 (deleted)
b66f1000-b66f9000 rw-s 00000000 00:09 964001831 /SYSV00000000 (deleted)
b66f9000-b66fa000 r–s 00000000 00:09 963936285 /SYSV00000000 (deleted)
b66fa000-b66fd000 r-xp 00000000 08:04 876068
/usr/lib/python2.5/lib-dynload/cmath.so
b66fd000-b66fe000 r–p 00002000 08:04 876068
/usr/lib/python2.5/lib-dynload/cmath.so
b66fe000-b66ff000 rw-p 00003000 08:04 876068
/usr/lib/python2.5/lib-dynload/cmath.so
b66ff000-b6710000 r-xp 00000000 08:04 1296987
/usr/lib/python2.5/site-packages/usrpm/_usrp_prims.so
b6710000-b6711000 rw-p 00011000 08:04 1296987
/usr/lib/python2.5/site-packages/usrpm/_usrp_prims.so
b6711000-b6742000 r-xp 00000000 08:04 980182
/usr/lib/python2.5/site-packages/numpy/random/mtrand.so
b6742000-b6743000 r–p 00030000 08:04 980182
/usr/lib/python2.5/site-packages/numpy/random/mtrand.so
b6743000-b6747000 rw-p 00031000 08:04 980182
/usr/lib/python2.5/site-packages/numpy/random/mtrand.so
b6747000-b6d7b000 r-xp 00000000 08:04 746411
/usr/lib/liblapack.so.3gf.0
b6d7b000-b6d7c000 r–p 00633000 08:04 746411
/usr/lib/liblapack.so.3gf.0
b6d7c000-b6d7f000 rw-p 00634000 08:04 746411
/usr/lib/liblapack.so.3gf.0
b6d7f000-b6e8c000 rw-p b6d7f000 00:00 0
b6e8e000-b6e91000 r-xp 00000000 08:04 876077
/usr/lib/python2.5/lib-dynload/_locale.so
b6e91000-b6e92000 r–p 00002000 08:04 876077
/usr/lib/python2.5/lib-dynload/_locale.so
b6e92000-b6e93000 rw-p 00003000 08:04 876077
/usr/lib/python2.5/lib-dynload/_locale.so
b6e93000-b6ea7000 r-xp 00000000 08:04 876065
/usr/lib/python2.5/lib-dynload/_ctypes.so
b6ea7000-b6ea8000 r–p 00014000 08:04 876065
/usr/lib/python2.5/lib-dynload/_ctypes.so
b6ea8000-b6eaa000 rw-p 00015000 08:04 876065
/usr/lib/python2.5/lib-dynload/_ctypes.so
b6eaa000-b6eb9000 r-xp 00000000 08:04 971614 /lib/libbz2.so.1.0.4
b6eb9000-b6eba000 r–p 0000f000 08:04 971614 /lib/libbz2.so.1.0.4
b6eba000-b6ebb000 rw-p 00010000 08:04 971614 /lib/libbz2.so.1.0.4
b6ebb000-b6Aborted

cao_jing · May 19, 2009, 10:14am

I got the same problem which Ritesh Maheshwari got. I want to stop top
block
with transmit_path, and it hang on the tb.wait() just like Ritesh
Maheshwari.
And i’m sure that it run with gr realtime schedule. And I set the TX
amplitude to 2000 or even less. But it still hang on the tb.wait().
I do some gdb work, find out that there are still one thread not quit,
so
the system is blocking there. But I can’t figure out how to quit the
thread,
and what cause the thread hang in there. Will you please help me?

---------------------------------------------gdb
backtrace----------------------------------------
#0 0xb7f8f430 in _kernel_vsyscall ()
#1 0xb7f49075 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7bdfe17 in boost::condition_variable::wait (this=0x8c14438,
m=@0xb29fa730)
at /usr/include/boost/thread/pthread/condition_variable.hpp:35
#3 0xb7a421f2 in boost::join ()
from /usr/lib/libboost_thread-mt-d.so.1.35.0
#4 0xb7a53223 in gruel::thread_group::join_all (this=0x8c14094)
at thread_group.cc:78
#5 0xb7bd74a0 in gr_scheduler_tpb::wait (this=0x8c14090)
at gr_scheduler_tpb.cc:94
#6 0xb7bdd7c9 in gr_top_block_impl::wait (this=0x8b73b80)
at gr_top_block_impl.cc:124
#7 0xb7bdd080 in gr_top_block::wait (this=0x874cbc8) at
gr_top_block.cc:71
#8 0xb7c5b3af in top_block_wait_unlocked (r=
{px = 0xb29fa80c, pn = {pi = 0xb29fa828}})
at gnuradio_swig_py_runtime.cc:4865
#9 0xb7c654d6 in _wrap_top_block_wait_unlocked (args=0x8bca1cc,
kwargs=0x8bd468c) at gnuradio_swig_py_runtime.cc:15264
#10 0x0805d867 in PyObject_Call ()
#11 0x080cd502 in PyEval_EvalFrameEx ()
#12 0x080d0345 in PyEval_EvalCodeEx ()
#13 0x080ce728 in PyEval_EvalFrameEx ()
#14 0x080cfbf5 in PyEval_EvalFrameEx ()
#15 0x080cfbf5 in PyEval_EvalFrameEx ()
#16 0x080d0345 in PyEval_EvalCodeEx ()
#17 0x08117891 in ?? ()
#18 0x0805d867 in PyObject_Call ()
#19 0x08063a7a in ?? ()
#20 0x0805d867 in PyObject_Call ()
#21 0x080c850c in PyEval_CallObjectWithKeywords ()
#22 0x080f9e68 in ?? ()
#23 0xb7f4550f in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#24 0xb7e93a0e in clone () from /lib/tls/i686/cmov/libc.so.6

–
View this message in context:
http://www.nabble.com/how-to-change-the-channel-width-when-data-is-transmitting-tp20471587p23611683.html
Sent from the GnuRadio mailing list archive at Nabble.com.