[Discuss-gnuradio] FW: [Linrad] Re: Ubuntu 8.10
Thank you Roger for the solution to the problem! Set your Visual Effects to none in Ubuntu 8.10 for efficient operation. Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. Don't despair, not even over the fact that you don't despair. , Kafka -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leif Asbrink Sent: Sunday, November 23, 2008 11:18 AM To: [EMAIL PROTECTED] Subject: [Linrad] Re: Ubuntu 8.10 Hi Roger, You have solved the problem:-) My Ubuntu 8.10 installation had 'Visual Effects' set to 'Normal'. That was the reason for abnormal behaviour. I have now set visual effects to 'None' and now the computer has normal behaviour and seems to run as well as with other distributions. (I have not analyzed timing issues in detail.) Thank you Roger:-) --- 0 --- According to public media here in Sweden it seems like the leading distributions are: 1)Ubuntu 2)Fedora 3)Opensuse 4)Mandriva I am using Debian for my daily work, and I have now tested Ubuntu 8.10 and Mandriva 2009 (the most recent ones) Both of them (now) run well although I was not able to change the numbering of my soundcards under Mandriva. ALSA is different there somehow. I will test Fedora and Opensuse also. Is there anyone on this list who prefers another distribution than the five mentioned? Slackware, Gentoo, CentOS or something else? If you post a message to this list about why you prefer it I will install it on my multi-partition hard disk and try to install Linrad on it to see if there are any surprises... 73 Leif / SM5BSZ On Sun, 23 Nov 2008 09:43:03 -0500 w3sz [EMAIL PROTECTED] wrote: What follows may or may not be germane to the issue you describe. I found that an earlier version of Ubuntu [8.04] installed, by default, here with 'Appearance' extras selected that caused no problem on 'modern' Core2Duo machines but which brought to its knees an old Pentium III that I ran remotely via VNC and using the Gnome desktop. The atrocious refresh and HID delays disappeared when I changed the 'appearance enhancements' to 'none' by clicking on 'System' then 'Preferences' then 'Appearance' then Visual Effects', and then clicking to select the 'None' radio button. I found that neither 'Normal' or 'Extra' settings of the 'Visual Effects' gave satisfactory performance when the VNC server was active on this old, slow machine. With the setting of 'None', everything works acceptably. Check your 8.10 install and see if something other than 'None' is selected. If so, select 'None', then recheck your CPU utilization. I would also suggest rebooting and then checking it again after making the change from either 'Normal' or 'Extra' to 'None'. Because you report that 8.04 did not exhibit porcine CPU behavior for you, this issue may not be related to your problem. On the other hand, it is possible that the 'default' settings of 'Visual Effects' have not remained constant throughout the lifetime of 8.04, and that your default install settings for 8.04 were not identical to mine, thus preventing you from seeing the problem with 8.04. If the above issue is NOT germane to the problem you described, please accept my apologies for the bandwidth. 73, Roger Rehr W3SZ http://www.nitehawk.com/w3sz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem trying to implement Reed Solomon encoder
Hi Stevie, thank you very much for the advice. I have tried to compile it removing the extern C wrap but it is not working, it keep on displaying the same error message. Maybe I'm wrong, but since all the files in the directory lib/reed-solomon are written in C instead of C++, isn't the wrap extern C necessary in my C++ component code? Thanks again. Alvaro stevie.glass wrote: Hi, Your problem is because you are not *linking* with the Reed/Solomon library. The problem is that you've wrapped the '#include fixed.h' inside an 'extern C' block. If you remove it then you'll be one step closer to getting it working. Is mise, Stevie ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio and CUDA
Hi Martin 1) You seem to be using atan on host, did you try writing one for device? 2) It seems you have each block implemented separately, did you try to put multiple ones together so that data does not have to travel to the card multiple times 3) I don't quite understand the compilation process for cuda stuff. Can you tell more detail on this. I have an empty block cuda block at the end of pipeline (details follow) Thanks Inderaj Details of compile and runtime failure I have the gr_how_to_write_a block calling the cuda funtion (in another .cu file) that does malloc/copy/free. I am using this .cu.lo: $(top_srcdir)/cudalt.py $@ $(NVCC) -c $(NVCCFLAGS) $ RUN FAILURE == [EMAIL PROTECTED] lib]# ../python/F_fm_cuda.py Traceback (most recent call last): File ../python/F_fm_cuda.py, line 32, in module import howto File /root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/lib/howto.py, line 6, in module import _howto ImportError: /usr/local/lib/python2.5/site-packages/gnuradio/_howto.so: undefined symbol: cudaFree ENV === [EMAIL PROTECTED] lib]# export | grep -i cuda declare -x LD_LIBRARY_PATH=:/usr/local/cuda/lib:/usr/local/cuda/lib declare -x PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin:.:/usr/libexec/sdcc:/usr/local/cuda/bin:/root/bin:.:/usr/libexec/sdcc:/usr/local/cuda/bin:/root/bin [EMAIL PROTECTED] lib]# export | grep -i python declare -x PYTHONPATH=:/usr/lib/python2.5/site-packages:/usr/local/lib/python2.5/site-packages:/usr/local/lib/python2.5/site-packages/gnuradio:/usr/lib/python2.5/site-packages:/usr/local/lib/python2.5/site-packages [EMAIL PROTECTED] lib]# MAKE TRACE= [EMAIL PROTECTED] gr-howto-write-a-block-3.1.3]# make make all-recursive make[1]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3' Making all in config make[2]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/config' Making all in src make[2]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src' Making all in lib make[3]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/lib' make all-am make[4]: Entering directory `/root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/lib' /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -DOMNITHREAD_POSIX=1 -pthread -I/usr/local/include/gnuradio -I/usr/local/include -I/usr/include/python2.5-g -O2 -Wall -Woverloaded-virtual -pthread -MT howto_square_ff.lo -MD -MP -MF .deps/howto_square_ff.Tpo -c -o howto_square_ff.lo howto_square_ff.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -DOMNITHREAD_POSIX=1 -pthread -I/usr/local/include/gnuradio -I/usr/local/include -I/usr/include/python2.5 -g -O2 -Wall -Woverloaded-virtual -pthread -MT howto_square_ff.lo -MD -MP -MF .deps/howto_square_ff.Tpo -c howto_square_ff.cc -fPIC -DPIC -o .libs/howto_square_ff.o mv -f .deps/howto_square_ff.Tpo .deps/howto_square_ff.Plo ../../cudalt.py cuda_block.lo nvcc -c -D_DEBUG -g -v -keep -use_fast_math -I. -IUDASDK/common/inc cuda_block.cu #$ _SPACE_= #$ _MODE_=DEVICE #$ _HERE_=/usr/local/cuda/bin #$ _THERE_=/usr/local/cuda/bin #$ TOP=/usr/local/cuda/bin/.. #$ LD_LIBRARY_PATH=/usr/local/cuda/bin/../lib:/usr/local/cuda/bin/../extools/lib::/usr/local/cuda/lib #$ PATH=/usr/local/cuda/bin/../open64/bin:/usr/local/cuda/bin/../bin:/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin:.:/usr/libexec/sdcc:/usr/local/cuda/bin:/root/bin #$ INCLUDES=-I/usr/local/cuda/bin/../include -I/usr/local/cuda/bin/../include/cudart #$ LIBRARIES= -L/usr/local/cuda/bin/../lib -lcudart #$ CUDAFE_FLAGS= #$ OPENCC_FLAGS= #$ PTXAS_FLAGS= #$ gcc -D__CUDA_ARCH__=100 -E -x c++ -DCUDA_NO_SM_13_DOUBLE_INTRINSICS -DCUDA_NO_SM_12_ATOMIC_INTRINSICS -DCUDA_NO_SM_11_ATOMIC_INTRINSICS -DCUDA_FLOAT_MATH_FUNCTIONS -I/usr/local/cuda/bin/../include -I/usr/local/cuda/bin/../include/cudart -I. -D__CUDACC__ -C -fPIC -I. -IUDASDK/common/inc -D_DEBUG -include cuda_runtime.h -m32 -malign-double -g -o cuda_block.cpp1.ii cuda_block.cu #$ cudafe --m32 --gnu_version=40102 --diag_error=host_device_limited_call -tused --gen_c_file_name cuda_block.cudafe1.c --stub_file_name cuda_block.cudafe1.stub.c --stub_header_file_name cuda_block.cudafe1.stub.h --gen_device_file_name cuda_block.cudafe1.gpu --include_file_name cuda_block.fatbin.c cuda_block.cpp1.ii #$ gcc -D__CUDA_ARCH__=100 -E -x c -DCUDA_NO_SM_13_DOUBLE_INTRINSICS -DCUDA_NO_SM_12_ATOMIC_INTRINSICS -DCUDA_NO_SM_11_ATOMIC_INTRINSICS
[Discuss-gnuradio] Complex samples format with ASK modulation
hello everybody, I am using the USRP with LFRX daughterboard to catch an RFID signal ASK modulated (frequency 13.56MHz, decimation factor 16). I really need an help because I don't understand very well the meaning of the outputs of my USRP: if the information related to the ASK is only the amplitude, so why USRP outputs I/Q samples? Which is the meaning of the Q samples? Which is the information carried by the phase (that should not be important in ASK modulation)? If I want to plot in the time domain the samples got, which kind of operation is necessary (given that I would compare my result with the usrp_oscope.py)? Any kind of help will be really well appreciated. Thank you, Marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New svn version
Hello, I tried to recompile the new svn (updated 2days ago) version and I got the following errors. I never see this error with previous version (about 2weeks old). Please let me know how can I solve this problem. Thank you, Catalin **Error*** gpio_swig.cc:3594:63: error: gnuradio_swig_bug_workaround.h: No such file or directory gpio_swig.cc: In function ‘void* _p_gr_sync_decimatorTo_p_gr_basic_block(void*)’: gpio_swig.cc:4466: error: ‘gr_sync_decimator’ was not declared in this scope gpio_swig.cc:4466: error: expected primary-expression before ‘void’ gpio_swig.cc:4466: error: expected `)' before ‘void’ gpio_swig.cc: In function ‘void* _p_gr_sync_interpolatorTo_p_gr_basic_block(void*)’: gpio_swig.cc:4481: error: ‘gr_sync_interpolator’ was not declared in this scope gpio_swig.cc:4481: error: expected primary-expression before ‘void’ gpio_swig.cc:4481: error: expected `)' before ‘void’ gpio_swig.cc: In function ‘void* _p_gr_sync_decimatorTo_p_gr_sync_block(void*)’: gpio_swig.cc:4487: error: ‘gr_sync_decimator’ was not declared in this scope gpio_swig.cc:4487: error: expected primary-expression before ‘void’ gpio_swig.cc:4487: error: expected `)' before ‘void’ gpio_swig.cc: In function ‘void* _p_gr_sync_interpolatorTo_p_gr_sync_block(void*)’: gpio_swig.cc:4493: error: ‘gr_sync_interpolator’ was not declared in this scope gpio_swig.cc:4493: error: expected primary-expression before ‘void’ gpio_swig.cc:4493: error: expected `)' before ‘void’ gpio_swig.cc: In function ‘void* _p_gr_sync_decimatorTo_p_gr_block(void*)’: gpio_swig.cc:4496: error: ‘gr_sync_decimator’ was not declared in this scope gpio_swig.cc:4496: error: expected primary-expression before ‘void’ gpio_swig.cc:4496: error: expected `)' before ‘void’ gpio_swig.cc: In function ‘void* _p_gr_sync_interpolatorTo_p_gr_block(void*)’: gpio_swig.cc:4505: error: ‘gr_sync_interpolator’ was not declared in this scope gpio_swig.cc:4505: error: expected primary-expression before ‘void’ gpio_swig.cc:4505: error: expected `)' before ‘void’ make[5]: *** [gpio_swig.lo] Error 1 make[5]: Leaving directory `/home/gnuradio/gnuradio/gr-gpio/src/lib' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/gnuradio/gnuradio/gr-gpio/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/gnuradio/gnuradio/gr-gpio/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gnuradio/gnuradio/gr-gpio' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gnuradio/gnuradio' make: *** [all] Error 2 ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New svn version
On Mon, 2008-11-24 at 17:55 -0500, Catalin LACATUS wrote: I tried to recompile the new svn (updated 2days ago) version and I got the following errors. I never see this error with previous version (about 2weeks old). Please let me know how can I solve this problem. gpio_swig.cc:3594:63: error: gnuradio_swig_bug_workaround.h: No such file or directory Apparently, the compiler cannot find the header files at compile time. While it's not clear in this specific case, often times the build system will get confused when an already built tree is then updated from svn. Please go to the top level of your source tree and run: $ make distclean Then you will need to go through bootstrap, configure, etc. again. If the problem persists, check out a fresh version of the trunk into a new directory and try it from there. Finally, if you're still stuck, let us know here. The latest trunk is definitely working, as I compile it frequently on a number of different machines/OS combinations. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio and CUDA
On Mon, 2008-11-24 at 08:47 -0800, Inderaj Bains wrote: Hi Martin 1) You seem to be using atan on host, did you try writing one for device? I use atan on cuda device. Look in gr-cuda/src/lib/cuda_quadrature_demod_cf_kernel.cu __global__ void cuda_quadrature_demod_cf_kernel( const gr_complex* g_idata, float* g_odata,const int noutput_items,const float gain) I don't know which test script you are using. The following is a FM receiver which should run completely on the device: testbed/wfm/usrp_wfm_rcv_nogui_cuda.py This script includes: testbed/wfm/cuda_wfm_rcv_cuda.py And this uses self.fm_demod = cuda.quadrature_demod_cuda_cf (fm_demod_gain) which uses the device code I started my reply with. 2) It seems you have each block implemented separately, did you try to put multiple ones together so that data does not have to travel to the card multiple times The data doesn't have to travel to the card multiple times. I copy it once to the device with a host_to_cuda block. Then the data is transfered from cuda block to cuda block all using cuda device memory. What does slow things down is that I emulate a circular buffer by copying the buffer memeory after every work call (this is a fast device-to-device copy which unfortunately is not that fast when used for small sizes (small number of output_items)) 3) I don't quite understand the compilation process for cuda stuff. Can you tell more detail on this. I have an empty block cuda block at the end of pipeline (details follow) I am not quite sure what you are trying to do. Did you make your own cuda block or are you trying to compile my code. If you want to use cuda blocks you need to use my gnuradio gpgpu-wip branche because the cuda device buffer support is in my gpgpu-wip/gnuradio-core. When building your own cuda libraries: For the cuda compiling to work you have to put cudalt.py in the rootdir gr_cuda.m4 in config/ and edit configure.ac and add: dnl Check for CUDA (required) GR_CUDA then you need to run ./bootstrap (do all the autoconf aclocal automake stuff) after that run ./configure and make sure it finds all cuda libs and the nvcc compiler. use gr-cuda/src/lib/Makefile.am as example for how to make a new cuda library. make sure you include .cu.lo: $(top_srcdir)/cudalt.py $@ $(NVCC) -c $(NVCCFLAGS) $ INCLUDES = $(STD_DEFINES_AND_INCLUDES) $(PYTHON_CPPFLAGS) $(CUDA_CFLAGS) # magic flags _yourlib_la_LDFLAGS = $(NO_UNDEFINED) -module -avoid-version # link the library against some comon swig runtime code and the # c++ standard library _cuda_la_LIBADD = \ $(PYTHON_LDFLAGS) \ $(CUDA_LIBS) \ -lstdc++ exmplanation: CUDA_LIBS adds the needed cuda libraries CUDA_CFLAGS add the needed cuda includes .cu.lo: $(top_srcdir)/cudalt.py $@ $(NVCC) -c $(NVCCFLAGS) $ makes sure a libtool like library is made for all .cu files using nvcc as compiler Very important: cuda memory can only be used in the same thread it is created in. Normally gnuradio instantiates blocks in one thread and runs the flowgraph in another thread. You can use the override the virtual methods start() and stop() of a new block to create and destroy device memory. You can also create and destroy device memory in the work(0 method of a block. The input and output circular buffers for cuda blocks are automatically created as device memory when you use CUDA_BUFFER as buffer type in the modified gr_io_sognature of input and/or output. example: This block will use cuda device memory as input and as output: cuda_quadrature_demod_cuda_cf::cuda_quadrature_demod_cuda_cf (float gain) : gr_block (quadrature_demod_cuda_cf, gr_make_io_signature (MIN_IN, MAX_IN, sizeof (gr_complex),GR_BUFFER_CUDA), gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (float),GR_BUFFER_CUDA)) This block will use normal host memory as input and as output: normal_gnuradio_cf::normal_gnuradio_cf (float gain) : gr_block (quadrature_demod_cuda_cf, gr_make_io_signature (MIN_IN, MAX_IN, sizeof (gr_complex)), gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (float))) I hope this helpes, Martin Thanks Inderaj Details of compile and runtime failure I have the gr_how_to_write_a block calling the cuda funtion (in another .cu file) that does malloc/copy/free. I am using this .cu.lo: $(top_srcdir)/cudalt.py $@ $(NVCC) -c $(NVCCFLAGS) $ RUN FAILURE == [EMAIL PROTECTED] lib]# ../python/F_fm_cuda.py Traceback (most recent call last): File ../python/F_fm_cuda.py, line 32, in module import howto File /root/dev/gnuradio-3.1.3/gr-howto-write-a-block-3.1.3/src/lib/howto.py, line 6, in module import _howto ImportError: /usr/local/lib/python2.5/site-packages/gnuradio/_howto.so: undefined symbol: cudaFree ENV === [EMAIL PROTECTED]
[Discuss-gnuradio] Help on gr_top_block and gr_hier_block2 when trying to receive after transmitting
Dear All, I was trying to make a channel estimation procedure to work, and I am in desperate need for some help. I had a preliminary version that works only part of the time, and I decided to start from scratch. I followed Eric's advice and used tunnel.py as an example. I have two USRPs, one called S and the other called R. The procedure is: (1). S sends channel estimation sequence. R receives, and estimate the channel. (2). R sends the channel estimation report back to S. (3). S sends data to R according to the channel estimation Everything works perfectly until step (2), that is, S can get the channel estimation report and can send data to R. The problem is that R cannot receive. The signal received by R is almost always near 0. My guess is that something is preventing R from receiving after it started the transmit path. Here is the skeleton of the code: tb.start() print --- started listening! --- while not tb.rxpath.receiver.finished_phase_diff_est(): time.sleep(0.001) #orig: 0.001 # here I do carrier sense, until the sender finishes while tb.rxpath.receiver.est_snr() 0.001: time.sleep(0.001) print --- sender stopped, preparing to send report! --- # here I call some functions to estimate the chanel tb.lock() tb.disconnect_all() # the transmting path was not connected originally, because my laptops are slow. I am getting some new ones. # add then cannot receive begin tb.connect(tb.txpath) tb.unlock() tb.txpath.set_tx_amplitude(_def_rv_tx_power) print --- sending rpt --- time.sleep(0.01) #orig: 0.01 tb.txpath.set_tx_amplitude(0) time.sleep(0.1) #try to make sure that 0 is written into the data buffer. tb.lock() print --- done sending! --- # add then cannot receive end tb.disconnect_all() tb.connect(tb.rxpath) tb.unlock() time.sleep(1) print --- done receving --- I noticed that if I delete the code between # add then cannot receive begin # add then cannot receive end , then the receiver can receive some signals. txpath and rxpath are both gr.hier_block2, and tb is gr_top_block, same as in tunnel.py. Can someone give me some hint to this? Thanks so much! Please let me know if more information is needed. Best regards, Zenny ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
